Schönen Freitag! Freunde, heute setzen wir die Serie von Veröffentlichungen fort, die dem Kurs gewidmet sind , denn die Unterrichtseinheiten in der neuen Gruppe beginnen bereits Ende nächster Woche. Also, fangen wir an!
Monitoring – das ist einfach. Das ist ein bekannter Fakt. Starten Sie Nagios, aktivieren Sie NRPE auf dem Remote-System, konfigurieren Sie Nagios auf den Port NRPE TCP 5666 und schon haben Sie Monitoring.
Es ist so einfach, dass es langweilig ist. Jetzt haben Sie die grundlegenden Metriken zur CPU-Zeit, zur Speichersubsystem, zum Arbeitsspeicher, die standardmäßig in Nagios und NRPE bereitgestellt werden. Aber in Wirklichkeit ist das nicht wirklich "Monitoring" an sich. Das ist nur der Anfang.
(Normalerweise werden PNP4Nagios, RRDtool und Thruk installiert, Benachrichtigungen in Slack konfiguriert und direkt zu nagiosexchange gegangen, aber das lassen wir jetzt mal beiseite).
Gutes Monitoring ist tatsächlich ziemlich komplex, Sie müssen wirklich die Innereien der Anwendung kennen, die Sie überwachen.
Ist Monitoring kompliziert?
Jeder Server, sei es Linux oder Windows, dient per Definition einem bestimmten Zweck. Apache, Samba, Tomcat, Dateispeicher, LDAP – all diese Dienste sind in irgendeiner oder mehreren Hinsicht relativ einzigartig. Jeder hat seine eigene Funktion, seine eigenen Besonderheiten. Es gibt verschiedene Möglichkeiten, Metriken, KPIs (Key Performance Indicators), die für Sie interessant sind, zu erhalten, wenn der Server unter Last steht.
Fotoautor auf
(ich wünschte, meine Dashboards wären in Neongelb- und Blautönen gefärbt – seufzend träumen – … hmm…)
Jede Software, die Dienstleistungen anbietet, sollte einen Mechanismus zur Erfassung von Metriken haben. Apache hat ein Modul mod-status, das die Serverstatusseite anzeigt. Bei Nginx ist es stub_status. Tomcat hat JMX oder spezielle Webanwendungen, die wichtige Metriken anzeigen. In MySQL gibt es den Befehl „show global status“ usw.
Warum integrieren Entwickler solche Mechanismen nicht in die Anwendungen, die sie erstellen?
Tun das nur Entwickler?
Ein gewisses Maß an Gleichgültigkeit gegenüber der Integration von Metriken beschränkt sich nicht nur auf Entwickler. Ich habe in Unternehmen gearbeitet, die Anwendungen mit Tomcat entwickelten und keine eigenen Metriken veröffentlichten, keine Serviceaktivitätsprotokolle, abgesehen von den allgemeinen Fehlerprotokollen von Tomcat. Einige Entwickler erzeugen eine Fülle von Protokollen, die für den Systemadministrator, der sie um 3:15 Uhr lesen muss, bedeutungslos sind.
Fotoautor auf
Systemingenieure, die es solchen Produkten ermöglichen, in den Markt einzutreten, müssen ebenfalls eine bestimmte Verantwortung für die Situation tragen. Nur wenige Systemingenieure haben die Zeit und kümmern sich darum, zu versuchen, aussagekräftige Metriken aus Logs zu gewinnen, ohne den Kontext dieser Metriken und die Möglichkeit, sie im Hinblick auf die Aktivität der Anwendung zu interpretieren. Einige verstehen nicht, welchen Nutzen sie daraus ziehen können, außer Indikatoren wie "derzeit ist etwas (oder wird bald) nicht in Ordnung".
Der Wandel im Denken hinsichtlich der Notwendigkeit von Metriken sollte nicht nur unter Entwicklern, sondern auch unter Systemingenieuren passieren.
Für jeden Systemingenieur, der nicht nur auf kritische Ereignisse reagieren muss, sondern auch deren Abwesenheit garantieren muss, ist das Fehlen von Metriken normalerweise ein Hindernis dafür.
Systemingenieure setzen sich jedoch normalerweise nicht mit dem Code auseinander, um Geld für ihr Unternehmen zu verdienen. Sie benötigen leitende Entwickler, die die Bedeutung der Verantwortung eines Systemingenieurs bei der Erkennung von Problemen, der Sensibilisierung für Leistungsprobleme und Ähnlichem verstehen.
Diese DevOps-Sache
Die DevOps-Mentalität beschreibt die Synergie zwischen dem Denken von Entwicklern (dev) und dem Betrieb (ops). Jedes Unternehmen, das behauptet, "DevOps zu praktizieren", muss:
- sagen, was sie wahrscheinlich nicht tun (Anspielung auf ein Meme aus dem Film "Die Prinzessin Bräutigam" - "Ich glaube nicht, dass das bedeutet, was du denkst, dass es bedeutet!")
- eine Position der kontinuierlichen Verbesserung des Produkts fördern.
Sie können das Produkt nicht verbessern und wissen, dass es verbessert wurde, wenn Sie nicht wissen, wie es derzeit funktioniert. Sie werden nicht herausfinden können, wie das Produkt funktioniert, wenn Sie nicht verstehen, wie seine Komponenten, die Dienste, von denen es abhängt, seine Hauptproblempunkte und Engpässe funktionieren.
Wenn Sie keine potenziellen Engpässe beobachten, können Sie die Technik "Fünf Warum" beim Schreiben eines Postmortems nicht anwenden. Sie werden nicht alles auf einem Bildschirm zusammenstellen können, um zu sehen, wie das Produkt funktioniert oder wie es "normal und glücklich" aussieht.
Shift left, NACH LINKS, ICH HABE GESAGT, LINKS—
Für mich ist eines der Schlüsselprinzipien von DevOps der "Shift Left". Ein Shift Left in diesem Kontext bedeutet eine Verschiebung der Möglichkeiten (nicht der Verantwortung, und nur Möglichkeiten) zu tun, worum sich normalerweise Systemingenieure kümmern, wie zum Beispiel Leistungskennzahlen zu erstellen, Protokolle effizienter zu nutzen usw., und zwar links im Lebenszyklus der Softwarebereitstellung (Software Delivery Life Cycle).
Fotoautor auf
Softwareentwickler sollten in der Lage sein, die Überwachungswerkzeuge zu nutzen und zu kennen, die das Unternehmen verwendet, um die Überwachung in all ihren Formen, Kennzahlen, Protokollierung, Überwachungsoberflächen und, was am wichtigsten ist, durchzuführen, zu beobachten, wie ihr Produkt in der Produktion funktioniert.Sie können Entwickler nicht dazu bringen, Zeit und Mühe in die Überwachung zu investieren, solange sie die Kennzahlen nicht sehen und Einfluss darauf haben können, wie sie aussehen, wie der Produktverantwortliche sie dem CTO beim nächsten Briefing präsentiert usw.
Kurz gesagt
- Führen Sie das Pferd zum Wasser. Zeigen Sie den Entwicklern, wie viele Probleme sie sich ersparen können, helfen Sie ihnen, die richtigen KPIs und Kennzahlen für ihre Anwendungen zu identifizieren, damit es weniger Geschrei vom Produktverantwortlichen gibt, auf den der CTO (Chief Technology Officer) schreit. Bringen Sie sie sanft und ruhig ans Licht. Sollte das nicht gelingen, kaufen Sie sie ein, drohen Sie oder überreden Sie entweder die Entwickler oder den Produktverantwortlichen, um so schnell wie möglich die Erfassung dieser Kennzahlen aus den Anwendungen zu realisieren und dann Diagramme zu erstellen. Das wird schwierig sein, da es nicht als Priorität angesehen wird und in der Produkt-Roadmap viele Projekte auf die Umsetzung warten, die Einnahmen generieren. Daher benötigen Sie eine Wirtschaftlichkeitsanalyse, um die Zeit und Mittel zu rechtfertigen, die für die Implementierung der Überwachung im Produkt aufgewendet werden.
- Helfen Sie den Systemingenieuren, sich auszuruhen. Zeigen Sie ihnen, dass die Anwendung der Checkliste „Release freigeben“ für jedes veröffentlichte Produkt positiv ist. Und die Überprüfung, dass alle Anwendungen in der Produktion von Metriken abgedeckt sind, wird dazu beitragen, gesund zu schlafen, indem es den Entwicklern ermöglicht, zu sehen, was und wo nicht funktioniert. Dennoch ist der beste Weg, jedem Entwickler, Produktinhaber und technischen Direktor auf die Nerven zu gehen und frustriert zu werden, hartnäckig Sand ins Getriebe zu streuen und Widerstand zu leisten. Ein solches Verhalten wird das Veröffentlichungsdatum eines Produkts beeinflussen, wenn man wieder bis zur letzten Minute wartet, also verschieben Sie wieder nach links und integrieren Sie diese Fragen so schnell wie möglich in den Projektplan. Falls nötig, schummeln Sie sich in Produktbesprechungen. Tragen Sie falsche Schnurrbärte und Filz oder Ähnliches, das wird nie schaden. Berichten Sie über Ihre Probleme, zeigen Sie die offensichtlichen Vorteile und evangelisieren Sie.
- Stellen Sie sicher, dass sowohl Entwicklern (dev) als auch dem Betrieb (ops) die Bedeutung und die Folgen des Übertritts von Produktmetriken in die „rote Zone“ klar sind. Lassen Sie den Betrieb nicht als einzigen Wächter der Produktverfügbarkeit agieren; stellen Sie sicher, dass auch die Entwickler involviert sind (#productsquads).
- Logs sind eine großartige Sache, aber Metriken ebenfalls. Kombinieren Sie sie und lassen Sie nicht zu, dass Ihre Logs in einem riesigen, brennenden Ball der Sinnlosigkeit enden. Erklären Sie den Entwicklern und zeigen Sie ihnen, warum niemand außer ihnen ihre Logs versteht, und zeigen Sie ihnen, wie es ist, um 3:15 Uhr nutzlose Logs anzusehen.
Fotoautor auf
Das ist alles. Neues Material wird nächste Woche veröffentlicht. Wenn Sie mehr über den Kurs erfahren möchten, laden wir Sie zu unserem , der bereits am Montag stattfindet, ein. Und jetzt warten wir wie gewohnt auf Ihre Kommentare.
Quelle: habr.com
