Im Umfeld von SRE/DevOps-Ingenieuren wird es niemanden überraschen, dass eines Tages ein Kunde (oder ein Überwachungssystem) auftaucht und meldet, dass „alles verloren ist“: Die Website funktioniert nicht, Zahlungen gehen nicht durch, das Leben verfällt ... Egal wie sehr Sie in einer solchen Situation helfen möchten, ohne ein einfaches und verständliches Tool kann es sehr schwierig sein, dies zu tun. Oft liegt das Problem im Anwendungscode selbst verborgen; Sie müssen es nur lokalisieren.
Und in Trauer und in Freude ...
So kam es, dass wir uns schon lange und tief in New Relic verliebt haben. Es war und ist ein hervorragendes Tool zur Überwachung der Anwendungsleistung und ermöglicht Ihnen außerdem die Instrumentierung der Microservice-Architektur (mithilfe ihres Agenten) und vieles mehr. Und alles hätte großartig sein können, wenn sich nicht die Preispolitik des Dienstes geändert hätte: it kosten 3+ Mal gewachsen. Darüber hinaus erfordert der Erhalt eines Testkontos seit letztem Jahr die Kommunikation mit einem persönlichen Manager, was es schwierig macht, das Produkt einem potenziellen Kunden vorzustellen.
Die übliche Situation: New Relic wird nicht „dauerhaft“ benötigt, sie erinnern sich erst in dem Moment daran, wenn Probleme beginnen. Dennoch muss man regelmäßig zahlen (140 USD pro Server und Monat), und in einer automatisch skalierenden Cloud-Infrastruktur summieren sich die Beträge ziemlich hoch. Obwohl es eine Pay-As-You-Go-Option gibt, erfordert die Aktivierung von New Relic einen Neustart der Anwendung, was dazu führen kann, dass die problematische Situation, für die alles gestartet wurde, verloren geht. Vor nicht allzu langer Zeit hat New Relic einen neuen Tarifplan eingeführt - , - was auf den ersten Blick wie eine vernünftige Alternative zu Professional aussieht... doch bei näherer Betrachtung stellte sich heraus, dass einige wichtige Funktionen fehlen (insbesondere nicht). Schlüsseltransaktionen, Anwendungsübergreifende Nachverfolgung, Verteilte Ablaufverfolgung).
Daher begannen wir darüber nachzudenken, nach einer günstigeren Alternative zu suchen, und unsere Wahl fiel auf zwei Dienste: Datadog und Atatus. Warum auf ihnen?
Über Konkurrenten
Lassen Sie mich gleich sagen, dass es andere Lösungen auf dem Markt gibt. Wir haben sogar Open-Source-Optionen in Betracht gezogen, aber nicht jeder Kunde verfügt über freie Kapazitäten, um selbst gehostete Lösungen zu hosten … – außerdem erfordern sie zusätzliche Wartung. Es stellte sich heraus, dass das Paar, das wir ausgewählt hatten, am nächsten stand unsere Bedürfnisse:
- integrierte und entwickelte Unterstützung für PHP-Anwendungen (der Stack unserer Kunden ist sehr vielfältig, aber dies ist ein klarer Spitzenreiter bei der Suche nach einer Alternative zu New Relic);
- erschwingliche Kosten (weniger als 100 USD pro Monat und Host);
- automatische Instrumentierung;
- Integration mit Kubernetes;
- Die Ähnlichkeit zur New Relic-Schnittstelle ist ein spürbarer Pluspunkt (weil unsere Ingenieure daran gewöhnt sind).
Daher haben wir in der ersten Auswahlphase mehrere andere beliebte Lösungen ausgeschlossen, insbesondere:
- Tideways, AppDynamics und Dynatrace – gegen Gebühr;
- Stackify ist in der Russischen Föderation gesperrt und zeigt zu wenig Daten an.
Der Rest des Artikels ist so aufgebaut, dass zunächst kurz auf die in Frage kommenden Lösungen eingegangen wird und ich anschließend auf unsere typische Interaktion mit New Relic und Erfahrungen/Eindrücke aus der Durchführung ähnlicher Vorgänge bei anderen Diensten eingehen werde.
Präsentation ausgewählter Wettbewerber
Про , hat wahrscheinlich jeder gehört? Die Entwicklung dieses Dienstes begann vor mehr als 10 Jahren, im Jahr 2008. Wir nutzen es seit 2012 aktiv und hatten keine Probleme, eine wirklich große Anzahl von Anwendungen in PHP, Ruby und Python zu integrieren, und wir haben auch Erfahrung mit der Integration mit C# und Go. Die Autoren des Dienstes verfügen über Lösungen zur Überwachung von Anwendungen, Infrastruktur, zur Verfolgung von Microservice-Infrastrukturen, haben praktische Anwendungen für Benutzergeräte erstellt und vieles mehr.
Allerdings läuft der New Relic-Agent auf proprietären Protokollen und unterstützt kein OpenTracing. Erweiterte Instrumentierung erfordert Bearbeitungen speziell für New Relic. Schließlich ist die Kubernetes-Unterstützung noch experimentell.
Begann seine Entwicklung im Jahr 2010 Gerade im Hinblick auf den Einsatz in Kubernetes-Umgebungen sieht es deutlich interessanter aus als New Relic. Insbesondere unterstützt es die Integration mit den Protokollen NGINX Ingress, Log Collection, Statsd und OpenTracing, wodurch Sie eine Benutzeranfrage vom Zeitpunkt der Verbindung bis zum Abschluss verfolgen und Protokolle für diese Anfrage finden können (beides auf der Webserverseite). und auf Seiten des Verbrauchers).
Bei der Verwendung von Datadog stellten wir fest, dass die Microservice-Karte manchmal falsch erstellt wurde und einige technische Mängel auftraten. Beispielsweise wurde der Diensttyp falsch identifiziert (Django wurde mit einem Caching-Dienst verwechselt) und 500 Fehler in einer PHP-Anwendung verursacht, die die beliebte Predis-Bibliothek verwendete.
— das jüngste Instrument; Der Dienst wurde 2014 gestartet. Sein Marketingbudget liegt deutlich unter dem der aufgeführten Wettbewerber, Erwähnungen sind deutlich seltener. Allerdings ist das Tool selbst New Relic sehr ähnlich, nicht nur in seinen Fähigkeiten (APM, Browser-Überwachung usw.), sondern auch im Aussehen.
Ein wesentlicher Nachteil besteht darin, dass nur Node.js und PHP unterstützt werden. Andererseits ist es deutlich besser implementiert als Datadog. Im Gegensatz zu Letzterem ist es bei Atatus nicht erforderlich, dass Anwendungen Änderungen vornehmen oder dem Code zusätzliche Beschriftungen hinzufügen.
Wie wir mit New Relic arbeiten
Schauen wir uns nun an, wie wir New Relic im Allgemeinen verwenden. Nehmen wir an, wir haben ein Problem, das einer Lösung bedarf:
In der Grafik ist es leicht zu erkennen unvollständig - Lassen Sie es uns analysieren. In New Relic werden Webtransaktionen sofort für eine Webanwendung ausgewählt, alle Komponenten werden im Leistungsdiagramm angezeigt, es gibt Fehlerraten- und Anforderungsraten-Panels ... Am wichtigsten ist, dass Sie direkt von diesen Panels aus zwischen verschiedenen wechseln können Teile der Anwendung (wenn Sie beispielsweise auf MySQL klicken, gelangen Sie zum Datenbankbereich).
Denn im betrachteten Beispiel sehen wir einen Anstieg der Aktivität PHP, klicken Sie auf dieses Diagramm und gelangen Sie automatisch zu Transaktionen:
Die Liste der Transaktionen, bei denen es sich im Wesentlichen um Controller aus dem MVC-Modell handelt, ist bereits sortiert nach Am zeitaufwändigsten, was sehr praktisch ist: Wir sehen sofort, was die Anwendung macht. Hier finden Sie Beispiele für lange Abfragen, die automatisch von New Relic erfasst werden. Durch Umschalten der Sortierung ist es leicht zu finden:
- der am stärksten ausgelastete Anwendungscontroller;
- am häufigsten angefragter Controller;
- der langsamste der Controller.
Darüber hinaus können Sie jede Transaktion erweitern und sehen, was die Anwendung zum Zeitpunkt der Codeausführung tat:
Schließlich speichert die Anwendung Beispiele für Spuren langer Anfragen (solche, die länger als 2 Sekunden dauern). Hier ist das Panel für eine lange Transaktion:
Es ist ersichtlich, dass die beiden Methoden viel Zeit in Anspruch nehmen und gleichzeitig auch der Zeitpunkt der Ausführung der Anforderung, ihr URI und ihre Domäne angezeigt werden. Sehr oft hilft dies dabei, die Anfrage in den Protokollen zu finden. Gehe zu Trace-Detailskönnen Sie sehen, woher diese Methoden aufgerufen werden:
Und in Datenbankabfragen – Auswertung von Abfragen an Datenbanken, die während der Ausführung der Anwendung ausgeführt wurden:
Mit diesem Wissen können wir beurteilen, warum die Anwendung langsamer wird, und gemeinsam mit dem Entwickler eine Strategie zur Lösung des Problems entwickeln. In der Realität liefert New Relic nicht immer ein klares Bild, aber es hilft bei der Wahl des Untersuchungsvektors:
- lang
PDO::Constructführte uns zu der seltsamen Funktionsweise von pgpoll; - Instabilität im Laufe der Zeit
Memcache::Getdeutete darauf hin, dass die virtuelle Maschine falsch konfiguriert war; - Eine verdächtig längere Zeit für die Vorlagenverarbeitung führte zu einer verschachtelten Schleife, die das Vorhandensein von 500 Avataren im Objektspeicher überprüfte.
- und so weiter ...
Es kommt auch vor, dass auf dem Hauptbildschirm etwas wächst, das mit der externen Datenspeicherung zu tun hat, anstatt Code auszuführen – und es spielt keine Rolle, was es sein wird: Redis oder PostgreSQL – sie sind alle in der Registerkarte ausgeblendet Datenbanken.
Sie können eine bestimmte Basis für die Recherche auswählen und Abfragen sortieren – ähnlich wie dies in Transaktionen geschieht. Und wenn Sie zur Registerkarte „Anfrage“ gehen, können Sie sehen, wie oft diese Anfrage in den einzelnen Anwendungscontrollern auftritt, und auch abschätzen, wie oft sie aufgerufen wird. Es ist sehr bequem:
Die Registerkarte enthält ähnliche Daten Externe Dienste, das Anfragen an externe HTTP-Dienste verbirgt, z. B. den Zugriff auf Objektspeicher, das Senden von Ereignissen an Sentry oder Ähnliches. Die Registerkarte ähnelt inhaltlich vollständig der Registerkarte „Datenbanken“:
Wettbewerber: Chancen und Eindrücke
Das Interessanteste ist nun, die Fähigkeiten von New Relic mit denen der Konkurrenz zu vergleichen. Leider konnten wir nicht alle drei Tools in einer Version einer in der Produktion laufenden Anwendung testen. Wir haben jedoch versucht, möglichst identische Situationen/Konfigurationen zu vergleichen.
1. Datenhund
Datadog begrüßt uns mit einem Panel mit einer Wand von Diensten:
Es versucht, Anwendungen in Komponenten/Mikrodienste zu unterteilen, sodass wir in der Beispiel-Django-Anwendung zwei Verbindungen zu PostgreSQL sehen werden (defaultdb и postgres) sowie Sellerie, Redis. Für die Arbeit mit Datadog müssen Sie über minimale Kenntnisse der MVC-Prinzipien verfügen: Sie müssen verstehen, woher Benutzeranfragen im Allgemeinen kommen. Das hilft normalerweise Karte der Dienstleistungen:
Ähnliches gibt es übrigens auch in New Relic:
... und ihre Karte ist meiner Meinung nach einfacher und übersichtlicher: Sie zeigt nicht die Komponenten einer Anwendung an (was sie übermäßig detailliert machen würde, wie im Fall von Datadog), sondern nur bestimmte Dienste oder Microservices.
Kehren wir zu Datadog zurück: Aus der Service-Map können wir ersehen, dass Benutzeranfragen an Django gehen. Gehen wir zum Django-Dienst und sehen endlich, was wir erwartet haben:
Leider gibt es hier standardmäßig keine Grafik Web-Transaktionszeit, ähnlich dem, was wir im Hauptfenster von New Relic sehen. Es kann jedoch anstelle des Zeitplans konfiguriert werden % der aufgewendeten Zeit. Es genügt, darauf umzuschalten Durchschnittliche Zeit pro Anfrage nach Typ... und jetzt blickt uns die bekannte Grafik an!
Warum Datadog ein anderes Diagramm gewählt hat, ist uns ein Rätsel. Eine weitere frustrierende Sache ist, dass sich das System die Wahl des Benutzers nicht merkt (im Gegensatz zu beiden Konkurrenten) und daher die einzige Lösung darin besteht, benutzerdefinierte Panels zu erstellen.
Aber ich war mit der Möglichkeit in Datadog zufrieden, von diesen Diagrammen zu den Metriken verwandter Server zu wechseln, die Protokolle zu lesen und die Belastung der Webserver-Handler (Gunicorn) auszuwerten. Alles ist fast das Gleiche wie in New Relic... und sogar noch ein bisschen mehr (Logs)!
Unterhalb der Grafiken sind Transaktionen aufgeführt, die denen von New Relic völlig ähneln:
In Datadog werden Transaktionen aufgerufen die Ressourcen. Sie können Controller nach der Anzahl der Anfragen, nach der durchschnittlichen Antwortzeit und nach der maximalen Zeit, die für einen ausgewählten Zeitraum aufgewendet wurde, sortieren.
Sie können die Ressource erweitern und alles sehen, was wir bereits in New Relic beobachtet haben:
Es gibt Statistiken zur Ressource, eine allgemeine Liste interner Anrufe und Beispiele für Anfragen, die nach Antwortcode sortiert werden können ... Diese Sortierung hat unseren Ingenieuren übrigens sehr gut gefallen.
Jede Beispielressource in Datadog kann geöffnet und untersucht werden:
Es werden Anforderungsparameter, ein zusammenfassendes Diagramm der für jede Komponente aufgewendeten Zeit und ein Wasserfalldiagramm mit der Reihenfolge der Aufrufe angezeigt. Sie können auch zur Baumansicht des Wasserfalldiagramms wechseln:
Und das Interessanteste ist, die Auslastung des Hosts anzuzeigen, auf dem die Anfrage ausgeführt wurde, und die Anfrageprotokolle anzuzeigen.
Tolle Integration!
Sie fragen sich vielleicht, wo sich die Registerkarten befinden Datenbanken и Externe Dienste, wie in New Relic. Hier gibt es keine: Da Datadog die Anwendung in Komponenten zerlegt, wird PostgreSQL berücksichtigt ein separater Dienst, und statt externer Dienste lohnt es sich, danach zu suchen aws.storage (Ähnlich verhält es sich mit jedem anderen externen Dienst, auf den die Anwendung zugreifen kann).
Hier ist ein Beispiel mit postgres:
Im Wesentlichen gibt es alles, was wir wollten:
Sie können sehen, von welchem „Dienst“ die Anfrage kam.
Es wäre nicht verkehrt, Sie daran zu erinnern, dass Datadog sich perfekt in NGINX Ingress integriert und Ihnen ab dem Moment, in dem eine Anfrage im Cluster eintrifft, eine End-to-End-Ablaufverfolgung ermöglicht. Darüber hinaus können Sie Statsd-Metriken empfangen, Protokolle sammeln und Host-Metriken sammeln .
Ein großes Plus von Datadog ist sein Preis formt sich aus Infrastrukturüberwachung, APM, Log Management und Synthetics Test, d.h. Sie können Ihren Plan flexibel wählen.
2.Atatus
Das Atatus-Team behauptet, dass ihr Service „derselbe wie New Relic, aber besser“ sei. Mal sehen, ob das wirklich so ist.
Das Hauptfenster sieht zwar ähnlich aus, es war jedoch nicht möglich, die in der Anwendung verwendeten Redis und Memcached zu ermitteln.
APM wählt standardmäßig alle Transaktionen aus, obwohl normalerweise nur Webtransaktionen erforderlich sind. Wie bei Datadog gibt es keine Möglichkeit, vom Hauptfenster aus zum gewünschten Dienst zu navigieren. Darüber hinaus werden Transaktionen nach Fehlern aufgelistet, was für APM nicht sehr logisch erscheint.
Bei Atatus-Transaktionen ist alles so ähnlich wie möglich bei New Relic. Der Nachteil besteht darin, dass die Dynamik für jeden Controller nicht sofort sichtbar ist. Sie müssen es in der Controller-Tabelle suchen und nach sortieren Die meiste Zeit verbraucht:
Die übliche Liste der Controller ist auf der Registerkarte verfügbar Entdecken:
In mancher Hinsicht erinnert diese Tabelle an Datadog und gefällt mir besser als die ähnliche in New Relic.
Sie können jede Transaktion erweitern und sehen, was die Anwendung getan hat:
Auch das Panel erinnert eher an Datadog: Es gibt eine Reihe von Anfragen, ein Gesamtbild der Aufrufe. Im oberen Bereich befindet sich eine Fehlerregisterkarte HTTP-Fehler und Beispiele für langsame Abfragen Sitzungsspuren:
Wenn Sie zu einer Transaktion gehen, können Sie ein Beispiel für einen Trace sehen, eine Liste der Anfragen an die Datenbank abrufen und sich die Anfrageheader ansehen. Alles ist ähnlich wie bei New Relic:
Im Allgemeinen freut sich Atatus über detaillierte Spuren – ohne das für New Relic typische Einkleben von Anrufen in einen Erinnerungsblock:
Allerdings fehlt ihm ein Filter, der (wie New Relic) ultraschnelle Anfragen (<5ms) abschneiden würde. Andererseits gefiel mir die Anzeige der endgültigen Transaktionsantwort (Erfolg oder Fehler).
Panel Datenbanken wird Ihnen helfen, die Anfragen an externe Datenbanken zu untersuchen, die die Anwendung stellt. Ich möchte Sie daran erinnern, dass Atatus nur PostgreSQL und MySQL gefunden hat, obwohl auch Redis und Memcached an dem Projekt beteiligt sind.
Anfragen werden nach den üblichen Kriterien sortiert: Antworthäufigkeit, durchschnittliche Antwortzeit usw. Ich möchte auch den Tab mit den langsamsten Abfragen erwähnen – er ist sehr praktisch. Darüber hinaus stimmten die Daten auf dieser Registerkarte für PostgreSQL mit den Daten der Erweiterung überein - hervorragendes Ergebnis!
Tab Externe Anfragen völlig identisch mit Datenbanken.
Befund
Beide vorgestellten Tools haben sich in der Rolle des APM gut bewährt. Jeder von ihnen kann das erforderliche Minimum bieten. Unsere Eindrücke lassen sich wie folgt kurz zusammenfassen:
Datadog
Profis:
- praktischer Tarifplan (APM kostet 31 USD pro Host);
- hat gut mit Python funktioniert;
- Möglichkeit der Integration mit OpenTracing
- Integration mit Kubernetes;
- Integration mit NGINX Ingress.
Nachteile:
- das einzige APM, das dazu führte, dass die Anwendung aufgrund eines Modulfehlers (predis) nicht verfügbar war;
- schwache automatische PHP-Instrumentierung;
- teilweise seltsame Definition von Dienstleistungen und deren Zweck.
Atatus
Profis:
- tiefe PHP-Instrumentierung;
- Benutzeroberfläche ähnlich wie New Relic.
Nachteile:
- funktioniert nicht auf älteren Betriebssystemen (Ubuntu 12.05, CentOS 5);
- schwache Autoinstrumentierung;
- Unterstützung für nur zwei Sprachen (Node.js und PHP);
- Langsame Schnittstelle.
Angesichts des Atatus-Preises von 69 USD pro Monat und Server würden wir lieber Datadog verwenden, das sich gut in unsere Anforderungen (Webanwendungen in K8s) integrieren lässt und über viele nützliche Funktionen verfügt.
PS
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «".
Source: habr.com