Graphit zeigt "Keine" für alle Datenpunkte an, obwohl ich ihm Daten sende


8

Ich habe Graphite über Puppet ( https://forge.puppetlabs.com/dwerder/graphite ) mit nginx und PostgresSQL installiert . Wenn ich Daten manuell sende, wird die Metrik erstellt, aber alle Datenpunkte sind "Keine" (auch bekannt als null). Dies passiert auch, wenn ich die mit Graphite gelieferte example-client.py ausführe.

echo "jakub.test 42 $(date +%s)" | nc 0.0.0.0 2003 # Carbon listens at 2003
# A minute or so later:
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | head -n1
Sun May  4 12:19:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | tail -n1
Mon May  5 12:09:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | grep -v None | wc -l
0

Und:

$ python /opt/graphite/examples/example-client.py 
# Wait until it sends two batches of data ...
$ whisper-fetch.py /opt/graphite/storage/whisper/system/loadavg_15min.wsp | grep -v None | wc -l
0

Dies sind laut ngrep die Daten, die [von einem späteren Versuch] am Port ankommen (Zeile 3):

####
T 127.0.0.1:34696 -> 127.0.0.1:2003 [AP]
  jakub.test  45 1399362193. 
####^Cexit
23 received, 0 dropped

Dies ist der relevante Teil von /opt/graphite/conf/storage-schemas.conf:

[default]
pattern = .*
retentions = 1s:30m,1m:1d,5m:2y

Irgendeine Idee was falsch ist? Die eigenen Metriken und Daten von Carbon werden in der Benutzeroberfläche angezeigt. Vielen Dank!

Umgebung: Ubuntu 13.10 Saucy, Graphit 0.9.12 (via Pip).

PS: Ich habe hier über meine Fehlerbehebungsversuche geschrieben - Graphit zeigt Metriken an, aber keine Daten - Fehlerbehebung

UPDATE :

  1. Datenpunkte in Flüsterdateien werden nur alle 1 Minute wiederhergestellt, selbst wenn die Aufbewahrungsrichtlinie eine höhere Genauigkeit wie "1s" oder "10s" angibt.
  2. Problemumgehung für ignorierte Daten: Verwenden Sie entweder ein Aggregationsschema mit xFilesFactor = 0.1(anstelle von 0,5) oder setzen Sie die niedrigste Genauigkeit auf 1 m anstelle von <Zahl zwischen 1-49> s. - Siehe die Kommentare unter der akzeptierten Antwort oder die Frage zu Graphite Answers. In den Dokumenten heißt es : " Sollte xFilesFactoreine Gleitkommazahl zwischen 0 und 1 sein und gibt an, welcher Bruchteil der Slots der vorherigen Aufbewahrungsstufe Nicht-Null-Werte haben muss, um zu einem Nicht-Null-Wert zu aggregieren. Der Standardwert ist 0,5. " Es scheint also, dass die Daten ohne Berücksichtigung einer festgelegten Genauigkeit von 1s zu 1 Minute aggregiert werden und am Ende "Keine" sind, da weniger als 50% der Werte im Minutenzeitraum "Keine" sind.

LÖSUNG

Also führte mich @jlawrie zur Lösung. Es stellt sich heraus, dass die Daten tatsächlich vorhanden sind, aber zu nichts aggregiert werden. Der Grund ist doppelt:

  1. Sowohl die Benutzeroberfläche als auch der Flüsterabruf zeigen Daten an, die mit höchster Genauigkeit aggregiert wurden und sich über den gesamten Abfragezeitraum erstrecken, der standardmäßig 24 Stunden beträgt. Dh alles mit einer Aufbewahrung <1d wird niemals in der Benutzeroberfläche angezeigt oder abgerufen, es sei denn, Sie wählen einen kürzeren Zeitraum. Da meine Aufbewahrungsdauer für 1s 30 Minuten betrug, musste ich einen Zeitraum von <= letzten 30 Minuten auswählen, um die Rohdaten tatsächlich mit der höchsten Genauigkeit zu sehen, die erfasst wird.
  2. Beim Aggregieren von Daten (in meinem Fall von 1s bis 1min) benötigt Graphite standardmäßig, dass 50% (xFilesFactor = 0,5) der Datenpunkte im Zeitraum einen Wert haben. Wenn nicht, werden die vorhandenen Werte ignoriert und zu Keine zusammengefasst. In meinem Fall müsste ich also mindestens 30 Mal innerhalb einer Minute Daten senden (30 ist 50% von 60s = 1min), damit sie im aggregierten 1-Minuten-Wert angezeigt werden. Meine App sendet jedoch nur alle 10 Sekunden Daten, sodass ich nur 6 der möglichen 60 Werte habe.

=> Die Lösung besteht darin, die erste Genauigkeit von 1s auf 10s zu ändern und einen kürzeren Zeitraum auszuwählen, in dem die Rohdaten angezeigt werden sollen (oder die Aufbewahrung auf 24 Stunden zu erweitern, um sie standardmäßig anzuzeigen).


Der mit Nullen gefüllte Graphite Answers- Fragendatensatz? ist in diesem Zusammenhang interessant (erwähnt die Standardaddition von null alle 60 s, nur 24 h) und b / c die Empfehlung von ngrep zur Fehlerbehebung.
Jakub Holý

Ich habe auch bei Graphite Answers um Hilfe gebeten - answers.launchpad.net/graphite/+question/248242
Jakub Holý

Haben Sie die Protokolle überprüft? Wenn es ein Problem mit der empfangenen Metrik gibt (no \ n oder verwenden Sie stattdessen \ r \ n), sollten Sie etwas in console.log oder created.log sehen. Diese Protokolle werden in / opt / graphite / storage / log / carbon-cache / carbon-cache-a / gespeichert, wenn Sie den Standardinstallationspfad verwendet haben.
Mattsn0w

Ja, ich habe die Protokolle überprüft. Es gab nichts Interessantes. Das Konsolenprotokoll hatte im Wesentlichen nur "[..] ServerFactory ab 7002 [..] Starten der Factory-Instanz <twisted.internet.protocol.ServerFactory unter 0x1bc4248>" und Aufzeichnungen zum Erstellen der erwarteten Metriken, jedoch keine Erwähnung der Daten - f. Ex. (für eine andere datenlose Metrik) "[..] Erstellen der Datenbankdatei /opt/graphite/storage/whisper/ring/handling-time/POST/15MinuteRate.wsp (archive = [(1, 1800), (60, 1440) ), (300, 210240)] xff = 0,5 agg = Durchschnitt) "
Jakub Holý

@ JakubHolý Könnten Sie die Antwort von jlawrie aktualisieren oder eine andere Antwort posten, da die Frage jetzt eine Antwort enthält
030

Antworten:


8

Ich habe das gleiche Problem mit dem gleichen Puppenmodul festgestellt. Ich bin mir nicht ganz sicher, warum, aber das Ändern der Standardaufbewahrungsrichtlinie scheint das Problem zu beheben, z

class { 'graphite':
  gr_storage_schemas => [
    {
      name       => 'carbon',
      pattern    => '^carbon\.',
      retentions => '1m:90d'
    },
    {
      name       => 'default',
      pattern    => '.*',
      retentions => '1m:14d'
    }
  ],
}

Vielen Dank! Diese mysteriöse Veränderung hat wirklich geholfen. Interessant ist, dass das Ändern der Aufbewahrung von "1s: 30m, 1m: 1d, 5m: 2y" auf "1m: 14d" das Problem "behebt". Ich werde versuchen, mehr damit zu spielen. Möglicherweise gibt es ein Problem mit der 1s-Granularität?
Jakub Holý

Es scheint in der Tat ein Problem mit der s-Periode zu sein - während es '1m:1d,5m:2yfunktioniert (Daten gespeichert), 10s:30m,1m:1d,5m:2ynicht. Aus der .wsp-Datei geht hervor, dass die Granularität <1 m ignoriert wird, da die Zeitstempel für die 10s: ... config immer noch in Intervallen von 1 min liegen - "08:17:00, 08:18:00 usw."
Jakub Holý

OK, das Problem hängt also mit der Aggregationsrichtlinie zusammen, und xFilesFactordie hier geltende (Standardeinstellung) ist durchschnittlich und xFilesFactor=0.5(siehe /opt/graphite/conf/storage-aggregation.conf). Wenn ich zu sumund 0.1durch Ändern des Namens ändere , werden die Daten gespeichert (obwohl die Spitzen immer noch bei 1 m Frequenz sind):echo -e "jakub.test.10s30m+1m1d+5m2y.count 42 $(date +%s)" | nc 0.0.0.0 2003
Jakub Holý

Ich habe mit diff gespielt. aggreg. Schemata, die Daten werden aufgezeichnet (im Abstand von 1 m), wenn ich xFilesFactor = 0.1die Agg einstelle . Methode spielt keine Rolle (zumindest die gesamte durchschnittliche, letzte, Summenarbeit).
Jakub Holý

Nach diesem kommen die Aggregation - Schemata nur ins Spiel mit mehreren Aufbewahrungsrichtlinien. Wenn ich nur eine Aufbewahrungsrichtlinie habe, selbst bei einer Auflösung von 10 Sekunden (wie oft ich Daten sende), sammelt sie jeden einzelnen Datenpunkt. Bei mehreren Aufbewahrungsrichtlinien wird die Richtlinie basierend auf dem Zeitbereich der Abfrage ausgewählt, die mit der Datei "whisper-fetch.py" standardmäßig bis zum letzten Tag verwendet wird. Aus diesem Grund werden Datenpunkte nur alle 1 Minute angezeigt. Ich bin mir immer noch nicht sicher, warum sie None anstelle von aggregiertem Wert anzeigen würden.
Jlawrie

1

Es gibt viele Möglichkeiten, wie Graphite Daten verliert, weshalb ich wirklich versuche, sie nicht zu verwenden. Lassen Sie mich mit einer einfachen beginnen - versuchen Sie, Ihre Anwendung zu verbinden, warten Sie eine Sekunde (buchstäblich eine Sekunde) und geben Sie dann die zeitgestempelten Daten aus. Ich habe unter vielen Umständen festgestellt, dass dies genau dieses Problem behebt. Eine andere Sache, die Sie versuchen sollten, ist das Senden von Daten mit einer Häufigkeit, die viel höher ist als die Häufigkeit, mit der Graphit Daten protokolliert. Ich werde noch etwas näher darauf eingehen. Ein weiterer häufiger Fehler ist die Verwendung des Dienstprogrammswhisper-resize.py, das bei mir wirklich nicht funktioniert hat. Wenn Ihre Daten noch nicht wichtig sind, löschen Sie einfach die Flüsterdateien und lassen Sie sie mit den neuen Aufbewahrungseinstellungen erstellen.

Die Speicherdateien von Graphite, die Flüsterdateien, speichern die Daten nicht als Punkt mit einem Wert und einer Zeit (wie Sie das Programm angegeben haben), sondern mit einer Reihe von Slots, in denen der Wert gespeichert wird. Das Programm versucht es dann Finden Sie mithilfe der Aufbewahrungsdatendatei heraus, welcher Steckplatz einem Zeitraum entspricht. Wenn es Daten erhält, die nicht genau in einen Steckplatz passen, i denke ichEs wird ein Durchschnitt, ein Minimum oder ein Maximum verwendet, abhängig von einer anderen Datei im selben Verzeichnis wie die Aufbewahrungsdatei. Ich fand, dass der beste Weg, um dies zu verhindern, darin bestand, Daten mit einer Häufigkeit zu übermitteln, die viel höher war als die Häufigkeit, mit der Graphit Daten speicherte. Es wird ehrlich gesagt sehr kompliziert - es gibt nicht nur Aufbewahrungsfristen für Graphit und Mittelungsalgorithmen, die Punkte füllen (glaube ich), sondern diese Werte werden AUCH auf die Flüsterdateien angewendet. Sehr seltsame Dinge passieren, wenn diese nicht übereinstimmen. Bis Ihre Konfiguration funktioniert, würde ich empfehlen, Ihre Flüsterdateien wiederholt zu löschen und sie von Graphit neu erstellen zu lassen.

Dieses Programm hat mich wirklich als ziemlich fehlerhaft empfunden. Wenn Sie also auf so etwas stoßen, gehen Sie nicht davon aus, dass es Ihre Schuld ist.


Vielen Dank, ich denke, ich sollte mehr darüber erfahren, wie das Abrufen und Aggregieren von Daten funktioniert. Vielleicht ist dies tatsächlich die Ursache des Problems. Ich denke jedoch, dass " Daten mit einer Frequenz einreichen, die viel höher war als die Häufigkeit, mit der Graphit Daten speicherte ", eine suboptimale Lösung ist, da nur der letzte in jeder Graphitperiode empfangene Datenpunkt aufgezeichnet wird, andere ignoriert werden - deshalb f.ex. . statsD Spülperiode muss = Graphitperiode sein .
Jakub Holý

1
Übrigens, Graphit / Kohlenstoff "verlieren" Daten könnten mit Kohlenstoffeinstellungen wie MAX_UPDATES_PER_SECOND = 500, MAX_CREATES_PER_MINUTE = 50 zusammenhängen (ich denke, Datenpunkte / Metriken über dem Grenzwert werden einfach gelöscht).
Jakub Holý

Es scheint, dass ich mich geirrt habe. In der Dokumentation wird - wenn ich es richtig interpretiere - angegeben, dass die obigen Einstellungen den Festplattenzugriff einschränken, die Daten / Metriken jedoch weiterhin im Speicher gespeichert sind (obwohl ich dies zuerst wirklich überprüfen möchte).
Jakub Holý

Einige davon könnten definitiv einige der Probleme erklären, die ich mit dieser Anwendung hatte.
Einige Linux Nerd
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.