Planejamento de capacidade de disco para Whisper / Grafite

14

Alguém tem alguma fórmula ou talvez alguns dados de amostra de seu ambiente que possam me ajudar a estimar quanto espaço em disco será usado por grafite por ponto de dados?

monitoring graphite Kyle Brandt
fonte
2
Verifique se também está planejando a E / S do disco corretamente, e não apenas a capacidade do disco. Ao longo dos anos, o rrdtool acumulou muitas micro-otimizações que o tornam muito mais rápido (2x mais rápido?) em gravações do que o formato de banco de dados Whisper da Graphite. Se você planeja manter todos os seus dados em um SSD decente, isso o levará a quase todo o caminho, mas eu não planejaria manter uma tonelada de Whisper DBs no disco giratório. Em escala, não é apenas econômico que os níveis de E / S do disco que o Graphite lança.
Jgoldschrafe # 26/13

Respostas:

7

whisper-info.py fornece muitas informações sobre o que e como cada arquivo é agregado, incluindo o tamanho do arquivo.

No entanto, é útil apenas para arquivos whisper existentes.

Quando quiser ver o dimensionamento preditivo de um esquema antes de implementá-lo, tente uma Calculadora Whisper, como a disponível em https://gist.github.com/jjmaestro/5774063

EDITAR:

Quando solicitado um exemplo ...

storage_schema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Olhando para o meu arquivo applied-in-last-hour.wsp, ls -lgera

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

e whisper-info.py ./applied-in-last-hour.wspproduz

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Portanto, basicamente você combina seus hosts por correspondência de retenção por segmento de período de retenção por estatística, multiplicando por um fator de sistemas que você pretende aplicar isso também, levando em consideração o número de novas estatísticas que você acompanhará. Então você pega qualquer quantidade de armazenamento que seja e pelo menos o dobro (porque estamos comprando armazenamento e sabemos que vamos usá-lo ...)

gWaldo
fonte
Qualquer chance de você ter alguns números de amostra (emparelhados com as configurações de retenção). No momento, estou pensando em diferentes armazenamentos de dados de séries temporais em termos de uso do disco - portanto, obter grafite ao vivo para isso é um pouco complicado.
Kyle Brandt
@KyleBrandt Resposta atualizada.
precisa saber é o seguinte
Obrigado por isso. Então, com o tamanho do arquivo, é isso que será depois de uma hora de coleta de dados ou é o que o tamanho do arquivo será sempre? Então 4415092 é representativo de 5 anos no valor de retenção dessa retenção, ou é representativo de uma hora de 1 minuto? Além disso, são bytes ou bits?
Kyle Brandt
Esta é uma nova implementação nesta empresa e não tenho acesso à minha antiga. Como o resultado fileSize de nível superior corresponde ao ls -lresultado, considero que sejam bytes. Quando adiciono os tamanhos dos arquivos dentro do arquivo .wsp (conforme relatado por whisper-info.py), eles se aproximam do tamanho geral do arquivo .wsp (o restante, suponho que sejam metadados e outros). Esse deve ser o tamanho do arquivo para todos tempo, como dados cai para resoluções mais baixas de dados e pontos de dados antigos são descartados.
gWaldo
Ok, então com essas configurações de retenção. Aproximadamente:ServerCount * MetricCount * 4.5MBytes
Kyle Brandt
2

Na documentação do statsd, eles fornecem um exemplo para uma política de retenção de dados.

As retenções são 10s:6h,1min:7d,10min:5y2160 + 10080 + 262800 = 275040 pontos de dados e fornecem um tamanho de arquivo de 3,2 MiB .

Supondo uma relação linear, isso seria aproximadamente 12,2 bytes por ponto de dados .

AndreKR
fonte
Os pares ops-school.readthedocs.org/en/latest/monitoring_201.html (carimbo de data / hora, valor) são armazenados como um valor longo e um dobro, consumindo 12 bytes por par. A diferença de 0,2 provavelmente deve-se à sobrecarga das informações de metadados do arquivo ?!
precisa saber é o seguinte
1

Nenhuma experiência direta com o Graphite, mas imagino que a mesma lógica que usamos para o Cacti ou qualquer outra coisa aplicada a RRD ou com rollover no tempo se aplicaria (o Graphite não usa RRD mais internamente, mas a lógica de armazenamento parece comparável).

A resposta rápida é "Provavelmente não tem tanto espaço quanto você acha que precisará".

