Hochverfügbare, über das Internet zugängliche und skalierbare Bereitstellung von Statistik und Graphit


17

Ich möchte statsd / graphite so einrichten, dass ich JS-Apps protokollieren kann, die auf HTML-Geräten ausgeführt werden (dh nicht in einer geschlossenen LAN-Umgebung und möglicherweise mit einer großen Menge an eingehenden Daten, die ich nicht direkt kontrolliere).

Meine Einschränkungen:

  • Einstiegspunkt muss HTTP sprechen: Dies wird durch einen einfachen HTTP-zu-UDP-statsd-Proxy gelöst (zB httpstatsd auf github)
  • muss dem Ausfall eines einzelnen Servers widerstehen (um Murphys Gesetz zu bekämpfen :)
  • muss horizontal skalierbar sein: webscale, baby! :)
  • Architektur sollte so einfach (und billig) wie möglich gehalten werden
  • Meine Server sind virtuelle Maschinen
  • Die Datendateien werden auf einer Filer-Appliance (mit NFS) gespeichert.
  • Ich habe TCP / UDP-Hardware-Load-Balancer zur Verfügung

Kurz gesagt, der Datenpfad: [client] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [graphite] - (nfs) -> [filer]

Meine bisherigen Ergebnisse:

  • Das Skalieren des http2statsd-Teils ist einfach (zustandslose Daemons)
  • Das Skalieren des statistischen Teils scheint nicht einfach zu sein (ich denke, ich würde mit inkohärenten Werten in Graphit für aggregierte Daten wie Summe, Durchschnitt, Minimum, Maximum ... enden). Es sei denn, der HTTP-Daemon führt ein konsistentes Hashing durch, um die Schlüssel zu speichern. Vielleicht eine Idee ... (aber dann gibt es die HA-Frage)
  • Das Skalieren des Graphitteils kann durch Splittern (unter Verwendung von Carbon-Relais) erfolgen (dies löst jedoch auch nicht die HA-Frage). Offensichtlich sollten nicht mehrere Whisper-Instanzen dieselbe NFS-Datei schreiben.
  • Das Skalieren des Filer-Teils ist nicht Teil der Frage (aber je weniger IO, desto besser :)
  • Das Skalieren der Web-App ist offensichtlich (obwohl ich sie noch nicht getestet habe), da sie nur die freigegebenen NFS-Daten lesen

Ich habe mich also gefragt, ob jemand Erfahrungen und bewährte Methoden für eine solide Bereitstellung von Statistik- / Graphitdaten gesammelt hat.


Wenn sie die Kommentare in Etsys Blogpost über StatsD lesen, schreiben sie, dass sie StatsD alle 10 Sekunden mit 10.000 bis 30.000 Metriken füttern. Ich würde vorschlagen, einen http2statsd-Client mit einem statsd-Server zu verknüpfen und zu verschieben, wenn die Anzahl der an statsd gesendeten Metriken zu einem Engpass wird.
pkhamre

Hast du das am Ende umgesetzt? Wenn ja, könnten Sie Einzelheiten mitteilen?
gf_

Antworten:


1

Es gibt einen statsd-Proxy mit konsistentem Hashing, der es ermöglicht, den statsd-Verkehr auf mehrere statsd-Aggregatoren zu verteilen, wobei jeder einen eigenen Satz von Metriknamen verwendet. Es ist ein entscheidendes Skalierbarkeitselement in Ihrer Architektur, mit dem Sie statistische Prozesse skalieren können.

Graphit ist auch schwierig, aber hoffentlich brauchen Sie keine unendliche Skala und können nur feine Scherben durch Service oder einen anderen statischen Parameter ausführen.

Der schwierigste Teil ist das Skalieren von Webanwendungen, und es hängt stark von den häufigsten Grafikabfragen ab. Sie können jedoch immer Daten für schwierigste Diagramme vorab aggregieren und den größten Teil der Last entfernen.

Ich benutze HostedGraphite schon seit einiger Zeit, um all diese Schmerzen zu vermeiden. Diese Leute haben ihr eigenes Riak-Backend für Carbon implementiert und dort die gesamte Skalierung vorgenommen.

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.