🥇Nicht nur New Relic: Ein Blick auf Datadog und Atatus

In der SRE-/DevOps-Community überrascht es niemanden, dass irgendwann ein Kunde (oder ein Monitoring-System) auftaucht und verkündet, dass "alles verloren ist": die Website funktioniert nicht, Zahlungen gehen nicht durch, das Leben ist trist... So sehr man in solch einer Situation helfen möchte, ist es oft sehr schwierig, ohne ein einfaches und verständliches Tool zu agieren. Oft versteckt sich das Problem im Code der Anwendung selbst – es braucht nur etwas Lokalisierung.

In guten wie in schlechten Zeiten...

Es ist so gekommen, dass wir New Relic schon seit langem sehr schätzen. Es ist nach wie vor ein hervorragendes Tool zur Überwachung der Anwendungsleistung und ermöglicht das Monitoring einer Mikroservice-Architektur (durch seinen Agenten) und noch vieles mehr. Alles könnte wunderbar sein, wenn da nicht die Änderungen in der Preispolitik des Dienstes wären: seine Kosten sind seit 2013 um über 3 Mal gestiegen. Zudem ist seit letztem Jahr für den Erhalt eines Testkontos die Kommunikation mit einem persönlichen Manager erforderlich, was die Präsentation des Produkts für potenzielle Kunden erschwert.

Eine gängige Situation: New Relic wird nicht ständig benötigt, sondern nur dann in Anspruch genommen, wenn Probleme auftreten. Dennoch muss man regelmäßig für die Dienste zahlen (140 USD pro Server und Monat), und in einer automatisch skalierenden Cloud-Infrastruktur summieren sich die Kosten schnell. Obwohl es die Möglichkeit "Pay-As-You-Go" gibt, erfordert die Aktivierung von New Relic einen Neustart der Anwendung, was zur Behebung der ursprünglichen Problemstellung führen kann. Kürzlich hat New Relic einen neuen Tarif mit dem Namen Essentials, eingeführt, der auf den ersten Blick eine vernünftige Alternative zum Professional-Tarif zu sein scheint... Bei näherer Betrachtung stellte sich jedoch heraus, dass einige wichtige Funktionen fehlen (insbesondere fehlen die Key Transactions, ,, Cross Application Tracing).

und

Distributed Tracing

). Daher haben wir darüber nachgedacht, eine günstigere Alternative zu suchen, und unsere Wahl fiel auf die beiden Dienste Datadog und Atatus. Warum gerade diese? unseren Bedürfnissen:

integrierte und umfassende Unterstützung für PHP-Anwendungen (der Technologie-Stack unserer Kunden ist sehr vielfältig, aber dies ist eindeutig der Führer, wenn es darum geht, eine Alternative zu New Relic zu finden);
bezahlbarer Preis (unter 100 USD pro Monat für das Hosting);
automatische Instrumentierung;
Integration mit Kubernetes;
Ähnlichkeit mit der Benutzeroberfläche von New Relic – ein deutlicher Vorteil (da unsere Ingenieure daran gewöhnt sind).

Deshalb haben wir in der ersten Auswahlphase mehrere andere beliebte Lösungen ausgeschlossen, darunter:

Tideways, AppDynamics und Dynatrace – aufgrund der Kosten;
Stackify – in Russland gesperrt und zeigt viel zu wenige Daten an.

Die folgende Artikelstruktur sieht vor, dass zuerst die in Betracht gezogenen Lösungen kurz vorgestellt werden, gefolgt von unseren typischen Interaktionen mit New Relic und unseren Erfahrungen/Eindrücken beim Ausführen ähnlicher Abläufe in anderen Diensten.

Vorstellung ausgewählter Wettbewerber

