Alle zusammen, es ist Freitag! Freunde, heute setzen wir unsere Serie von Beiträgen zum Kurs fort. Die neuen Kurse beginnen bereits Ende nächster Woche. Also, legen wir los!
Monitoring ist das einfach. Das ist allgemein bekannt. Starten Sie Nagios, aktivieren Sie NRPE auf dem Remote-System, konfigurieren Sie Nagios für den TCP-Port NRPE 5666 und schon haben Sie Monitoring.
Es ist so einfach, dass es fast langweilig ist. Nun haben Sie die grundlegenden Metriken zur CPU-Auslastung, Speicher, und Festplattensubsysteme, die standardmäßig in Nagios und NRPE eingesetzt werden. Aber das ist eigentlich noch nicht das „Monitoring“, wie wir es verstehen. Das ist nur der Anfang.
(Normalerweise installiert man PNP4Nagios, RRDtool und Thruk, richtet Benachrichtigungen in Slack ein und geht direkt zu nagiosexchange, aber das lassen wir hier mal weg).
Gutes Monitoring ist tatsächlich ziemlich komplex, Sie müssen wirklich die Interna der Anwendung kennen, die Sie überwachen.
Ist Monitoring kompliziert?
Jeder Server, sei es Linux oder Windows, hat eine spezifische Funktion. Apache, Samba, Tomcat, Dateispeicher, LDAP – all diese Dienste sind in einem oder mehreren Aspekten mehr oder weniger einzigartig. Jeder hat seine eigenen Aufgaben und Besonderheiten. Es gibt verschiedene Möglichkeiten, um Metriken und KPIs (Key Performance Indicators) zu erfassen, die für Sie von Interesse sind, wenn der Server unter Last steht.
Fotoautor findet man
(Ich wünschte, meine Dashboards wären in Neonblau gefärbt – seufzend träumerisch –… hm…)
Jede Software, die Dienstleistungen bereitstellt, sollte über einen Mechanismus zur Sammlung von Metriken verfügen. Apache hat das Modul mod-status, das eine Statusseite des Servers anzeigt. Nginx hat das stub_status. Tomcat bietet JMX oder spezielle Webanwendungen, die wichtige Metriken anzeigen. In MySQL gibt es den Befehl „show global status“ usw.
Warum integrieren Entwickler nicht solche Mechanismen in die Anwendungen, die sie erstellen?
Tun das nur die Entwickler?
Ein bestimmtes Maß an Gleichgültigkeit gegenüber der Implementierung von Metriken beschränkt sich nicht nur auf die Entwickler. Ich habe in Unternehmen gearbeitet, die Anwendungen mit Tomcat entwickelt haben und keinerlei eigenen Metriken oder Service-Aktivitätsprotokolle bereitgestellt haben, abgesehen von den allgemeinen Fehlerprotokollen von Tomcat. Einige Entwickler generieren ein Übermaß an Protokollen, die für den Systemadministrator, der das Pech hat, sie um 3:15 Uhr morgens lesen zu müssen, bedeutungslos sind.
Fotoautor findet man
Systemingenieure, die solchen Produkten den Markteintritt ermöglichen, sollten auch eine gewisse Verantwortung für die Situation übernehmen. Nur wenige Systemingenieure haben die Zeit oder das Interesse, bedeutungsvolle Metriken aus den Protokollen zu extrahieren, ohne den Kontext dieser Metriken und die Möglichkeit, sie im Licht der Anwendungsaktivität zu interpretieren. Einige verstehen nicht, welchen Nutzen sie daraus ziehen können, außer dass es Anzeichen für Probleme gibt – „irgendetwas stimmt momentan (oder wird bald) nicht”.
Ein Wandel im Denken über die Notwendigkeit von Metriken muss nicht nur bei den Entwicklern, sondern auch bei den Systemingenieuren stattfinden.
Für jeden Systemingenieur, der nicht nur auf kritische Ereignisse reagieren, sondern deren Auftreten auch verhindern möchte, ist das Fehlen von Metriken oft ein Hindernis.
Systemingenieure befassen sich in der Regel nicht mit dem Code, um Gewinne für ihr Unternehmen zu erzielen. Sie benötigen erfahrene Entwickler, die die Verantwortung des Systemingenieurs für die Erkennung von Problemen, die Sensibilisierung für Leistungsprobleme und dergleichen verstehen.
Dieses DevOps-Ding
Die DevOps-Mentalität beschreibt die Synergie zwischen der Denke von Entwicklern (Dev) und dem Betrieb (Ops). Jedes Unternehmen, das behauptet, „DevOps zu praktizieren“, sollte:
- sagen, was sie wahrscheinlich nicht tun (Anspielung auf den Meme aus dem Film „Die Prinzessin Braut“ – „Ich glaube nicht, dass das bedeutet, was du denkst, dass es bedeutet!“)
- eine Haltung zur kontinuierlichen Verbesserung des Produkts fördern.
Sie können ein Produkt nicht verbessern und dessen Verbesserung erkennen, wenn Sie nicht wissen, wie es aktuell funktioniert. Sie werden nicht herausfinden können, wie das Produkt arbeitet, wenn Sie die Funktionsweise seiner Komponenten, die Dienste, von denen es abhängt, sowie die Hauptprobleme und Engpässe nicht verstehen.
Wenn Sie potenzielle Engpässe nicht überwachen, werden Sie beim Schreiben eines Postmortems die Technik der "Fünf Warums" nicht anwenden können. Sie werden nicht alles auf einem Bildschirm zusammenführen können, um zu sehen, wie das Produkt funktioniert oder wie es in einem "normalen und glücklichen" Zustand aussieht.
Shift left, ICH HABE GESAGT, SHIFT LEFT—
Für mich ist eines der Schlüsselprinzipien von DevOps das "Shift Left". In diesem Kontext bedeutet Shift Left, die Möglichkeit (nicht die Verantwortung, sondern nur die Möglichkeit) zu verschieben, Dinge zu tun, um die sich normalerweise Systemingenieure kümmern, wie z. B. Leistungskennzahlen zu erstellen, Protokolle effizienter zu nutzen usw., in den frühen Phasen des Software-Lieferzyklus (Software Delivery Life Cycle).
Fotoautor findet man
Softwareentwickler müssen in der Lage sein, die Überwachungstools zu nutzen und zu verstehen, die das Unternehmen einsetzt, um sämtliche Überwachungsaspekte, Metriken, Protokollierungen und Schnittstellen zur Überwachung zu handhaben. Noch wichtiger ist es, zu beobachten, wie ihr Produkt in der Produktion funktioniert.Sie können Entwickler nicht dazu zwingen, Zeit und Mühe in die Überwachung zu investieren, solange sie die Metriken nicht sehen und Einfluss darauf nehmen können, wie der Produktinhaber diese dem CTO beim nächsten Briefing präsentiert usw.
Kurz gesagt
- Führen Sie das Pferd zur Tränke. Zeigen Sie den Entwicklern, welche Probleme sie sich ersparen können, und helfen Sie ihnen, die richtigen KPIs und Metriken für ihre Anwendungen festzulegen, damit es weniger Konflikte mit den Produktverantwortlichen gibt, die vom technischen Direktor (CTO) unter Druck gesetzt werden. Bringen Sie sie behutsam und ruhig ans Licht. Wenn das nicht funktioniert, versuchen Sie es mit Überzeugungskraft, Drohungen oder Lockangeboten, um entweder die Entwickler oder den Produktverantwortlichen dazu zu bringen, diese Metriken so schnell wie möglich aus den Anwendungen zu extrahieren, und erstellen Sie anschließend Diagramme. Das wird eine Herausforderung, da dies nicht als vorrangig betrachtet wird und es in der Produkt-Roadmap viele Projekte gibt, die auf die Umsetzung warten und Umsatz generieren. Daher benötigen Sie eine wirtschaftliche Rechtfertigung, um die Zeit und Mittel zu rechtfertigen, die für die Implementierung des Monitorings im Produkt aufgebracht werden.
- Lassen Sie Systemingenieuren die Nacht ruhig schlafen. Zeigen Sie ihnen, dass die Verwendung einer Checkliste für den "Release" bei jeder Produktveröffentlichung sinnvoll ist. Zudem hilft es, sicherzustellen, dass alle Anwendungen in der Produktion mit Metriken abgedeckt sind, um einen gesunden Schlaf zu gewährleisten. Dadurch können Entwickler erkennen, was und wo nicht funktioniert. Allerdings gibt es einen sicheren Weg, um jeden Entwickler, Produktmanager und technischen Direktor zu verärgern: ständig Hindernisse in den Weg zu legen und Widerstand zu leisten. Solches Verhalten wird das Veröffentlichungsdatum eines Produkts beeinflussen. Wenn Sie bis zur letzten Minute warten, sollten Sie wieder einen Shift nach links einplanen und diese Punkte so schnell wie möglich in das Projekt einbeziehen. Falls notwendig, schleichen Sie sich in die produktbezogenen Meetings. Tragen Sie falsche Schnurrbärte und Filzhüte oder ähnliches – das wird Sie nie im Stich lassen. Berichten Sie über Ihre Herausforderungen, zeigen Sie die klaren Vorteile auf und evangelisieren Sie.
- Stellen Sie sicher, dass sowohl Entwickler (dev) als auch Betrieb (ops) die Bedeutung und die Folgen der Verschiebung von Produktmetriken in die "rote Zone" verstehen. Lassen Sie nicht zu, dass der Betrieb der einzige Hüter der Produktverfügbarkeit ist; sorgen Sie dafür, dass auch die Entwickler daran teilnehmen (#productsquads).
- Logs sind großartig, aber Metriken sind es auch. Kombinieren Sie beides und lassen Sie Ihre Logs nicht zu Müll in einem riesigen, brennenden Ball der Nutzlosigkeit werden. Erklären und zeigen Sie den Entwicklern, warum niemand außer ihnen ihre Logs verstehen kann, und zeigen Sie ihnen, wie es ist, um 3:15 Uhr auf nutzlose Logs zu schauen.
Fotoautor findet man
Das wäre alles. Neues Material erscheint nächste Woche. Wenn Sie mehr über den Kurs erfahren möchten, laden wir Sie ein zu , der bereits am Montag stattfinden wird. Jetzt freuen wir uns traditionell auf Ihre Kommentare.
Quelle: habr.com
