Festplattenkapazitätsplanung für Whisper / Graphite

14

Hat jemand Formeln oder einige Beispieldaten aus seiner Umgebung, mit denen ich abschätzen kann, wie viel Speicherplatz von Graphit pro Datenpunkt belegt wird?

monitoring graphite Kyle Brandt
quelle
2
Stellen Sie sicher, dass Sie Ihre Festplatten-E / A auch richtig planen und nicht nur Ihre Festplattenkapazität. rrdtool hat im Laufe der Jahre eine Menge von Mikrooptimierungen gesammelt, die es beim Schreiben viel schneller (2x schneller?) machen als das Whisper-Datenbankformat von Graphite. Wenn Sie vorhaben, alle Ihre Daten auf einer anständigen SSD zu speichern, werden Sie den größten Teil des Weges dorthin zurücklegen, aber ich würde nicht vorhaben, eine ganze Tonne Whisper-DBs auf einer sich drehenden Festplatte zu speichern. In der Größenordnung ist es einfach nicht kosteneffektiv, dass die von Graphite ausgelösten Festplatten-E / A-Ebenen erreicht werden.
Jgoldschrafe

Antworten:

7

whisper-info.py gibt Ihnen viel Einblick, was und wie jede Datei aggregiert wird, einschließlich der Dateigröße.

Es ist jedoch nur für vorhandene Whisper-Dateien nützlich.

Wenn Sie die prädiktive Größenbestimmung eines Schemas vor dem Einsetzen anzeigen möchten, versuchen Sie es mit einem Flüstern-Rechner, wie er beispielsweise unter https://gist.github.com/jjmaestro/5774063 verfügbar ist

BEARBEITEN:

Auf die Frage nach einem Beispiel ...

Speicherschema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Ein Blick auf meine Datei applied-in-last-hour.wsp, ls -lAusbeuten

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

und whisper-info.py ./applied-in-last-hour.wspErträge

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Im Grunde genommen kombinieren Sie Ihre Hosts pro Aufbewahrungs-Match pro Aufbewahrungszeitraum-Segment pro Statistik, multiplizieren dies mit einem Faktor von Systemen, die Sie ebenfalls anwenden möchten, und berücksichtigen die Anzahl der neuen Statistiken, die Sie verfolgen werden. Dann nehmen Sie jede Menge Speicherplatz und verdoppeln ihn mindestens (weil wir Speicher kaufen und wissen, dass wir ihn verwenden werden ...)

gWaldo
quelle
Jede Möglichkeit, dass Sie einige Probennummern daraus haben (gepaart mit Aufbewahrungseinstellungen). Im Moment denke ich über verschiedene Zeitreihendatenspeicher in Bezug auf die Festplattennutzung nach. Es ist also eine leichte Aufgabe, dafür Graphit live zu bekommen.
Kyle Brandt
@KyleBrandt Antwort aktualisiert.
gWaldo
Danke dafür. Ist es bei der Dateigröße das, was es nach einer Stunde Datenerfassung sein wird, oder ist es das, was die Dateigröße so ziemlich immer sein wird? Ist 4415092 also repräsentativ für die Speicherung von Daten aus 5 Jahren oder repräsentativ für Daten aus einer Stunde mit einer Minute? Ist das auch Bytes oder Bits?
Kyle Brandt
Dies ist eine neue Implementierung in dieser Firma, und ich habe keinen Zugriff auf meine alte. Da das FileSize-Ergebnis der obersten Ebene mit dem Ergebnis übereinstimmt ls -l, nehme ich das als Byte. Wenn ich die Größe der Archive in der .wsp-Datei addiere (wie von gemeldet whisper-info.py), entsprechen sie in etwa der Gesamtgröße der .wsp-Datei (der Rest sind vermutlich Metadaten usw.). Dies sollte die Größe der Datei für alle sein Zeit, da Daten auf niedrigere Datenauflösungen herunterfallen und alte Datenpunkte verworfen werden
gWaldo
Okay, also mit diesen Aufbewahrungseinstellungen. Grob ServerCount * MetricCount * 4.5MBytes
Kyle Brandt
2

In der Dokumentation für statsd geben sie ein Beispiel für eine Richtlinie zur Vorratsdatenspeicherung.

Die Retentionen sind 10s:6h,1min:7d,10min:5y2160 + 10080 + 262800 = 275040 Datenpunkte und ergeben eine Archivgröße von 3,2 MiB .

Unter der Annahme einer linearen Beziehung wären dies ungefähr 12,2 Bytes pro Datenpunkt .

AndreKR
quelle
ops-school.readthedocs.org/en/latest/monitoring_201.html (Zeitstempel, Wert) Paare werden als langer und doppelter Wert gespeichert und verbrauchen 12 Bytes pro Paar. Der 0.2-Unterschied liegt wahrscheinlich am Overhead der Datei-Metadaten-Informationen ?!
user27465
1

Keine direkte Erfahrung mit Graphite, aber ich stelle mir die gleiche Logik vor, die wir für Cacti verwendet haben, oder irgendetwas anderes, das für RRD oder Time-Rollover gilt.

Die schnelle Antwort lautet: "Wahrscheinlich nicht so viel Platz, wie Sie für nötig halten."

