Planejamento da capacidade de disco para o sussurro / grafite

Question

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?

    

Answer 1

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

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

Quando você quiser ver o dimensionamento preditivo de um esquema antes de colocá-lo no lugar, experimente uma calculadora Whisper, como a disponível em link

EDITAR:

Quando perguntado por um exemplo ...

storage_schema:

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

Olhando meu arquivo applied-in-last-hour.wsp , ls -l yields

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

e whisper-info.py ./applied-in-last-hour.wsp retornam

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

Então, basicamente você combina seus hosts por correspondência de retenção por segmento de período de retenção por estatística, multiplica por um fator de sistemas que você pretende aplicar também, fator no número de novas estatísticas que você vai faixa. Então você pega a quantidade de armazenamento que é e pelo menos o dobro (porque estamos comprando armazenamento e sabemos que vamos usá-lo ...)

    

Answer 2

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

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

Assumindo um relacionamento linear, isso seria aproximadamente 12,2 bytes por ponto de dados .

    

Answer 3

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

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

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

Como exemplo, vou usar espaço em disco - nós armazenamos figuras com precisão de 5 minutos por 30 dias, precisão de 15 minutos por mais 60 dias e, em seguida, uma precisão por hora por mais 300 dias. usando um inteiro de 64 bits (8 bytes) para armazená-lo:

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

Com 8 bytes por amostra, cerca de 173KB, além de uma sobrecarga saudável para indexação de armazenamento e coisas do gênero, ela chega a cerca de 200KB para dados de uso de disco de uma partição (qualquer erro tendendo a superestimação).

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) - funciona com cerca de 5 MB por máquina.

Eu também adiciono uns 10% saudáveis no topo do número final e arredondo para cima, então eu tamanho as coisas em 6MB por máquina.

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

    

Answer 4

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

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

Sou relativamente novo em bancos de dados, portanto, posso estar fazendo algo errado, mas suponho que seja toda a sobrecarga para cada amostra.

Portanto, foi uma experiência divertida, mas não acho que faça sentido usar o sussurro para o tipo de dados que estou armazenando. O MongoDB parece uma solução melhor, mas preciso descobrir como usá-lo como um backend para o Grafana.