Über New Relic, den hat wahrscheinlich jeder schon gehört? Dieser Dienst begann seine Entwicklung vor mehr als 10 Jahren, im Jahr 2008. Wir nutzen ihn aktiv seit 2012 und hatten keine Probleme bei der Integration einer wirklich großen Anzahl von Anwendungen in PHP, Ruby und Python; zudem haben wir Erfahrungen mit der Integration von C# und Go. Die Anbieter des Dienstes haben Lösungen für die Überwachung von Anwendungen, Infrastruktur, das Tracking von Microservices-Infrastrukturen entwickelt, es gibt benutzerfreundliche Anwendungen für Endgeräte und vieles mehr.

Allerdings arbeitet der New Relic Agent mit proprietären Protokollen und unterstützt kein OpenTracing. Für eine erweiterte Instrumentierung müssen spezifische Anpassungen für New Relic vorgenommen werden. Schließlich hat die Unterstützung für Kubernetes derzeit noch experimentellen Status.

Entwickelt seit 2010 Datadog Im Vergleich zu New Relic zeigt sich, dass es in Kubernetes-Umgebungen deutlich interessanter ist. Es unterstützt die Integration mit NGINX Ingress, das Protokollieren von Logs sowie die Protokolle statsd und OpenTracing, was es ermöglicht, Benutzeranfragen vom Zeitpunkt der Verbindung bis zum Abschluss nachverfolgen und die entsprechenden Logs sowohl auf der Server- als auch auf der Consumer-Seite finden zu können.

Bei der Nutzung von Datadog haben wir festgestellt, dass es manchmal die Karte der Mikrodienste falsch erstellt hat und einige technische Mängel aufwies. Beispielsweise erkannte es den Servicetyp nicht korrekt (es interpretierte Django alsCaching-Service) und verursachte 500er Fehler in der PHP-Anwendung, die die beliebte Bibliothek Predis verwendete.

Atatus ist das neueste Tool; der Dienst wurde 2014 gestartet. Sein Marketingbudget steht eindeutig im Schatten der genannten Konkurrenten, und Erwähnungen sind deutlich seltener. Dennoch ähnelt das Tool selbst sehr New Relic, sowohl in den Funktionen (APM, Browser-Monitoring usw.) als auch im Erscheinungsbild.

Ein wesentlicher Nachteil ist die Unterstützung lediglich für Node.js und PHP. Andererseits ist sie deutlich besser implementiert als bei Datadog. Im Gegensatz zu Letzterem erfordert Atatus keine Änderungen an den Anwendungen oder das Setzen zusätzlicher Markierungen im Code.

So arbeiten wir mit New Relic

Lassen Sie uns nun klären, wie wir New Relic normalerweise verwenden. Angenommen, wir haben ein Problem, das gelöst werden muss:

Auf dem Diagramm ist leicht zu erkennen ein Anstieg — schauen wir uns diesen näher an. In New Relic sind für die Webanwendung sofort die Web-Transaktionen ausgewählt, im Leistungsdiagramm sind alle Komponenten aufgeführt, es gibt Panels für die Fehlerquote, die Anforderungsrate... Das Wichtigste ist, dass man direkt von diesen Panels zwischen verschiedenen Teilen der Anwendung navigieren kann (zum Beispiel führt ein Klick auf MySQL zum Datenbankbereich).

Da wir in diesem Beispiel einen Anstieg der Aktivität sehen PHP, klicken wir auf dieses Diagramm und werden automatisch zu Transactions:

Die Liste der Transaktionen, die im Grunde die Controller aus dem MVC-Modell sind, ist bereits nach Am meisten Zeit in Anspruch nehmen, was sehr praktisch ist: Wir sehen sofort, was die Anwendung tut. Hier sind auch Beispiele für langwierige Anfragen vorhanden, die automatisch von New Relic gesammelt werden. Durch das Umschalten der Sortierung lassen sich leicht finden:

der am stärksten belastete Anwendungscontroller;
der am häufigsten angeforderte Controller;
der langsamste der Controller.

Darüber hinaus kann jede Transaktion aufgeklappt werden, um zu sehen, was die Anwendung zum Zeitpunkt der Codeausführung gemacht hat:

