Prometheus vs StatsD für die Erfassung von Metriken

Misst Ihren Gesundheitsindikator

StastD war bereits seit fast einem Jahrzehnt für die Erfassung von Metriken bekannt. Ursprünglich von Flickr in der Zeit der flachen Metriken (Graphite) usw. populär gemacht. Eine wichtige Entwicklung in der Sammlung und Analyse von Metriken ist das Kennzeichnen von Metriken. Ich würde sagen, dass das Kennzahlen-Tagging den gesamten Kennzahlenbereich mit einer besseren Struktur, Filterung und Gruppierung nach revolutioniert hat. Zur Verwendung von Tags in StatsD wird heute häufig das dogstatsd-Protokoll (Evolution des plain statsd-Protokolls mit Tags-Unterstützung) verwendet.

Prometheus ist sehr neu auf dem Markt für Metriken, wächst jedoch sehr schnell und mit den damit verbundenen cncf.io-Boostern. In Anbetracht der Idee, dass Prometheus vom ersten Tag an von Google abstammt, unterstützte Prometheus Tags.

StatsD / Dogstatsd ist nur ein Protokoll, in dem das prometheus-Projekt eine Protokoll-, Erfassungs- und Zeitreihendatenbank enthält. Prometheus hat auch einen Alarmmanager. Ein Prometheus-äquivalentes Beispiel-Setup würde StatsD Server (Telegraf StatsD), Zeitreihendatenbank (InfluxDB) und Kapacitor für die Alarmierung beinhalten.

Vorteile von StatsD:

  • Die Zeit für einen Kickstart ist sehr kurz, da Sie lediglich die IP-Adresse, den Port und die Client-Bibliothek Ihres Servers kennen müssen.
  • Perzentile werden auf der Serverseite berechnet, damit wir aggregierte Ansichten mehrerer Instanzen desselben Dienstes erfassen können.
  • Perzentile und Histogramme werden in der Clientanwendung serverseitig mit relativ geringerem Overhead berechnet.
  • Überträgt alle Daten über das UDP-Protokoll, wodurch Netzwerkverbindungsprobleme vermieden werden, die die gesamte Anwendung zum Erliegen bringen.
  • Ein kurzlebiger Prozess kann leicht Metriken senden, da StatsD Push-basierte Systeme sind.
  • Verwendet relativ weniger Speicher, da die Metriken sofort auf den Server übertragen werden.
  • Der Implementierungsaufwand von Entwicklerseite ist geringer.

Nachteile von StatsD:

  • Wenn auf dem StatsD-Server eine Überlastung vorliegt, verlieren wir möglicherweise die Metriken, wenn die Metriken über UDP transportiert werden.
  • Das Volumen des statistischen Verkehrs nimmt mit dem Volumen Ihrer Instrumente zu (wir können Stichproben verwenden, um dies zu reduzieren).
  • Wenn Ihr StatsD-Verkehrsaufkommen nicht auf einen einzelnen Server passt, ist die Perzentilberechnung möglicherweise nicht korrekt, wenn man bedenkt, dass Perzentile jetzt auf mehreren Servern berechnet werden.
  • Sie müssen mehrere Werkzeuge (Lagerung, Alarmierung) zusammennähen, damit es funktioniert.

Vorteile von prometheus:

  • Langfristige Realisierbarkeit des Projekts, da es unter cncf und unter linux steht.
  • Metrik-Tags werden erstklassig unterstützt.
  • Jede Metrik wird mit einer Beschreibung geliefert, die das Verständnis der Metriken erleichtert.
  • Sie können Metriken auf Serverebene auf den lokalen Endpunkten in der Regel * http: // localhost: 8888 / metrics * (Google nennt es zPages) der Anwendung anzeigen.
  • Wenn der prometheus-Server ausfällt, gehen keine App-Messdaten verloren, da alle Daten im Anwendungsspeicher gespeichert sind.
  • Messprotokoll, Speicherung, Erfassung und Alarmierung sind sofort einsatzbereit.
  • Der Datenverkehr für die Erfassung von Metriken steigt nicht proportional zum Anstieg des Anwendungsdatenverkehrs, da die Daten in festen Intervallen (normalerweise 10 Sekunden) gelöscht werden.
  • Die verfügbare Anwendung kann leicht ermittelt werden, indem aus der Tatsache abgeleitet wird, dass die Anwendung nicht verfügbar ist, wenn die Metriken nicht verschrottet werden können.

Nachteile von prometheus:

  • Da es sich bei prometheus um ein Pull-basiertes System zur Erfassung von Metriken handelt, ist eine Diensterkennung (consul oder etcd) erforderlich, um alle Prometheus-Endpunkte der Anwendung zu ermitteln.
  • Die Berechnung der Perzentile liefert möglicherweise kein Gesamtbild, da die Perzentile auf jeder Instanzebene und nicht auf globaler Ebene berechnet werden.
  • Es wird mehr Speicher verwendet, da die Metriken lokal im Anwendungsspeicher gespeichert werden.
  • Für kurzlebige Prozesse ist ein Push-Gateway erforderlich, um Metriken zu pushen.
  • Die erforderlichen Implementierungs- und Entwicklerkenntnisse sind hoch.

Grafana ist in beiden Fällen das Werkzeug zur Visualisierung von Defacto-Metriken :)

Auch wenn ich versucht bin, meine Meinung hier zu schreiben, überlasse ich Ihnen das Fazit :)

Weitere Informationen zu Pull vs Push finden Sie hier.

Lassen Sie mich Ihre Gedanken in den Kommentaren wissen. Du solltest mir auf Twitter @SkyRocknRoll folgen