Dies ist ein Gast-Blogbeitrag von Erik Näslund, Direktor von Entgeistert . Erik ist Backend-Entwickler und Betriebstechniker. Sein erstes Spiel entwickelte er im Alter von sechs Jahren mit AMOS Professional auf dem Amiga. Es gab eine Zeit, in der FPGA-Programmierung und -Hardware der letzte Schrei waren. In den letzten 15 Jahren hat Erik an der Webentwicklung gearbeitet und dabei hauptsächlich Python, C# und Javascript verwendet.

Ich habe in Softwareunternehmen mit einer Mitarbeiterzahl von Dutzenden bis hin zu Tausenden gearbeitet.

In dem Unternehmen mit etwa zehn Mitarbeitern waren Entwickler für das gesamte Monitoring verantwortlich. Viele Dinge wurden nie überwacht, weil wir einfach nicht die Zeit investierten. Wir empfanden die Lernschwelle als zu groß und hatten nicht das Budget, um teures gehostetes Monitoring zu kaufen. Dies führte zu einigen peinlichen Momenten, in denen unsere Kunden uns von Problemen berichteten, bevor wir sie entdeckten.

Das mittelgroße Unternehmen mit etwa hundert Mitarbeitern hatte ein eigenes Betriebsteam, das für die Überwachung zuständig war. Sie verbrachten einige Zeit damit, redundante Nagios-Server einzurichten und sie mit Prüfungen zu versehen. Das funktionierte einigermaßen gut, aber wir hatten trotzdem viele Dinge, die nicht überwacht wurden, was hauptsächlich daran lag, dass Entwicklung und Betrieb nicht so eng zusammenarbeiteten, wie sie hätten sein können. Die Betriebsabteilung kannte die von uns entwickelte Software nicht gut genug, um die richtigen Dinge zu überwachen, und der Zeitplan des Entwicklungsteams war meist zu eng, um sie durch die einzelnen Schritte zu führen. Die Überwachung wurde meist erst nachträglich hinzugefügt, wenn überhaupt, was auf beiden Seiten zu Frustrationen führte.

In dem großen Unternehmen mit über tausend Mitarbeitern waren Entwickler nie in die Überwachung eingebunden. Ich wusste, dass wir eine gute Infrastruktur und Serverüberwachung hatten, aber keine der Webanwendungen, die wir selbst entwickelten, fand jemals Beachtung. Wir haben ein paar mutige Versuche unternommen, Überwachung hinzuzufügen, aber am Ende hatten wir nur einen Mix aus Lösungen. Wann immer wir nach etwas fragten, das das ganze Unternehmen nutzen könnte, bekamen wir ein „Wir kümmern uns darum“. Offenbar hatte das Betriebsteam Probleme, ein System zu finden, das flexibel genug und gleichzeitig für Entwickler einfach zu handhaben war.

Meine Erkenntnisse daraus sind folgende, unabhängig von der Unternehmensgröße gültige Fakten:

• Wenn der Zeit- oder Kostenaufwand zu groß ist, werden Sie keine Überwachung hinzufügen.
• Jeder Entwickler, der Code schreibt, der in die Produktion geht, muss wissen, wie man Überwachung hinzufügt. Es muss kinderleicht sein, um die Notwendigkeit einer speziellen Schulung in Überwachungssystemen mit hochkomplexen Konfigurationssprachen zu vermeiden.

Einrichten der Infrastrukturphase

Stellen Sie sich ein fiktives rundenbasiertes Online-Strategiespiel namens Awesome Space Battle vor. Die Spieler sagen ihren Truppen, was sie tun sollen, und einmal pro Minute werden ihre Befehle ausgeführt und es kommt zu einer epischen Schlacht. Wie Sie vielleicht schon vermutet haben, bin ich kein Spieleentwickler. Das wäre wahrscheinlich das langweiligste Spiel aller Zeiten, aber für diese Erklärung reicht es vollkommen aus.

Die Serverinfrastruktur basiert auf zwei Servern, die auf Amazon AWS hinter einem Load Balancer laufen. Die Server heißen einfach S1 und S2. Sie sind nicht direkt vom öffentlichen Internet aus zugänglich, da wir möchten, dass unsere Spieler über unseren Load Balancer laufen. Wir verwenden einen Drittanbieter-Zahlungsanbieter, der die Checkout-Seite bereitstellt.

Website-Überwachung

Es ist entscheidend, dass die Site für die Spieler jederzeit verfügbar und reaktionsfähig ist. Sie benötigen ein Tool, das sowohl die Verfügbarkeit als auch die Leistung der Website überwachen kann. Die Leistungsmessung wird normalerweise als APM (Application Performance Management) bezeichnet, und eine bestimmte Untergruppe heißt RUM (Real User Monitoring).

APM dient zum Messen von Dingen wie der Zeit, die für SQL-Abfragen und Vorlagen-Rendering aufgewendet wird. Es ist ein großartiges Tool zum Auffinden von Engpässen in Ihrer Anwendung. Denken Sie daran, zuerst zu messen und später zu optimieren, da unsere Intuition darüber, was langsam sein wird, oft falsch ist.

RUM funktioniert, indem es als Teil jeder Seite einen Javascript-Schnipsel einfügt. Es gibt Ihnen einen guten Überblick darüber, wie viel Zeit für das Herunterladen von Assets, das Ausführen von Javascript usw. aufgewendet wird. Dies geschieht normalerweise durch die Verwendung von Web-Performance-API in modernen Browsern verfügbar.

Im Fall von Awesome Space Battle haben wir beschlossen, einen Test für Folgendes hinzuzufügen: http://s1.awesomespacebattle.com /Und http://s2.awesomespacebattle.com/ . Es ist wichtig zu beachten, dass wir die URL jedes

