In der SRE-/DevOps-Community ist es keine Überraschung, dass eines Tages ein Kunde (oder ein Überwachungssystem) auftaucht und berichtet, dass "alles verloren ist": die Website funktioniert nicht, Zahlungen werden nicht verarbeitet, das Leben ist vergänglich... So sehr man in einer solchen Situation helfen möchte, ist es ohne ein einfaches und verständliches Tool oft sehr schwierig. Häufig versteckt sich das Problem im Code der Anwendung selbst — es gilt nur, es zu lokalisieren.
In guten wie in schlechten Zeiten...
Wir haben uns bereits vor langer Zeit sehr in New Relic verliebt. Es war und ist ein hervorragendes Tool zur Überwachung der Anwendungsleistung und ermöglicht es auch, die mikroservicebasierte Architektur (mit Hilfe seines Agents) zu instrumentalisieren und vieles mehr. Und alles hätte wunderbar sein können, wenn da nicht die Änderungen in der Preisgestaltung des Dienstes wären: sein Kosten um mehr als das Dreifache gestiegen. Darüber hinaus ist seit letztem Jahr für den Erhalt eines Testkontos der Kontakt zu einem persönlichen Manager erforderlich, was die Präsentation des Produkts an potenzielle Kunden erschwert.
Eine typische Situation: New Relic wird nicht "dauerhaft benötigt", man denkt nur daran, wenn Probleme auftreten. Aber bezahlen muss man trotzdem regelmäßig (140 USD pro Server pro Monat), und in einer automatisch skalierenden Cloud-Infrastruktur summieren sich diese Beträge schnell. Auch wenn es die Möglichkeit von "Pay-As-You-Go" gibt, würde die Aktivierung von New Relic einen Neustart der Anwendung erfordern, was zum Verlust der problematischen Situation führen kann, wegen der alles angestoßen wurde. Vor nicht allzu langer Zeit hat New Relic einen neuen Tarif eingeführt — , — der auf den ersten Blick als vernünftige Alternative zu Professional aussieht... aber bei genauerer Betrachtung stellte sich heraus, dass einige wichtige Funktionen fehlen (insbesondere fehlen Schlüsseltransaktionen, Cross Application Tracing, Distributed Tracing).
Infolgedessen haben wir darüber nachgedacht, eine kostengünstigere Alternative zu suchen, und unsere Wahl fiel auf die beiden Dienste Datadog und Atatus. Warum gerade diese?
Über die Wettbewerber
Ich möchte gleich klarstellen, dass es auf dem Markt auch andere Lösungen gibt. Wir haben sogar Open Source-Optionen in Betracht gezogen, aber nicht jeder Kunde hat die Ressourcen, um Lösungen aus der Kategorie Self-Hosted zu hosten... — zudem erfordern sie zusätzliche Wartung. Das von uns gewählte Duo stellte sich als die am nächsten kommende Lösung zu unseren Bedürfnissen heraus.:
- integrierte und umfassende Unterstützung für PHP-Anwendungen (der Technologie-Stack unserer Kunden ist sehr vielfältig, aber dies ist ein klarer Marktführer, wenn es um Alternativen zu New Relic geht);
- erschwingliche Kosten (weniger als 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).
Daher haben wir in der ersten Auswahlrunde mehrere andere beliebte Lösungen ausgeschlossen, insbesondere:
- Tideways, AppDynamics und Dynatrace — aufgrund der Kosten;
- Stackify — in Russland blockiert und zeigt zu wenige Daten an.
Der folgende Artikel ist so aufgebaut, dass zunächst die betrachteten Lösungen kurz vorgestellt werden, danach werde ich über unsere typische Interaktion mit New Relic und unsere Erfahrungen/Eindrücke bei der Durchführung ähnlicher Operationen in anderen Diensten berichten.
Vorstellung der ausgewählten Mitbewerber
Über , wahrscheinlich hat jeder schon davon gehört? Dieser Dienst begann seine Entwicklung vor über 10 Jahren, im Jahr 2008. Wir nutzen ihn aktiv seit 2012 und hatten keine Probleme mit der Integration einer wirklich großen Anzahl von Anwendungen in PHP, Ruby und Python, zudem haben wir Erfahrungen mit der Integration in C# und Go. Die Serviceanbieter haben Lösungen zur Anwendungsüberwachung, zur Infrastrukturüberwachung, zur Nachverfolgung von Microservices-Infrastrukturen entwickelt, benutzerfreundliche Anwendungen für Endgeräte erstellt und vieles mehr.
Allerdings arbeitet der New Relic-Agent nach proprietären Protokollen und unterstützt kein OpenTracing. Für erweiterte Instrumentierung sind Anpassungen speziell für New Relic erforderlich. Schließlich hat die Unterstützung für Kubernetes bisher einen experimentellen Status.
Die Entwicklung begann im Jahr 2010 ist in Bezug auf die Anwendung in Kubernetes-Umgebungen deutlich attraktiver als New Relic. Insbesondere unterstützt es die Integration mit NGINX Ingress, das Sammeln von Protokollen, die Protokolle statsd und OpenTracing, was es ermöglicht, Benutzeranfragen vom Zeitpunkt der Verbindung bis zum Abschluss der Arbeit nachzuverfolgen und auch die Protokolle zu diesem Antrag zu finden (sowohl auf der Serverseite als auch auf der Seite der Verbraucher).
Bei der Verwendung von Datadog haben wir festgestellt, dass es manchmal die Microservices-Karte falsch erstellte und einige technische Mängel aufwies. Zum Beispiel erkannte es den Diensttyp nicht richtig (verwechselte Django mit einem Cache-Dienst) und verursachte 500-Fehler in einer PHP-Anwendung, die die beliebte Bibliothek Predis verwendete.
— das jüngste Tool; der Service wurde im Jahr 2014 gestartet. Sein Marketingbudget ist offensichtlich geringer als das der genannten Mitbewerber, und Erwähnungen sind deutlich seltener. Dennoch ähnelt das Tool in vielerlei Hinsicht New Relic, nicht nur in seinen Funktionen (APM, Browserüberwachung usw.), sondern auch im Erscheinungsbild.
Ein wesentlicher Nachteil ist die Unterstützung ausschließlich für Node.js und PHP. Auf der anderen Seite ist die Umsetzung deutlich besser als bei Datadog. Im Gegensatz zu letzterem erfordert Atatus keine Anpassungen an den Anwendungen und keine zusätzlichen Markierungen im Code.
Wie wir mit New Relic arbeiten
Lassen Sie uns nun klären, wie wir normalerweise New Relic verwenden. Angenommen, wir haben ein Problem, das gelöst werden muss:
Auf dem Diagramm ist leicht zu erkennen einen Anstieg — lassen Sie uns diesen analysieren. In New Relic sind für die Webanwendung sofort die Webtransaktionen ausgewählt, im Leistungsdiagramm sind alle Komponenten angegeben, es gibt Panels für die Fehlerquote, die Anfragequote… Was am wichtigsten ist – direkt aus diesen Panels kann man zwischen verschiedenen Teilen der Anwendung navigieren (zum Beispiel führt ein Klick auf MySQL zum Datenbankbereich).
Da wir im betrachteten Beispiel einen Anstieg der Aktivität sehen PHP, klicken wir auf dieses Diagramm und gelangen automatisch zu Transaktionen:
Die Liste der Transaktionen, die im Grunde genommen Controller aus dem MVC-Modell sind, ist bereits nach Am meisten Zeitverbrauchend, was sehr praktisch ist: Wir sehen sofort, womit sich die Anwendung beschäftigt. Hier finden sich auch Beispiele für lange Anfragen, die automatisch von New Relic gesammelt werden. Durch Ändern der Sortierung lässt sich leicht finden:
- der am stärksten beanspruchte Controller der Anwendung;
- der am häufigsten angeforderte Controller;
- der langsamste der Controller.
Darüber hinaus kann man jede Transaktion aufklappen und sehen, womit sich die Anwendung zum Zeitpunkt der Ausführung des Codes beschäftigt hat:
Schließlich speichert die Anwendung Beispiele für Traces von langen Anfragen (die länger als 2 Sekunden benötigen). Hier ist das Panel für eine lange Transaktion:
Man sieht, dass zwei Methoden viel Zeit in Anspruch nehmen, und zugleich wird auch die Zeit angezeigt, zu der die Anfrage ausgeführt wurde, ihr URI und die Domain. Das hilft sehr oft, die Anfrage in den Logs zu finden. Wenn man zu Trace-Detailswechselt, kann man sehen, woher diese Methoden aufgerufen werden:
Und bei Datenbankabfragen — um die Datenbankabfragen zu bewerten, die während der Ausführung der Anwendung durchgeführt wurden:
Mit diesem Wissen können wir die Ursache für die Verlangsamung der Anwendung bewerten und gemeinsam mit dem Entwickler eine Strategie zur Lösung des Problems entwickeln. In der Realität bietet New Relic nicht immer ein klares Bild, hilft jedoch, die Ermittlungsschritte zu wählen:
- langsame
PDO::Constructführte uns zu einer seltsamen Funktion des pgpoll; - Instabilität über die Zeit
Memcache::Getwies auf eine inkorrekte Konfiguration der virtuellen Maschine hin; - Die verdächtig gestiegene Verarbeitungszeit des Templates führte zu einer verschachtelten Schleife mit der Überprüfung der Existenz von 500 Avataren im Objektspeicher;
- und so weiter...
Es kommt auch vor, dass anstelle der Codeausführung auf dem Hauptbildschirm etwas wächst, das mit der externen Datenspeicherung zu tun hat - egal, ob es sich dabei um Redis oder PostgreSQL handelt - sie verbergen sich alle im Tab Datenbanken.
Man kann eine bestimmte Datenbank zur Untersuchung auswählen und die Anfragen sortieren, ähnlich wie im Bereich Transaktionen. Im Anfrage-Tab kann man sehen, wie oft diese Anfrage in jedem der Controller der Anwendung auftaucht, sowie einschätzen, wie häufig sie aufgerufen wird. Das ist sehr praktisch:
Ähnliche Daten enthält der Tab Externe Dienste, der die Anfragen an externe HTTP-Dienste verbirgt, wie z.B. Zugriffe auf den Objektspeicher, das Senden von Ereignissen an Sentry oder Ähnliches. Inhaltlich ist dieser Tab vollständig analog zu Datenbanken:
Wettbewerber: Möglichkeiten und Eindrücke
Jetzt kommt das Interessante - wir vergleichen die Möglichkeiten von New Relic mit dem, was die Wettbewerber bieten. Leider konnten wir nicht alle drei Tools auf einer Version einer funktionierenden Production-Anwendung testen. Dennoch haben wir versucht, so identische Situationen/Konfigurationen wie möglich zu vergleichen.
1. Datadog
Datadog empfängt uns mit einem Dashboard, das eine Wand von Diensten zeigt:
Es versucht, Anwendungen in Komponenten/Mikroservices zu unterteilen; daher werden wir in dem Beispiel-Django-Projekt zwei Verbindungen zu PostgreSQL sehen (defaultdb und in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier), sowie Celery und Redis. Die Arbeit mit Datadog erfordert von Ihnen minimale Kenntnisse der MVC-Prinzipien: Sie müssen verstehen, wohin die Anfragen der Benutzer gelangen. In der Regel hilft dabei eine Service-Karte:
Übrigens gibt es etwas Ähnliches auch in New Relic:
… wobei meiner Meinung nach die Karte einfacher und verständlicher gestaltet ist: Sie zeigt nicht die Komponenten einer Anwendung (was sie übermäßig detailliert macht, wie im Fall von Datadog), sondern nur bestimmte 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 sehen, was wir erwartet haben:
Leider gibt es hier standardmäßig kein Diagramm Web-Transaktionszeit, ähnlich dem, was wir auf dem Haupt-Dashboard von New Relic sehen. Allerdings kann es an der Stelle des Diagramms konfiguriert werden % der aufgewendeten Zeit. Es reicht aus, es auf Durchschnittliche Zeit pro Anfrage nach Typ… und schon blickt uns das vertraute Diagramm an!
Warum Datadog einem anderen Diagramm den Vorzug gegeben hat, bleibt für uns ein Rätsel. Enttäuscht hat uns auch, dass das System die Benutzerwahl nicht speichert (im Gegensatz zu beiden Wettbewerbern), weshalb nur die Erstellung benutzerdefinierter Dashboards hilft.
Überrascht hat uns jedoch die Möglichkeit, in Datadog von diesen Diagrammen auf die Metriken der verbundenen Server zu wechseln, die Protokolle zu lesen und die Last der Webserver-Handler (Gunicorn) zu bewerten. Alles ist fast wie bei New Relic … und sogar ein wenig mehr (Protokolle)!
Unterhalb der Diagramme befinden sich die Transaktionen, die vollständig mit New Relic übereinstimmen:
In Datadog werden Transaktionen Ressourcengenannt. Man kann die Controller nach Anzahl der Anfragen, nach durchschnittlicher Antwortzeit und nach maximaler Aufwandszeit für den gewählten Zeitraum sortieren.
Die Ressource kann aufgeklappt werden, um alles zu sehen, was wir bereits in New Relic gesehen haben:
Sowohl die Statistik zur Ressource als auch eine Übersicht über interne Aufrufe und Beispiele von Anfragen, die nach dem Antwortcode sortiert werden können, sind vorhanden … Übrigens gefällt diese Sortierung unseren Ingenieuren sehr.
Jedes Beispiel einer Ressource in Datadog kann geöffnet und untersucht werden:
Es werden die Parameter der Anfrage, ein zusammenfassendes Diagramm der aufgewendeten Zeit für jede der Komponenten und ein Wasserfalldiagramm angezeigt, in dem die Reihenfolge der Aufrufe sichtbar ist. Außerdem gibt es die Möglichkeit, auf die baumartige Ansicht des Wasserfalldiagramms umzuschalten:
Und das Interessanteste: die Anzeige der Last des Hosts, auf dem die Anfrage ausgeführt wurde, sowie die Einsicht in die Anfrageprotokolle.
Tolle Integration!
Es könnte die Frage aufkommen, wo die Registerkarten Datenbanken und Externe Dienste, wie bei New Relic, sind. Hier gibt es keine: Da Datadog die Anwendung in Komponenten zerlegt, wird PostgreSQL als einzelner Dienstbetrachtet, und anstelle von externen Diensten sollte nach aws.storage (ähnlich wird es auch für jeden anderen externen Dienst gelten, auf den die Anwendung zugreifen kann).
Hier ist ein Beispiel mit in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier:
Im Grunde gibt es alles, was wir wollten:
Es ist ersichtlich, aus welchem „Dienst“ die Anfrage kam.
Es sei nicht unerwähnt, dass Datadog hervorragend mit NGINX Ingress integriert ist und eine durchgehende Nachverfolgung vom Moment des Ankommens der Anfrage im Cluster ermöglicht, sowie die Annahme von statsd-Metriken, das Sammeln von Logs und Metriken von Hosts erlaubt.
Ein riesiger Vorteil von Datadog ist, dass sein Preis sich zusammensetzt aus Infrastrukturmonitoring, APM, Log-Management und Synthetics-Test, d.h. man kann flexibel einen Tarif auswählen.
2. Atatus
Das Atatus-Team behauptet, dass ihr Service „so wie New Relic, aber besser“ ist. Schauen wir mal, ob das wirklich so ist.
Die Kopfzeile sieht tatsächlich ähnlich aus, aber es war nicht möglich zu bestimmen, ob Redis und memcached in der Anwendung verwendet werden.
APM wählt standardmäßig alle Transaktionen aus, obwohl normalerweise nur die Web-Transaktionen erforderlich sind. Wie bei Datadog gibt es keine Möglichkeit, auf den gewünschten Dienst aus dem Hauptfenster zu wechseln. Darüber hinaus befinden sich die Transaktionen in der Liste nach den Fehlern, was für APM nicht sehr logisch erscheint.
In den Transaktionen sieht es bei Atatus sehr ähnlich wie bei New Relic aus. Nachteil: Man sieht sofort nicht die Dynamik für jeden der Controller. Diese muss man in der Tabelle der Controller suchen, sortiert nach Meiste verbrauchte Zeit:
Die uns vertraute Liste von Controllern ist im Tab Erforschen:
Irgendwie erinnert diese Tabelle an Datadog und gefällt besser als die entsprechende in New Relic.
Jede Transaktion kann aufgeklappt werden, um zu sehen, womit die Anwendung beschäftigt war:
Das Dashboard erinnert auch eher an Datadog: es gibt die Anzahl der Anfragen, ein Gesamtbild der Aufrufe. Die obere Leiste bietet einen Tab mit Fehlern HTTP-Fehler und Beispiele für langsame Anfragen Sitzungsnachverfolgungen:
Wenn man zur Transaktion wechselt, sieht man ein Beispiel für eine Nachverfolgung, man kann die Liste der Datenbankanfragen einsehen und die Header der Anfrage betrachten. Alles ähnlich wie bei New Relic:
Im Allgemeinen hat Atatus mit detaillierten Nachverfolgungen überzeugt – ohne die typischen Zusammenführungen von Anfragen in ein Reminder-Block, wie sie bei New Relic vorkommen:
Allerdings fehlt hier ein Filter, der (wie bei New Relic) extrem schnelle Anfragen (<5ms) ausschneidet. Auf der anderen Seite hat mir die Anzeige des endgültigen Antwortstatus der Transaktion (erfolgreich oder Fehler) gefallen.
Das Panel Datenbanken hilft, die Anfragen an externe Datenbanken, die die Anwendung macht, zu untersuchen. Ich erinnere daran, dass Atatus nur PostgreSQL und MySQL gefunden hat, obwohl im Projekt auch Redis und memcached eingesetzt werden.
Anfragen werden nach bekannten Kriterien sortiert: Häufigkeit der Ausführung, durchschnittliche Antwortzeit und so weiter. Besonders bemerkenswert 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 – ein hervorragendes Ergebnis!
Tab Externe Anfragen ist vollständig identisch mit Datenbanken.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Beide vorgestellten Werkzeuge haben sich als gute APM bewährt. Jedes von ihnen kann das notwendige Minimum anbieten. Unsere Eindrücke lassen sich kurz zusammenfassen als:
Datadog
Vorteile:
- ein praktisches Preismodell (APM kostet 31 USD pro Host);
- hat sich mit Python hervorragend bewährt;
- Möglichkeit zur Integration mit OpenTracing
- Integration mit Kubernetes;
- Integration mit NGINX Ingress.
Nachteile:
- der einzige APM, der die Anwendungsverfügbarkeit aufgrund eines Modulfehlers (predis) beeinträchtigt hat;
- schwache Autoinstrumentierung für PHP;
- teilweise seltsame Definitionen von Services und deren Zweck.
Atatus
Vorteile:
- tiefe Instrumentierung für PHP;
- ähnliche Benutzeroberfläche wie New Relic.
Nachteile:
- funktioniert nicht auf alten Betriebssystemen (Ubuntu 12.05, CentOS 5);
- schwache Autoinstrumentierung;
- unterstützt nur zwei Programmiersprachen (Node.js und PHP);
- langsame Benutzeroberfläche.
Angesichts des Preises von Atatus von 69 USD pro Monat pro Server würden wir eher Datadog verwenden, das sich hervorragend an unsere Bedürfnisse (Webanwendungen in K8s) anpasst und viele nützliche Funktionen bietet.
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «».
Quelle: habr.com
