La grafite interrompe la raccolta casuale dei dati

8

Abbiamo un server Graphite per raccogliere dati tramite collectd, statsd, JMXTrans ... Da alcuni giorni, abbiamo spesso buchi nei nostri dati. Scavando i dati che abbiamo ancora, possiamo vedere un aumento delle dimensioni della cache del carbonio (da 50K a 4M). Non vediamo un aumento del numero di metriche raccolte (le metriche ricevute sono stabili a circa 300 K). In media, il numero di query è aumentato da 1000 a 1500.

Stranamente, cpuUsage diminuisce leggermente dal 100% (abbiamo 4 CPU) al 50% quando aumenta la dimensione della cache.

Stranamente, vediamo un aumento del numero se gli ottetti vengono letti dal disco e una diminuzione del numero di ottetti scritti.

Abbiamo configurato carbon principalmente con valori predefiniti:

MAX_CACHE_SIZE = inf
MAX_UPDATES_PER_SECOND = 5000
MAX_CREATES_PER_MINUTE = 2000

Ovviamente, qualcosa è cambiato nel nostro sistema, ma non capiamo cosa, né come possiamo trovare questa causa ...

Qualsiasi aiuto ?

graphite metrics

— Guillaume
fonte

Di solito parto dall'approccio fondamentalmente alle problematiche della grafite; c'è spazio sul disco su cui scrivere? Le autorizzazioni della directory dei dati sono cambiate? C'è stato un cambiamento nell'utente del daemon che raccoglie le statistiche? Se non ci sono cause chiare, è del tutto possibile che tu abbia la corruzione RRD e potrebbe essere necessario trovare un modo per esportare ciò che hai e avviare la raccolta metrica da zero.

— Stephan,

Abbiamo controllato lo spazio su disco e le autorizzazioni, niente di strano lì. Nessun cambiamento nel demone che raccoglie dati, forse un aumento del numero di metriche, ma non così grande. Stiamo esaminando la corruzione di WSP.

— Guillaume,

2

Questo non è un bug di uno stack di grafite, ma piuttosto un collo di bottiglia di IO, molto probabilmente perché la tua memoria non ha IOPS abbastanza alti. Per questo motivo, la coda continua a svilupparsi e trabocca a 4M. A quel punto, perdi tutti quei dati in coda, che verranno riflessi in seguito, come "lacune" casuali nel tuo grafico. Il tuo sistema non può tenere il passo con la scala con cui sta ricevendo le metriche. Continua a riempirsi e straripare .

Stranamente, cpuUsage diminuisce leggermente dal 100% (abbiamo 4 CPU) al 50% quando aumenta la dimensione della cache.

Questo perché il sistema inizia a scambiarsi e le CPU ottengono molto "tempo di inattività", a causa dell'attesa IO.

Per aggiungere un contesto, ho 500 IOPS predisposti su aws su un sistema su cui ricevo circa 40K metriche. La coda è stabile a 50 KB.

— erbdex
fonte

Vedo lo stesso identico problema descritto nella domanda. Tuttavia, l'utilizzo del disco è minimo (riportato come 0% -3% in cima) e sto solo spingendo ~ 80 metriche / s attraverso StatsD. Pertanto sembra improbabile che io abbia un collo di bottiglia nell'IO. Qualche idea di cosa potrebbe causare il problema?

— heyman,

1

L'altro risponditore ha menzionato il collo di bottiglia di I / o del disco. Parlerò del collo di bottiglia della rete come un'altra causa di ciò.

Nel mio ambiente, eseguiamo un cluster di server UI front-end (httpd, memcached); un altro gruppo di relè a strato intermedio (relè carbon-c che esegue forwarding e aggregazione); e un livello back-end (httpd, memcached, carbon-c-relay e carbon-cache). Ciascuno di questi cluster è costituito da più istanze in EC2 e nel processo totale 15 milioni di metriche al minuto.

Abbiamo riscontrato un problema a causa del quale erano presenti lacune per le metriche generate dalla funzione di "somma" aggregata e anche i valori aggregati erano errati (troppo bassi). Il problema sarebbe alleviato riavviando il carbon-c-relay nello strato intermedio, ma le lacune ricomincerebbero a comparire dopo diverse ore.

Abbiamo avuto aggregazione sia nel livello intermedio che nel livello back-end (il livello back-end ha aggregato le metriche aggregate passate dal livello intermedio).

Gli host del livello intermedio non erano associati alla CPU, né al disco, né alla memoria. Ciò, combinato con il fatto che il problema sarebbe apparso solo poche ore dopo il riavvio dei processi di inoltro, ha comportato un collo di bottiglia della rete. La nostra soluzione era semplicemente quella di aggiungere più host al livello intermedio. In questo modo immediatamente le metriche aggregate si sono comportate correttamente e non si sono verificate lacune.

Il posto esatto nello stack di rete dov'era il collo di bottiglia? Non potrei dirtelo. Potrebbe essere stato sugli host Linux; avrebbe potuto essere dalla parte dell'Amazzonia.

— Michael Martinez
fonte