einzelner Server und nicht der des Load Balancers. Dies ist sehr wichtig, um Probleme so schnell wie möglich zu diagnostizieren. Eine direkte Überprüfung beim Load Balancer könnte zeitweise Fehlermeldungen generieren, falls nur einer der beiden Server ausgefallen ist. AWS-Sicherheitsgruppen wurden verwendet, um den Testservern eine direkte Verbindung mit den Servern basierend auf der Quell-IP zu ermöglichen.

Schließlich beschlossen wir, auch einen Test hinzuzufügen für https://store.awesomespacebattle.com/ die vom Zahlungsanbieter gehostet wird. Es ist sinnvoll, für jeden Teil, der auf einer anderen Infrastruktur läuft, mindestens eine Prüfung durchzuführen, da es völlig unterschiedliche Gründe für ein Versagen geben kann.

Ereignisüberwachung

Es war sehr beruhigend zu wissen, dass wir eine Benachrichtigung erhalten würden, wenn die Website komplett ausfallen und nicht mehr richtig angezeigt werden würde. Das war jedoch nicht genug. Denken Sie daran, dass Awesome Space Battle ein rundenbasiertes Spiel ist und wir einen periodischen Job haben, der den Großteil der Spiellogik ausführt. Wir wollten sicherstellen, dass dieser jede Minute ohne Unterbrechungen ausgeführt wird. Unsere Benutzer sollten außerdem zehn Tage vor der Verlängerung ihres Kontos eine E-Mail erhalten. Wir haben festgestellt, dass dies die Konversionsrate erheblich verbessert.

Die Überwachung solcher Schlüsselereignisse ist mit herkömmlichen Überwachungstools für Webanwendungen nicht so einfach, deshalb brauchten wir hier etwas anderes.

Die Ereignisüberwachung funktioniert genau umgekehrt wie die herkömmliche Überwachung von Webanwendungen. Sie basiert auf der Serversignalisierung, dass bestimmte erwartete Ereignisse eingetreten sind, anstatt dass ein externer Testserver regelmäßig den Status abfragt. Wenn die Ereignisse nicht so oft wie erwartet eintreten, schlägt der Test fehl und jemand wird benachrichtigt. In gewisser Weise kann man sich die herkömmliche Überwachung von Webanwendungen als „Pull-basierte Überwachung“ vorstellen, während die Ereignisüberwachung eher eine „Push-basierte Überwachung“ ist.

Für Awesome Space Battle wurden zwei Ereignistests hinzugefügt – „Die Spiellogik sollte jede Minute auf zwei Servern ausgeführt werden“ und „Das Versenden von Erneuerungs-E-Mails sollte jeden Tag auf einem Server ausgeführt werden.“

Wie Sie vielleicht bemerkt haben, wird der E-Mail-Versand nur von einem einzigen Server durchgeführt. Wir fragen einfach den Load Balancer nach allen angeschlossenen, fehlerfreien Servern, und der mit der niedrigsten Instanz-ID übernimmt die Aufgabe.

Die richtigen Personen benachrichtigen

Jetzt hatten wir also ein wirklich gutes Monitoring eingerichtet und fühlten uns ziemlich sicher. Irgendwann trat ein Problem auf, das niemand bemerkte, weil es Wochenende war und niemand Bereitschaftsdienst hatte. An diesem Punkt entschieden wir uns für die Integration mit einem System, das uns Bereitschaftspläne und Eskalationsrichtlinien sowie alle gewünschten Benachrichtigungsoptionen bietet. Achten Sie darauf, einen Dienst auszuwählen, der sich gut in alle Ihre Monitoring- und Benachrichtigungstools integrieren lässt. Wir haben uns beispielsweise dafür entschieden, alle Probleme an unseren HipChat-Raum weiterzuleiten. Dies erwies sich als großartige Entscheidung, da alle Entwickler im Team sofort erfuhren, wenn etwas nicht stimmte, und sich sofort darum kümmern konnten.

Immer überwachen

Beim Unit-Testen gibt es ein Sprichwort: „Wenn es nicht getestet wird, ist es kaputt.“ Dasselbe würde ich beim Monitoring sagen: „Wenn es nicht überwacht wird, ist es kaputt.“

Ich würde jedem, der seine Anwendungen und Infrastruktur nicht überwacht, raten, sofort damit anzufangen. Fangen Sie klein an, mit etwas, das einfach zu handhaben und flexibel genug für die meisten Ihrer Anwendungsfälle ist. Ein häufiger Fehler ist, zu versuchen, ein einziges Überwachungstool zu finden, das alles kann, was Sie sich vorstellen können. Diese Flexibilität geht auf Kosten der Benutzerfreundlichkeit und wenn Ihre Tools zu schwer zu verwenden sind, werden Sie sie einfach nicht verwenden.

Wenn Sie möchten, dass Ihre Entwickler sich voll und ganz dem Monitoring widmen, sind leicht verständliche Tools unerlässlich. Es ist sinnvoll, wenn die Entwickler für ihr eigenes Monitoring verantwortlich sind. Wer wüsste besser, was zu überwachen ist, als die Person, die die Software erstellt hat?

Ein Full-Stack-Entwickler ist für die Erstellung von Software (Programmierung) verantwortlich und stellt sicher, dass sie sich korrekt verhält (Testen) und dies während ihrer gesamten Lebensdauer (Überwachung) auch weiterhin tut. Entwickler haben nur allzu oft das Gefühl, dass ihre Arbeit nach dem ersten Programmierteil erledigt ist. Eine anfängliche Investition in die Überwachung stellt sicher, dass Sie für spätere unvorhergesehene Probleme gerüstet sind. Egal, wie gut Sie als Entwickler sind, es wird immer Dinge geben, mit denen Sie nicht gerechnet haben.