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.