Schließlich werden im Anwendung Proben von langen Abfragen (die länger als 2 Sekunden dauern) gespeichert. Hier ist das Dashboard für eine langwierige Transaktion:

Es ist zu sehen, dass zwei Methoden viel Zeit in Anspruch nehmen, und zusammen damit wird die Zeit angezeigt, in der die Anfrage ausgeführt wurde, ihre URI und Domain. Häufig hilft das, die Anfrage in den Logs zu finden. Gehen Sie zu Trace details, um zu sehen, von wo diese Methoden aufgerufen werden:

Und in Database queries – die Datenbankabfragen zu bewerten, die während der Ausführung der Anwendung bearbeitet wurden:

Mit diesem Wissen können wir die Gründe für die Verlangsamung der Anwendung bewerten und gemeinsam mit dem Entwickler eine Strategie zur Problemlösung erarbeiten. In der Praxis bietet New Relic nicht immer ein klares Bild, aber es hilft, die Richtung der Untersuchung zu bestimmen.

langsam PDO::Construct führte uns zu einem seltsamen Verhalten von pgpoll;
Instabilität über die Zeit Memcache::Get deutete auf eine fehlerhafte Konfiguration der virtuellen Maschine hin;
die verdächtig gestiegene Verarbeitungszeit des Templates führte zu einer geschachtelten Schleife mit der Prüfung von 500 Avataren im Objektspeicher;
usw.

Es kommt auch vor, dass anstelle der Ausführung von Code auf dem Hauptbildschirm etwas, das mit externem Datenspeicher zu tun hat, angezeigt wird – egal ob es sich um Redis oder PostgreSQL handelt, sie verstecken sich alle im Tab Datenbanken.

Man kann eine bestimmte Datenbank zur Untersuchung auswählen und die Anfragen sortieren – ähnlich wie im Bereich "Transaktionen". Wechselt man zum Tab für Anfragen, sieht man, wie oft diese Anfrage in jedem der Controller der Anwendung auftritt und wie regelmäßig sie aufgerufen wird. Das ist sehr praktisch:

Ähnliche Daten findet man im Tab Externe Dienste, die Anfragen an externe HTTP-Dienste wie zum Beispiel den Zugriff auf ein Objekt-Storage oder das Senden von Ereignissen an Sentry verbirgt. Inhaltlich ist der Tab identisch mit Databases:

Wettbewerber: Möglichkeiten und Erfahrungen

Jetzt wird es interessant – vergleichen wir die Möglichkeiten von New Relic mit denen der Wettbewerber. Leider konnten wir nicht alle drei Tools mit einer Version der Production-Anwendung testen. Dennoch haben wir versucht, möglichst identische Situationen/Konfigurationen zu vergleichen.

1. Datadog

Datadog begrüßt uns mit einem Dashboard, das eine Wand von Diensten zeigt:

Es versucht, Anwendungen in Komponenten/Mikroservices zu unterteilen, weshalb wir in dem in diesem Beispiel verwendeten Django-Anwendungsbeispiel 2 Verbindungen zu PostgreSQL sehen werden (defaultdb und postgres), sowie Celery und Redis. Die Arbeit mit Datadog erfordert von Ihnen minimale Kenntnisse der MVC-Prinzipien: Sie müssen verstehen, wo die Benutzeranfragen überhaupt ankommen. In der Regel hilft dabei eine Service-Karte:

Übrigens gibt es etwas Ähnliches auch in New Relic:

… dabei ist ihre Karte, meiner Meinung nach, einfacher und verständlicher gestaltet: Sie zeigt nicht die Komponenten einer Anwendung (was sie zu detailliert machen würde, wie im Fall von Datadog), sondern nur spezifische Dienste oder Mikrodienste.

Kehren wir zu Datadog zurück: Aus der Dienstkarte ist ersichtlich, dass die Benutzeranfragen in Django eingehen. Lassen Sie uns zum Django-Dienst wechseln und endlich das sehen, was wir erwartet haben:

