O grafite para de coletar dados aleatoriamente

8

Temos um servidor Graphite para coletar dados por meio de collectd, statsd, JMXTrans ... Há alguns dias, frequentemente, temos falhas em nossos dados. Procurando nos dados que ainda temos, podemos ver um aumento no tamanho do cache de carbono (de 50K para 4M). Não vemos um aumento no número de métricas coletadas (o MetricsReceived é estável em cerca de 300K). Temos um aumento no número de consultas de 1000 para 1500 em média.

Estranhamente, o cpuUsage diminui ligeiramente de 100% (temos 4 CPU) para 50% quando o tamanho do cache aumenta.

Estranhamente, vemos um aumento no número de octetos lidos no disco e uma diminuição no número de octetos gravados.

Temos o carbono configurado principalmente com valores padrão:

MAX_CACHE_SIZE = inf
MAX_UPDATES_PER_SECOND = 5000
MAX_CREATES_PER_MINUTE = 2000

Obviamente, algo mudou em nosso sistema, mas não entendemos o que e nem como podemos encontrar essa causa ...

Qualquer ajuda ?

graphite metrics

— Guillaume
fonte

Normalmente começo da abordagem inicial para questões de grafite; há espaço no disco para gravar? As permissões do diretório de dados foram alteradas? Houve uma alteração no usuário daemon que coleta estatísticas? Se não houver uma causa clara, é perfeitamente possível que você tenha corrupção de RRD e talvez seja necessário encontrar uma maneira de exportar o que você possui e iniciar a coleta de métricas do zero.

— 28413 Stephan Stephan

Verificamos o espaço em disco e a permissão, nada de estranho lá. Nenhuma mudança no daemon que coleta dados, talvez um aumento no número de métricas, mas não tão grande. Estamos analisando a corrupção do WSP.

— Guillaume

2

Este não é um bug de uma pilha de grafite, mas um gargalo de E / S, provavelmente porque seu armazenamento não possui IOPS suficientemente altas. Por esse motivo, a fila continua se acumulando e transbordando na 4M. Nesse ponto, você perde muitos dados na fila, refletidos posteriormente, como 'lacunas' aleatórias no gráfico. Seu sistema não pode acompanhar a escala na qual está recebendo métricas. Ele continua enchendo e transbordando .

Estranhamente, o cpuUsage diminui ligeiramente de 100% (temos 4 CPU) para 50% quando o tamanho do cache aumenta.

Isso ocorre porque o sistema começa a trocar e as CPUs ficam com muito tempo ocioso, devido à espera de E / S.

Para adicionar contexto, tenho 500 IOPS provisionados no aws em um sistema no qual recebo algumas métricas de 40K. A fila é estável em 50K.

— erbdex
fonte

Estou vendo exatamente o mesmo problema descrito na pergunta. No entanto, o uso do disco é mínimo (relatado como 0% -3% no topo) e eu apenas estou enviando ~ 80 métricas / s através do StatsD. Portanto, parece improvável que eu tenha um gargalo de IO. Alguma idéia do que pode estar causando o problema?

— Heyman

1

Outro respondente mencionou gargalo de E / S de disco. Vou falar sobre o gargalo da rede como outra causa disso.

No meu ambiente, executamos um cluster de servidores de interface do usuário front-end (httpd, memcached); outro agrupamento de relés da camada intermediária (relé carbono-c realizando encaminhamento e agregação); e uma camada de back-end (httpd, memcached, carbono-c-relay e carbono-cache). Cada um desses clusters consiste em várias instâncias no EC2 e no total processam 15 milhões de métricas por minuto.

Tivemos um problema em que estávamos vendo lacunas nas métricas geradas pela função agregada "soma", e também os valores agregados estavam incorretos (muito baixos). O problema seria aliviado ao reiniciar o relé carbono-c na camada intermediária, mas as lacunas começariam a aparecer novamente após várias horas.

Tivemos a agregação ocorrendo na camada intermediária e na camada de back-end (a camada de back-end agregou as métricas agregadas passadas a ele da camada do meio).

Os hosts da camada intermediária não estavam vinculados à CPU, nem ao disco e nem à memória. Isso combinado ao fato de o problema aparecer apenas algumas horas após o reinício dos processos de retransmissão, significava que havia um gargalo na rede. Nossa solução foi simplesmente adicionar mais hosts à camada intermediária. Fazer isso instantaneamente resultou no desempenho correto das métricas agregadas e na ausência de lacunas.

O local exato na pilha de rede onde estava o gargalo? Eu não poderia te contar. Poderia estar nos hosts linux; poderia estar no lado amazônico.

— Michael Martinez
fonte