Schönen Freitag euch allen! Freunde, heute setzen wir die dem Kurs gewidmete Publikationsreihe fort , da der Unterricht in der neuen Gruppe für den Kurs Ende nächster Woche beginnen wird. Also, fangen wir an!
Überwachung ist nur. Dies ist eine bekannte Tatsache. Rufen Sie Nagios auf, führen Sie NRPE auf dem Remote-System aus, konfigurieren Sie Nagios auf dem NRPE-TCP-Port 5666 und Sie haben die Überwachung.
Es ist so einfach, dass es nicht interessant ist. Jetzt verfügen Sie über grundlegende Metriken für CPU-Zeit, Festplattensubsystem und RAM, die Nagios und NRPE standardmäßig zur Verfügung gestellt werden. Dabei handelt es sich aber nicht wirklich um „Überwachung“ als solche. Das ist erst der Anfang.
(Normalerweise installieren sie PNP4Nagios, RRDtool und Thruk, richten Benachrichtigungen in Slack ein und gehen direkt zu Nagiosexchange, aber das lassen wir vorerst weg.)
Gute Überwachung ist eigentlich ziemlich komplex, Sie müssen wirklich die Interna der Anwendung kennen, die Sie überwachen.
Ist die Überwachung schwierig?
Jeder Server, sei es Linux oder Windows, erfüllt per Definition einen bestimmten Zweck. Apache, Samba, Tomcat, Dateispeicherung, LDAP – alle diese Dienste sind in einer oder mehreren Hinsichten mehr oder weniger einzigartig. Jedes hat seine eigene Funktion, seine eigenen Eigenschaften. Es gibt verschiedene Möglichkeiten, Kennzahlen, KPIs (Key Performance Indicators), zu erhalten, die für Sie interessant sind, wenn der Server unter Last steht.
Autor des Fotos auf
(Ich wünschte, meine Armaturenbretter wären neonblau – ich seufze verträumt –... hmm...)
Jede Software, die Dienste bereitstellt, muss über einen Mechanismus zum Sammeln von Metriken verfügen. Apache hat ein Modul mod-status, um die Serverstatusseite anzuzeigen. Nginx hat - stub_status. Tomcat verfügt über JMX oder benutzerdefinierte Webanwendungen, die wichtige Kennzahlen anzeigen. MySQL hat einen Befehl „globalen Status anzeigen“ usw.
Warum bauen Entwickler also nicht ähnliche Mechanismen in die von ihnen erstellten Anwendungen ein?
Machen das nur Entwickler?
Ein gewisses Maß an Gleichgültigkeit gegenüber der Einbettung von Metriken ist nicht auf Entwickler beschränkt. Ich habe in Unternehmen gearbeitet, in denen Anwendungen mit Tomcat entwickelt wurden und keine eigenen Metriken und keine Protokolle der Serviceaktivität bereitgestellt wurden, mit Ausnahme allgemeiner Tomcat-Fehlerprotokolle. Einige Entwickler erstellen viele Protokolle, die für den Systemadministrator, der das Pech hat, sie um 3:15 Uhr morgens zu lesen, keine Bedeutung haben.
Autor des Fotos auf
Auch Systemingenieure, die die Freigabe solcher Produkte ermöglichen, müssen eine gewisse Verantwortung für die Situation tragen. Nur wenige Systemingenieure haben die Zeit oder die Mühe, aussagekräftige Metriken aus Protokollen zu extrahieren, ohne den Kontext dieser Metriken zu kennen und sie im Lichte der Anwendungsaktivität interpretieren zu können. Manche verstehen nicht, wie sie davon profitieren können, abgesehen von den Indikatoren „etwas ist derzeit (oder wird bald) falsch laufen“.
Nicht nur bei Entwicklern, sondern auch bei Systemingenieuren muss ein Umdenken hinsichtlich der Notwendigkeit von Metriken stattfinden.
Für jeden Systemingenieur, der nicht nur auf kritische Ereignisse reagieren, sondern auch sicherstellen muss, dass diese nicht eintreten, ist das Fehlen von Metriken normalerweise ein Hindernis dafür.
Allerdings basteln Systemingenieure normalerweise nicht an Code herum, um Geld für ihr Unternehmen zu verdienen. Sie benötigen leitende Entwickler, die die Bedeutung der Verantwortung des Systemingenieurs bei der Identifizierung von Problemen, der Sensibilisierung für Leistungsprobleme usw. verstehen.
Das ist eine Entwicklungssache
Die Devops-Mentalität beschreibt die Synergie zwischen Entwicklungs- (Dev) und Operations-Denken (Ops). Jedes Unternehmen, das behauptet, „Entwicklungen durchzuführen“, muss:
- Dinge sagen, die sie wahrscheinlich nicht tun (in Anlehnung an das Meme „Die Braut des Prinzen“ – „Ich glaube nicht, dass es das bedeutet, was du denkst!“)
- Fördern Sie eine Haltung der kontinuierlichen Produktverbesserung.
Sie können ein Produkt nicht verbessern und wissen, dass es verbessert wurde, wenn Sie nicht wissen, wie es derzeit funktioniert. Sie können nicht wissen, wie ein Produkt funktioniert, wenn Sie nicht verstehen, wie seine Komponenten funktionieren, welche Dienste es benötigt und welche Hauptprobleme und Engpässe es gibt.
Wenn Sie nicht auf mögliche Engpässe achten, können Sie beim Verfassen eines Postmortems nicht die Five Whys-Technik anwenden. Sie werden nicht in der Lage sein, alles auf einen Bildschirm zu bringen, um zu sehen, wie ein Produkt funktioniert, oder um zu wissen, wie es „normal und glücklich“ aussieht.
Nach links verschieben, LINKS, ICH SAGTE LEEEE—
Für mich ist eines der Schlüsselprinzipien von Devops „Shift Left“. Eine Verschiebung nach links bedeutet in diesem Zusammenhang eine Verschiebung der Möglichkeit (keine Verantwortung, aber nur Fähigkeiten), um Dinge zu tun, die Systemingenieuren normalerweise am Herzen liegen, wie z. B. das Erstellen von Leistungsmetriken, die effizientere Verwendung von Protokollen usw., links im Software Delivery-Lebenszyklus.
Autor des Fotos auf
Softwareentwickler müssen in der Lage sein, die Überwachungstools zu nutzen und zu kennen, die das Unternehmen verwendet, um die Überwachung in all ihren Formen, Metriken, Protokollierungen, Überwachungsschnittstellen und, was am wichtigsten ist, durchzuführen. Beobachten Sie, wie ihr Produkt in der Produktion funktioniert. Sie können Entwickler nicht dazu bringen, Mühe und Zeit in die Überwachung zu investieren, bis sie die Metriken sehen und beeinflussen können, wie sie aussehen, wie der Produktbesitzer sie dem CTO beim nächsten Briefing präsentiert usw.
Kurz gesagt
- Führe dein Pferd zum Wasser. Zeigen Sie Entwicklern, wie viel Ärger sie für sich selbst vermeiden können, und helfen Sie ihnen, die richtigen KPIs und Metriken für ihre Anwendungen zu identifizieren, damit es weniger zu Geschrei seitens des Produktbesitzers kommt, der vom CTO angeschrien wird. Bringen Sie sie sanft und ruhig ans Licht. Wenn das nicht funktioniert, bestechen, drohen und überreden Sie entweder sie oder den Produktbesitzer, diese Metriken so schnell wie möglich aus den Anwendungen abzurufen, und zeichnen Sie dann die Diagramme. Dies wird schwierig sein, da es nicht als Priorität angesehen wird und die Produkt-Roadmap viele umsatzgenerierende Projekte ausstehen wird. Daher benötigen Sie einen Business Case, um den Zeit- und Kostenaufwand für die Implementierung der Überwachung in das Produkt zu rechtfertigen.
- Helfen Sie Systemingenieuren, gut zu schlafen. Zeigen Sie ihnen, dass die Verwendung einer „Lass uns veröffentlichen“-Checkliste für jedes Produkt, das veröffentlicht wird, eine gute Sache ist. Und wenn Sie sicherstellen, dass alle Anwendungen in der Produktion mit Metriken abgedeckt sind, können Sie nachts besser schlafen, da Entwickler sehen können, was wo falsch läuft. Der richtige Weg, Entwickler, Produktbesitzer oder CTOs zu irritieren und zu frustrieren, besteht jedoch darin, hartnäckig zu bleiben und Widerstand zu leisten. Dieses Verhalten wirkt sich auf das Veröffentlichungsdatum eines Produkts aus, wenn Sie erneut bis zur letzten Minute warten. Wechseln Sie also noch einmal nach links und nehmen Sie diese Probleme so schnell wie möglich in Ihren Projektplan auf. Begeben Sie sich bei Bedarf auf den Weg zu Produktbesprechungen. Tragen Sie einen falschen Schnurrbart und Filz oder so etwas, es wird nie scheitern. Kommunizieren Sie Ihre Anliegen, demonstrieren Sie klare Vorteile und verbreiten Sie das Evangelium.
- Stellen Sie sicher, dass sowohl die Entwicklung (Dev) als auch der Betrieb (Ops) die Bedeutung und Konsequenz verstehen, wenn sich Produktmetriken in den roten Bereich bewegen. Überlassen Sie Ops nicht den alleinigen Hüter der Produktgesundheit, sondern stellen Sie sicher, dass auch Entwickler einbezogen werden (#productsquads).
- Protokolle sind eine tolle Sache, aber auch Metriken. Kombinieren Sie sie und lassen Sie nicht zu, dass Ihre Holzscheite in einem riesigen brennenden Ball der Nutzlosigkeit zu Müll werden. Erklären und zeigen Sie den Entwicklern, warum niemand sonst ihre Protokolle versteht, und zeigen Sie ihnen, wie es ist, um 3:15 Uhr morgens auf nutzlose Protokolle zu schauen.
Autor des Fotos auf
Das ist alles. Neues Material wird nächste Woche veröffentlicht. Wenn Sie mehr über den Kurs erfahren möchten, laden wir Sie dazu ein , die am Montag stattfinden wird. Und jetzt warten wir traditionell auf Ihre Kommentare.
Source: habr.com