Leider gibt es hier standardmäßig kein entsprechendes Diagramm Web-Transaktionszeit, das analog zu dem ist, was wir auf dem Hauptpanel von New Relic sehen. Aber es kann an der Stelle des Diagramms eingestellt werden % der aufgewendeten Zeit. Es genügt, es auf Durchschnittliche Zeit pro Anfrage nach Typ… und schon blickt uns das vertraute Diagramm entgegen!

Warum Datadog ein anderes Diagramm gewählt hat, bleibt uns ein Rätsel. Enttäuschend war auch, dass das System die Benutzerwahl nicht speichert (anders als beide Wettbewerber), weshalb nur die Erstellung benutzerdefinierter Dashboards hilft.

Dafür erfreute die Möglichkeit in Datadog, von diesen Diagrammen auf Metriken der verbundenen Server zu wechseln, Protokolle zu lesen und die Auslastung der Webserver-Handler (Gunicorn) zu bewerten. Alles fast wie bei New Relic… und sogar etwas mehr (Protokolle)!

Unter den Grafiken befinden sich die Transaktionen, die vollständig mit New Relic identisch sind:

In Datadog werden Transaktionen als Ressourcenbezeichnet. Controller können nach der Anzahl der Anfragen, der durchschnittlichen Antwortzeit und der maximalen erforderlichen Zeit für den gewählten Zeitraum sortiert werden.

Eine Ressource kann ausgeklappt werden, um alles zu sehen, was wir bereits in New Relic betrachtet haben:

Es gibt sowohl Statistik zur Ressource als auch eine zusammenfassende Liste interner Aufrufe und Beispiele für Anfragen, die nach dem Antwortcode sortiert werden können... Übrigens, diese Sortierfunktion kam bei unseren Ingenieuren sehr gut an.

Jedes Beispiel einer Ressource in Datadog kann aufgeklappt und untersucht werden:

Es werden die Abfrageparameter angezeigt, ein zusammenfassendes Diagramm über die benötigte Zeit für jeden der Komponenten und ein Wasserfalldiagramm, in dem die Reihenfolge der Aufrufe sichtbar ist. Zudem kann auf die Baumansicht des Wasserfalldiagramms umgeschaltet werden:

Und das Interessanteste – die Überwachung der Last des Hosts, auf dem die Anfrage ausgeführt wurde, sowie die Ansicht der Anfragenprotokolle.

Tolle Integration!

Es könnte die Frage aufkommen, wo die Registerkarten Datenbanken und Externe Dienstesind, wie bei New Relic. Hier gibt es keine: Da Datadog die Anwendung in Komponenten zerlegt, wird PostgreSQL als als separater Dienst, während statt External Services gesucht werden sollte aws.storage (das Gleiche gilt für jeden anderen externen Dienst, auf den die Anwendung zugreifen kann).

Hier ist ein Beispiel mit postgres:

Im Grunde gibt es alles, was wir wollten:

Es ist klar, aus welchem «Dienst» die Anfrage kam.

Es sei daran erinnert, dass Datadog hervorragend mit NGINX Ingress integriert ist und eine durchgehende Tracing-Möglichkeit vom Moment des Eintreffens der Anfrage im Cluster bietet, sowie die Annahme von statsd-Metriken, das Sammeln von Logs und Host-Metriken ermöglicht.

Ein großer Vorteil von Datadog ist, dass der Preis sich zusammensetzt aus Infrastruktur-Monitoring, APM, Log Management und Synthetics Test, d.h. der Plan kann flexibel angepasst werden.

2. Atatus

Das Atatus-Team behauptet, dass ihr Dienst – „so gut wie New Relic, aber besser“. Mal sehen, ob das tatsächlich so ist.

Die Titelleiste sieht tatsächlich ähnlich aus, aber es war nicht möglich, die im Anwendung verwendeten Redis und memcached zu identifizieren.