Die lange Antwort beinhaltet einige ortsspezifische Mathematik. Für unser Überwachungssystem (InterMapper) berechne ich die Aufbewahrungsfristen, Auflösungen und die Datenpunktgröße, multipliziere sie und füge Overhead hinzu.

Als Beispiel verwende ich Speicherplatz - wir speichern Zahlen mit einer Genauigkeit von 5 Minuten für 30 Tage, einer Genauigkeit von 15 Minuten für weitere 60 Tage und einer stündlichen Genauigkeit für weitere 300 Tage, und wir verwenden eine 64 -bit (8 Byte) Ganzzahl zum Speichern:

  • 21600 Proben insgesamt, aufgeschlüsselt nach:
    • 8640 Proben für die Präzision von 30 Tagen und 5 Minuten
    • 5760 Proben für die Präzision von 60 Tagen und 15 Minuten
    • 7200 Proben für eine Genauigkeit von 300 Tagen und einer Stunde

Bei 8 Bytes pro Sample, das sind ungefähr 173 KB, zuzüglich eines gesunden Overheads für die Speicherindizierung und dergleichen, beträgt dieser für die Datennutzung einer Partition ungefähr 200 KB (ein Fehler, der zu einer Überschätzung neigt).

Anhand der Basismetriken kann ich eine durchschnittliche Größe "pro Computer" ermitteln (10 Festplattenpartitionen, Auslagerungsspeicher, RAM, Lastdurchschnitt, Netzwerktransfer und einige andere Dinge) - entspricht etwa 5 MB pro Computer.

Ich addiere auch gesunde 10% zu der endgültigen Zahl und rechne auf, sodass ich die Dinge mit 6 MB pro Maschine dimensioniere.

Dann schaue ich mir die 1 TB Speicherplatz an, die ich zum Speichern von Metrikdaten für Diagramme zur Verfügung habe, und sage: "Ja, mir geht in meinem Leben wahrscheinlich nicht der Speicherplatz aus, es sei denn, wir wachsen sehr stark!" :-)

voretaq7
quelle
1
Um eine Zahl aus der Praxis herauszuholen, mit meinen Produktionsaufbewahrungsrichtlinien (9 Monate bei 5 Minuten; 1 Jahr pro Stunde; 5 Jahre pro Tag) und ungefähr 20 Maschinen mit jeweils ~ 20 8-Byte-Metriken plus Warnung / Alarm / critical / outage Ereignishistorien für 5 Jahre Ich verwende 1,5 GB Festplattenspeicher. Das ist, wenn InterMapper alles in eine Postgres-Datenbank einfügt. Also nochmal - die schnelle Antwort ist "Wahrscheinlich nicht so viel Platz, wie Sie denken, dass Sie brauchen" :-)
voretaq7
Ja, diese Mathematik ist unkompliziert. Ich schaue mir nur genauer an, wie Graphite seine Daten speichert - kann im Maßstab große Unterschiede bewirken. Das einzige, was ich gefunden habe, ist, dass es laut Dokumentation nicht sehr platzsparend ist (wahrscheinlich, weil es auf ziemlich aggressive Rollups ankommt).
Kyle Brandt
Whisper (das Speicher-Back-End, das Graphite verwendet) verfügt über einige eingebaute Objekte zum Kauen im Weltraum - diese Seite haben Sie wahrscheinlich bereits gesehen. Der Abschnitt "Überlappende Zeiträume für Archive" fällt mir auf, weil die Archive größer sind als in den obigen Beispielen, weil sie alle auf den Beginn der Zeit zurückgehen (das 60-Tage-Archiv ist tatsächlich 90 Tage lang; das 300-Tage-Archiv ist 390 Tage lang). Whisper speichert außerdem einen Zeitstempel (4 oder 8 Byte) für jeden Datenpunkt, der ebenfalls hinzugefügt werden muss. Sieht aber nicht knifflig aus, nur aufgebläht :)
voretaq7
0

Ich habe 70 Knoten, die viele Daten erzeugen. Mit Carbon / Whisper erstellte ein Knoten allein 91k Dateien (der Knoten generiert mehrere Schemata mit jeweils mehreren Zählern und variablen Feldern, die auswählbar sein müssen, z. B .: (Knotenname). (Schema). (Zähler). (Unterzähler). (Etc )....und so weiter).

Dies lieferte die Granularität, die ich brauchte, um jedes gewünschte Diagramm zu zeichnen. Nachdem ich das Skript zum Auffüllen der verbleibenden 69 Knoten ausgeführt hatte, hatte ich 1,3 TB Daten auf der Festplatte. Und das sind nur 6 Stunden Daten / Knoten. Was ich bekomme, ist die tatsächliche flache CSV-Datei für 6 Stunden im Wert von Daten über 230 MB / Knoten. 70 Knoten sind ~ 16 GB Daten. Mein Speicherschema war 120s: 365d.

Ich bin relativ neu in Datenbanken, daher kann es sein, dass ich etwas falsch mache, aber ich schätze, es ist der gesamte Aufwand für jede Stichprobe.

Es war also ein lustiges Experiment, aber ich halte es nicht für sinnvoll, Flüstern für die Art von Daten zu verwenden, die ich speichere. MongoDB scheint eine bessere Lösung zu sein, aber ich muss herausfinden, wie man es als Backend für Grafana verwendet.

musca999
quelle