A resposta longa envolve alguma matemática específica do site. Para o nosso sistema de monitoramento (InterMapper), descubro os períodos de retenção, as resoluções e o tamanho dos pontos de dados, faço algumas multiplicações e adiciono sobrecarga.

Como exemplo, utilizarei espaço em disco - armazenamos números com uma precisão de 5 minutos por 30 dias, uma precisão de 15 minutos por mais 60 dias e, em seguida, uma precisão horária por mais 300 dias, e estamos usando um 64 inteiro de 8 bits (8 bytes) para armazená-lo:

  • 21600 total de amostras, discriminadas como:
    • 8640 amostras para a precisão de 30 dias e 5 minutos
    • 5760 amostras para a precisão de 60 dias e 15 minutos
    • 7200 amostras para a precisão de 300 dias em 1 hora

Com 8 bytes por amostra, isso significa cerca de 173 KB, mais uma sobrecarga saudável para indexação de armazenamento e similares, chegando a cerca de 200 KB para os dados de uso de disco de uma partição (qualquer erro tendendo a superestimar).

A partir das métricas básicas, posso calcular um tamanho médio "por máquina" (10 partições de disco, espaço de troca, RAM, média de carga, transferência de rede e algumas outras coisas) - resulta em cerca de 5 MB por máquina.

Também adiciono 10% saudáveis ​​em cima do número final e arredondo para cima, para dimensionar as coisas em 6 MB por máquina.

Depois, olho para o 1 TB de espaço disponível para armazenar dados de métricas para gráficos e digo "Sim, provavelmente não estou ficando sem armazenamento durante a minha vida, a menos que cresçamos muito!" :-)

voretaq7
fonte
1
Para lançar um número da prática real por aí, com minhas políticas de retenção de produção (9 meses a 5 minutos; 1 ano a cada hora; 5 anos diariamente) e cerca de 20 máquinas com ~ 20 métricas de 8 bytes cada, mais o aviso / alarme / histórico de eventos críticos / de interrupção por 5 anos, estou usando 1,5 G de espaço em disco. Isso ocorre com o InterMapper inserindo tudo em um banco de dados Postgres. Então, mais uma vez - a resposta rápida é "Provavelmente não tanto espaço quanto você acha que vai precisar" :-)
voretaq7
Sim, essa matemática é direta, estou apenas procurando mais sobre como o Graphite armazena dados - pode fazer grandes diferenças em escala. A única coisa que descobri é que, de acordo com os documentos, não é muito eficiente em termos de espaço (provavelmente porque conta com acumulações bastante agressivas).
Kyle Brandt
O Whisper (o Graphite de back-end de armazenamento usa) tem alguns itens internos para mastigar espaço - você provavelmente já viu essa página. A seção sobre "Os arquivos se sobrepõem a períodos de tempo" se destaca para mim porque significa que os arquivos são maiores do que meus exemplos acima, pois todos remontam ao início dos tempos (o arquivo de 60 dias dura na verdade 90 dias; o arquivo de 300 dias é 390 dias). O Whisper também mantém um registro de data e hora (4 ou 8 bytes) junto com cada ponto de dados que também precisa ser adicionado. Não parece que complicado, apenas inchado :)
voretaq7
0

Eu tenho 70 nós que geram muitos dados. Usando Carbon / Whisper, um nó criou 91k arquivos sozinho (o nó gera vários esquemas, cada um com vários contadores e campos variáveis ​​que precisam ser selecionáveis. Por exemplo: (nodename). (Schema). (Counter). (Subcounter). (Etc )....e assim por diante).

Isso forneceu a granularidade necessária para plotar qualquer gráfico que eu quisesse. Depois de executar o script para preencher os 69 nós restantes, eu tinha 1,3 TB de dados no disco. E isso representa apenas 6 horas de dados / nó. O que me impressiona é que o arquivo CSV plano real para 6 horas de dados é de cerca de 230 Mb / nó. 70 nós são ~ 16 GB de dados. Meu esquema de armazenamento era 120s: 365d.

Eu sou relativamente novo em bancos de dados, portanto, posso estar fazendo algo errado, mas acho que é uma sobrecarga para cada amostra.

Portanto, foi um experimento divertido, mas não acho que faça sentido usar o sussurro para o tipo de dados que estou armazenando. O MongoDB parece um solução melhor, mas preciso descobrir como usá-lo como um back-end para o Grafana.

musca999
fonte