APM wählt standardmäßig alle Transaktionen aus, wobei in der Regel nur Web erforderlich ist. Wie bei Datadog gibt es keine Möglichkeit, vom Hauptdashboard zum gewünschten Dienst zu wechseln. Darüber hinaus befinden sich die Transaktionen in der Liste nach den Fehlern, was für APM nicht besonders logisch erscheint.

Bei den Transaktionen von Atatus ist alles sehr ähnlich zu New Relic. Ein Nachteil ist, dass die Dynamik für jeden Controller nicht sofort sichtbar ist. Man muss sie in der Controller-Tabelle suchen und nachsortieren nach Meiste verbrachte Zeit:

Die gewohnte Liste der Controller ist im Tab Erforschen:

Diese Tabelle erinnert ein wenig an Datadog und gefällt besser als die entsprechende in New Relic.

Jede Transaktion kann ausgeklappt werden, um zu sehen, womit die Anwendung beschäftigt war:

Das Dashboard erinnert ebenfalls eher an Datadog: Es gibt die Anzahl der Anfragen und eine allgemeine Sicht auf die Aufrufe. Das obere Panel bietet einen Tab mit Fehlern HTTP-Fehler und Beispiele für langsame Anfragen Sitzungs-Trace:

Wenn man in die Transaktion geht, sieht man ein Beispiel für den Trace, erhält eine Liste der Anfragen an die Datenbank und kann die Anfrage-Header einsehen. Alles ist ähnlich wie bei New Relic:

Im Allgemeinen hat Atatus mit detaillierten Traces überzeugt – ohne die typischen Zusammenführungen von Aufrufen in einen Reminder-Block, wie sie bei New Relic vorkommen:

Allerdings fehlt hier ein Filter, der (wie bei New Relic) ultraschnelle Anfragen (<5 ms) herausfiltert. Auf der anderen Seite hat mir die Anzeige der endgültigen Antwort der Transaktion (erfolgreich oder Fehler) gefallen.

Panel Datenbanken hilft dabei, die Anfragen an externe Datenbanken zu untersuchen, die die Anwendung generiert. Ich möchte daran erinnern, dass Atatus nur PostgreSQL und MySQL gefunden hat, obwohl im Projekt auch Redis und Memcached verwendet werden.

Die Anfragen werden nach gewohnten Kriterien sortiert: Häufigkeit, durchschnittliche Antwortzeit und so weiter. Besonders hervorzuheben ist der Tab mit den langsamsten Anfragen – das ist sehr praktisch. Darüber hinaus stimmen die Daten in diesem Tab für PostgreSQL mit den Daten aus der Erweiterung überein. pg_stat_statements – ein hervorragendes Ergebnis!

Tab Externe Anfragen ist vollständig identisch mit Datenbanken.

Fazit

Beide vorgestellten Werkzeuge haben sich als APM gut bewährt. Jedes von ihnen kann das notwendige Minimum bieten. Unsere Eindrücke zusammengefasst:

Datadog

Vorteile:

komfortliche Preisstruktur (APM kostet 31 USD pro Host);
hat sich hervorragend mit Python bewährt;
Integration mit OpenTracing möglich;
Integration mit Kubernetes;
Integration mit NGINX Ingress.

Nachteile:

der einzige APM, der aufgrund eines Modulf fehler das Anwendungszugriffsproblem verursachte (predis);
schwache automatische Instrumentierung für PHP;
teilweise seltsame Definition von Diensten und deren Zuordnung.

Atatus

Vorteile:

tiefe Instrumentierung für PHP;
ähnliches Benutzerinterface wie New Relic.

Nachteile:

funktioniert nicht auf älteren Betriebssystemen (Ubuntu 12.05, CentOS 5);
unzureichende Automatisierungstools;
unterstützt nur zwei Programmiersprachen (Node.js und PHP);
langsame Benutzeroberfläche.

Angesichts des Preises von Atatus von 69 USD pro Monat für den Server würden wir eher Datadog verwenden, das hervorragend auf unsere Bedürfnisse (Webanwendungen in K8s) zugeschnitten ist und viele nützliche Funktionen bietet.