Gastbeitrag von Dave Josephsen, Entwickler-Evangelist bei Librato . Librato bietet eine Komplettlösung zur Überwachung und zum Verständnis der Kennzahlen, die sich auf allen Ebenen des Stacks auf Ihr Unternehmen auswirken.

Die Annahme, die allen Überwachungssystemen zugrunde liegt, ist die Existenz einer Entität, die wir nicht vollständig kontrollieren können. Etwas, das wir geschaffen haben, wie ein Flugzeug, oder auch etwas, das einfach durch ein Wunder der Biologie existiert, wie der menschliche Körper. Etwas, das perfekt wäre, wenn es nicht mit der schmutzigen, analogen Realität des Fleischraums interagieren würde; dem Spielplatz der Entropie und des Chaos, wo selbst die beste Technik, die wir erreichen können, durch Alter, menschliches Versagen und Zufall irgendwann scheitert.

Überwachen Sie, was Sie nicht kontrollieren können

Flugzeuge und Körper sind Systeme. Wir erwarten nicht nur, dass sie auf eine bestimmte Weise funktionieren, sondern wir haben auch klar definierte mentale Modelle, die ihre eigentlichen Betriebseigenschaften beschreiben – einfache Annahmen darüber, wie sie funktionieren sollten, die sich in messbaren Metriken widerspiegeln, die es uns ermöglichen, diese Systeme als „gut“ oder „schlecht“ zu beschreiben. Flugzeugreifen sollten einen Druck von 60 PSI aushalten, menschliche Herzen sollten zwischen 40 und 100 Mal pro Minute schlagen. Der JDBC-Client sollte nie mehr als einen Pool von 150 DB-Verbindungen benötigen.

Das ist Warum Wir überwachen: um ein geschlossenes Feedback zu den Betriebseigenschaften von Systemen zu erhalten, die wir nicht vollständig kontrollieren können, um sicherzustellen, dass sie innerhalb der von uns erwarteten Grenzen arbeiten. Überwachung ist grundsätzlich ein Signalverarbeitungsproblem, daher sind alle Überwachungssysteme Signalverarbeitungssysteme. Einige Überwachungssysteme erfassen und generieren Signale basierend auf realen Messungen, andere erfassen und verarbeiten Signale, um beispielsweise Visualisierung, Erkennung abweichenden Verhaltens sowie Warn- und Benachrichtigungsfunktionen zu nutzen.

Unten sehen Sie ein zugegebenermaßen stark vereinfachtes Diagramm, das die Funktionsweise von Überwachungssystemen für Dinge wie das menschliche Herz oder den Öldruck von Flugzeugen beschreibt (wobei natürlich die eher esoterischen inneren Vorgänge des menschlichen Herzens, die nicht überwacht werden können, außer Acht gelassen werden). Darin sehen wir Sensoren, die ein Signal erzeugen, das die verschiedenen Komponenten speist, die den menschlichen Bedienern operatives Feedback über das System geben.

Allzu oft sehen wir jedoch beim Entwurf von IT-Überwachungssystemen ein Muster wie in der folgenden Abbildung: Hier werden mehrere Sensoren eingesetzt, um für jede Komponente doppelte Signale zu erzeugen, die eine andere Art von Feedback erzeugen.

Es gibt viele Gründe für die Entstehung dieses Anti-Patterns. Die meisten davon laufen jedoch auf eine kognitive Dissonanz zwischen verschiedenen IT-Gruppen hinaus, die jeweils der Ansicht sind, aus einem anderen Grund zu überwachen und daher unterschiedliche Analysetools benötigen. Die Betriebs- und Entwicklungsteams könnten beispielsweise der Ansicht sein, dass sich die Überwachung von Betriebssystemmetriken grundlegend von der Überwachung von Anwendungsmetriken unterscheidet, und daher jeweils eigene Überwachungstools implementieren, um die ihrer Meinung nach exklusiven Anforderungen zu erfüllen. Bei Betriebssystemmetriken könnte das Betriebsteam davon ausgehen, dass es Zustandsdaten mit Minutenauflösung benötigt, um Warnmeldungen auszulösen, während sich die Entwicklung auf Leistungsmetriken mit Sekundenauflösung konzentriert, um die Anwendungsleistung zu visualisieren.

In Wirklichkeit haben beide Teams die gleiche Anforderung: ein Telemetriesignal, das ein Closed-Loop-Feedback von den Systemen liefert, an denen sie interessiert sind. Da jedoch jedes Team eine andere Toolchain implementiert, um diese Anforderung zu erfüllen, erzeugen sie am Ende redundante Signale, um unterschiedliche Tools zu versorgen.

