Graphit sammelt keine Daten mehr zufällig

8

Wir haben einen Graphite-Server zum Sammeln von Daten über collectd, statsd, JMXTrans ... Seit einigen Tagen haben wir häufig Lücken in unseren Daten. Wenn wir uns die Daten ansehen, die wir noch haben, können wir eine Zunahme der Größe des Carbon-Cache feststellen (von 50 KB auf 4 MB). Wir sehen keinen Anstieg der Anzahl der gesammelten Metriken (metricsReceived ist stabil bei etwa 300 KB). Wir haben die Anzahl der Anfragen von durchschnittlich 1000 auf 1500 erhöht.

Seltsamerweise verringert sich die CPU-Auslastung geringfügig von 100% (wir haben 4 CPUs) auf 50%, wenn die Cache-Größe zunimmt.

Seltsamerweise sehen wir wieder eine Zunahme der Anzahl, wenn Oktette von der Festplatte gelesen werden, und eine Abnahme der Anzahl der geschriebenen Oktette.

Wir haben Carbon hauptsächlich mit Standardwerten konfiguriert:

MAX_CACHE_SIZE = inf
MAX_UPDATES_PER_SECOND = 5000
MAX_CREATES_PER_MINUTE = 2000

Offensichtlich hat sich etwas in unserem System geändert, aber wir verstehen nicht, was und wie wir diese Ursache finden können ...

Irgendeine Hilfe ?

graphite metrics

— Guillaume
quelle

Normalerweise beginne ich von Grund auf mit Graphitproblemen. Gibt es auf der Festplatte Speicherplatz zum Schreiben? Haben sich die Datenverzeichnisberechtigungen überhaupt geändert? Hat sich die Erfassung der Statistiken durch den Daemon-Benutzer geändert? Sollte es keine eindeutige Ursache geben, ist es durchaus möglich, dass Sie eine RRD-Beschädigung haben und möglicherweise einen Weg finden müssen, um das zu exportieren, was Sie haben, und die Metrikerfassung von Grund auf neu zu starten.

— Stephan

Wir haben den Speicherplatz und die Berechtigung überprüft, nichts Seltsames. Keine Änderung im Daemon, der Daten sammelt, möglicherweise eine Erhöhung der Anzahl der Metriken, aber nicht so groß. Wir untersuchen die WSP-Korruption.

— Guillaume

2

Dies ist kein Fehler eines Graphitstapels, sondern ein E / A-Engpass, höchstwahrscheinlich, weil Ihr Speicher nicht über genügend IOPS verfügt. Aus diesem Grund baut sich die Warteschlange ständig auf und läuft bei 4M über. Zu diesem Zeitpunkt verlieren Sie so viele Daten in der Warteschlange, die später wiedergegeben werden, als zufällige "Lücken" in Ihrem Diagramm. Ihr System kann nicht mit der Skala Schritt halten, in der es Metriken empfängt. Es füllt sich ständig und läuft über .

Seltsamerweise verringert sich die CPU-Auslastung geringfügig von 100% (wir haben 4 CPUs) auf 50%, wenn die Cache-Größe zunimmt.

Dies liegt daran, dass Ihr System mit dem Austausch beginnt und die CPUs aufgrund der E / A-Wartezeit viel Leerlaufzeit haben.

Um den Kontext hinzuzufügen, habe ich 500 IOPS bei aws auf einem System bereitgestellt, auf dem ich etwa 40.000 Metriken erhalte. Die Warteschlange ist stabil bei 50 KB.

— erbdex
quelle

Ich sehe genau das gleiche Problem, das in der Frage beschrieben ist. Die Festplattennutzung ist jedoch minimal (von atop als 0% -3% angegeben) und ich schiebe nur ~ 80 Metriken / s durch StatsD. Daher ist es unwahrscheinlich, dass ich einen E / A-Engpass habe. Irgendeine Idee, was das Problem verursachen könnte?

— Heyman

1

Andere Antwortende erwähnten den Festplatten-E / A-Engpass. Ich werde über einen Netzwerkengpass als eine weitere Ursache dafür sprechen.

In meiner Umgebung führen wir einen Cluster von Front-End-UI-Servern aus (httpd, memcached). ein weiterer Cluster von Relais der mittleren Schicht (Carbon-C-Relais, das die Weiterleitung und Aggregation durchführt); und eine Backend-Schicht (httpd, memcached, Carbon-C-Relay und Carbon-Cache). Jeder dieser Cluster besteht aus mehreren Instanzen in EC2 und verarbeitet insgesamt 15 Millionen Metriken pro Minute.

Wir hatten ein Problem, bei dem Lücken für die von der aggregierten "Summen" -Funktion generierten Metriken festgestellt wurden und auch die aggregierten Werte falsch waren (zu niedrig). Das Problem würde durch einen Neustart des Carbon-C-Relais in der mittleren Schicht behoben, aber nach einigen Stunden würden wieder Lücken auftreten.

Wir hatten eine Aggregation sowohl in der mittleren Schicht als auch in der Backend-Schicht (die Backend-Schicht aggregierte die aggregierten Metriken, die von der mittleren Schicht an sie übergeben wurden).

Die Hosts der mittleren Schicht waren nicht an die CPU, nicht an die Festplatte und keine Speicherbeschränkungen gebunden. Dies zusammen mit der Tatsache, dass das Problem nur wenige Stunden nach dem Neustart der Relay-Prozesse auftreten würde, bedeutete, dass es einen Netzwerkengpass gab. Unsere Lösung bestand einfach darin, der mittleren Schicht weitere Hosts hinzuzufügen. Dies führte sofort dazu, dass die aggregierten Metriken korrekt funktionierten und keine Lücken aufwiesen.

Wo genau war der Engpass im Netzwerkstapel? Ich konnte es dir nicht sagen. Es könnte auf den Linux-Hosts gewesen sein; es könnte auf der Amazonas-Seite gewesen sein.

— Michael Martinez
quelle