Skalierung statsd mit mehreren Servern

Question

Ich lege eine Architektur, wo wir statsd und Graphit verwenden werden. Ich verstehe, wie Graphit funktioniert und wie ein einzelner statsd Server damit kommunizieren kann. Ich frage mich, wie die Architektur und Einrichtung für das Skalieren von statsd-Servern funktionieren würde. Würden Sie mehrere Knoten-statsd-Server haben und dann einen zentralen statsd-Server, der zu graphite übergeht? Ich konnte nichts über die Skalierung von Statistiken finden, und jede Idee, wie man mehrere statsd-Server haben könnte, wäre willkommen.

Answer 1

Ich habe das gleiche Problem im Moment. Ein naives Load-Balancing zwischen mehreren statsds funktioniert offensichtlich nicht, da Keys mit demselben Namen in verschiedenen statsds landen würden und somit falsch aggregiert würden.

Aber es gibt ein paar Optionen für die in einer Umgebung mit statsd, die maßstabs benötigt:

für Zähler Metriken

• Verwendung clientseitige Probenahme, wie sie in der statsd Dokumentation beschrieben (dh anstatt jeden senden Ereignis zu statsd, sende nur jedes 10. Ereignis und mache statsd multipliziere es mit 10). Der Nachteil ist, dass Sie für jede Ihrer Metriken manuell eine geeignete Abtastrate festlegen müssen. Wenn Sie zu wenige Werte erfassen, werden Ihre Ergebnisse ungenau. Wenn Sie zu viel probieren, werden Sie Ihre (einzelne) statsd-Instanz beenden.

• Erstellen Sie einen benutzerdefinierten Lastenausgleich, der nach metrischen Namen in verschiedene statsds zerlegt, um das Problem der fehlerhaften Aggregation zu umgehen. Jeder von ihnen könnte direkt an Graphite schreiben.

• Erstellen Sie einen statsd-Client, der Ereignisse lokal zählt und sie nur als Aggregat an statsd sendet. Dies reduziert den Datenverkehr auf statsd erheblich und macht ihn auch konstant (solange Sie keine weiteren Server hinzufügen). Solange der Zeitraum, in dem Sie die Daten an statsd senden, wesentlich kleiner ist als die eigene flush-Periode von statsd, sollten Sie auch ähnlich genaue Ergebnisse erhalten.

• Variation des letzten Punktes, den ich mit großem Erfolg in der Produktion umgesetzt habe: eine erste Schicht aus mehrere verwenden (in meinem Fall lokal) statsds, was wiederum alle Aggregate in einen zentralen statsd, die dann im Gespräch mit Graphit. Die erste Schicht von statsds müsste eine viel kleinere Spülzeit haben als die zweite. Um dies zu tun, benötigen Sie ein statsd-to-statsd-Backend. Da ich genau dieses Problem konfrontiert, schrieb ich eine, die als netzwerk effizient wie möglich zu sein, versucht: https://github.com/juliusv/ne-statsd-backend

Wie es ist, wurde statsd leider nicht eine überschaubare Art und Weise zu skalieren in entworfen (nein, I don‘ t siehe Anpassen der Abtastraten manuell als "handhabbar". Aber die oben genannten Problemumgehungen sollten Ihnen helfen, wenn Sie daran festhalten.

Answer 2

Wenn Sie Zugang zu einem Hardware Load Balancer wie einem F5 BigIP haben (ich könnte mir vorstellen, dass es OSS Software-Implementierungen gibt) und den Hostnamen jedes Hosts in Ihren Metriken enthalten (dh Sie zählen Dinge wie " appname.servername.foo.bar.baz "und aggregieren sie auf der Graphit-Ebene) können Sie den Affinitäts-Load-Balancing der Quelladresse verwenden - er sendet den gesamten Datenverkehr von einer Quelladresse zum selben Zielknoten (innerhalb eines angemessenen Zeitlimits). Solange also jeder Metrikname nur von einem Quellenhost stammt, wird dies das gewünschte Ergebnis erzielen.

Answer 3

Die meisten der Implementierungen ich pro Server-Metriken sah, wie: <env>.applications.<app>.<server>.<metric>

Mit diesem Ansatz Sie lokale statsd Instanzen auf jedes Feld haben können, tun, um die UDP-Arbeit vor Ort und lassen statsd seine Aggregate veröffentlichen Graphit.

Wenn Sie wirklich pro-Server-Metriken nicht brauchen, haben Sie zwei Möglichkeiten:

1. Kombinieren verwandten Metriken in der Visualisierungsschicht (zB: by configuring graphiti to do so)
2. Verwenden Kohlenstoff Aggregation take care of that