Graphite pára de coletar dados aleatoriamente

Question

Temos um servidor Graphite para coletar dados através do collectd, statsd, JMXTrans ... Desde alguns dias, freqüentemente temos falhas em nossos dados. Vasculhando os 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 métricasRecebido está estável em cerca de 300K). Temos um aumento no número de consultas de 1.000 a 1.500 em média.

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

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

Temos configuração de carbono 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, nem como podemos encontrar essa causa ...

Alguma ajuda?

    

Answer 1

Este não é um bug da pilha de grafite, mas sim um afunilamento de E / S, muito provavelmente porque seu armazenamento não tem o IOPS alto o suficiente. Por causa disso, a fila continua aumentando e transborda a 4M. Nesse ponto, você perde tantos dados enfileirados, o que é refletido posteriormente, como 'lacunas' aleatórias em seu gráfico. Seu sistema não pode manter-se com a escala em que está recebendo métricas. Ele mantém o cheio e transbordando .

Strangely, the cpuUsage decreases slightly from 100% (we have 4 CPU) to 50% when the cache size increase.

Isso ocorre porque seu sistema começa a trocar e as CPUs ficam com muito tempo ocioso, por causa da espera de IO.

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

    

Answer 2

Outro responsável mencionou gargalo de i / o no disco. Eu vou falar sobre afunilamento de rede como outra causa disso.

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

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

A agregação ocorreu na camada intermediária e na camada de back-end (a camada de back-end agregou as métricas agregadas transmitidas para ela a partir da camada intermediária).

Os anfitriões da camada do meio não estavam ligados à cpu, não estavam ligados ao disco e não apresentavam restrições na memória. Isso combinado com o fato de que o problema só apareceria algumas horas depois de reiniciar os processos de relés, significava que havia um gargalo na rede. Nossa solução foi simplesmente adicionar mais hosts à camada intermediária. Ao fazer isso instantaneamente, as métricas agregadas foram realizadas corretamente e não apresentaram lacunas.

O lugar exato na pilha de rede onde estava o gargalo? Eu não poderia te dizer. Poderia ter sido nos hosts linux; poderia ter sido no lado da Amazônia.