Unterschiedliche Signale führen zu unvorhersehbaren Ergebnissen

Wenn unterschiedliche Datenquellen für Warnmeldungen und grafische Darstellungen verwendet werden, kann die eine oder andere Quelle falsch positive oder negative Ergebnisse liefern. Jede Quelle kann leicht unterschiedliche Metriken unter dem Deckmantel desselben Namens oder dieselbe Metrik auf leicht unterschiedliche Weise überwachen. Wenn ein Ingenieur mitten in der Nacht durch eine Warnung eines solchen Systems geweckt wird und das Visualisierungsfeedback nicht mit dem Ereignisbenachrichtigungsfeedback übereinstimmt, ist ein bereits prekär,   stressig Die verwirrende Situation wird noch schlimmer und es wird wertvolle Zeit mit der Überprüfung des einen oder anderen Überwachungssystems verschwendet.

Letztendlich ist es irrelevant, welche Quelle korrekt war. Selbst wenn jemand den erforderlichen forensischen Aufwand betreibt, um die Ursache herauszufinden, ist es unwahrscheinlich, dass in Zukunft eine sinnvolle Korrekturmaßnahme zur Synchronisierung des Verhaltens der Quellen ergriffen werden kann. Die unvermeidliche Folge ist, dass Ingenieure beide Überwachungssysteme ignorieren werden, da keinem von beiden vertraut werden kann.

Die Behebung von Fehlalarmen aufgrund unterschiedlicher Datenquellen ist nicht die Verbesserung eines unzuverlässigen Überwachungssystems, sondern vielmehr die Optimierung zweier unzuverlässiger Überwachungssysteme. Würden wir zwei verschiedene EKGs für denselben Patienten verwenden – eines zur Visualisierung und eines zur Benachrichtigung – und das Ergebnis wäre unzuverlässig, würden wir das System höchstwahrscheinlich so umgestalten, dass es mit einem gemeinsamen Signal arbeitet, und uns darauf konzentrieren, dieses Signal so genau wie möglich zu gestalten. Das heißt, der einfachste Weg, dieses Problem zu lösen, besteht darin, Warnmeldung zu dem, was Sie sehen .

Synchronisieren Sie Ihre Alarmierung und Visualisierung auf ein gemeinsames Signal  

Um Warnmeldungen zu erhalten, die auf Ihre Beobachtungen hinweisen, muss nicht jeder in der Organisation dasselbe Überwachungstool verwenden, um die für ihn interessanten Messdaten zu erfassen. Es ist lediglich erforderlich, dass die Verarbeitungs- und Benachrichtigungssysteme ein gemeinsames Eingangssignal verwenden.
Wie Sie eine Vereinheitlichung der Eingangssignale erreichen, hängt von den aktuell in Ihrem Unternehmen eingesetzten Tools ab. Wenn Sie beispielsweise ein Nagios/Ganglia-Unternehmen betreiben, können Sie Nagios so modifizieren, dass es auf von Ganglia erfassten Daten hinweist, anstatt einen Stream von Metrikdaten von Ganglia zur Visualisierung und ein anderes Signal von Nagios zur Benachrichtigung zu erfassen.

Librato und PagerDuty eignen sich hervorragend für die zentrale Verarbeitung der Telemetriesignale aller in Ihrem Unternehmen eingesetzten Datensammler. Dank der schlüsselfertigen Integration in AWS und Heroku sowie der Unterstützung von fast 100 Open-Source-Monitoring-Tools, Log-Sinks, Instrumentierungsbibliotheken und Daemons können Sie Ihre aktuellen Tools ganz einfach so konfigurieren, dass sie Metriken an Librato senden.

Durch die Kombination von Librato und PagerDuty können alle Ingenieure jedes Teams Ereignisse in Ihren Telemetriesignalen problemlos verarbeiten, visualisieren und korrelieren sowie Benachrichtigungen und Eskalationen senden, die garantiert die Daten in diesen Visualisierungen widerspiegeln. Ihre Ingenieure können die gewünschten Tools nutzen und gleichzeitig sicherstellen, dass die von diesen Tools ausgegebenen Signale genutzt werden können, um allen Mitarbeitern im Unternehmen effektives und zeitnahes Feedback zu geben. Melden Sie sich an für Kostenlose Librato-Testversion heute und erfahren Sie, wie Sie Integrieren Sie PagerDuty mit Librato .