INTRO

Seit jeher kommen im Enterprise Umfeld eine große Anzahl von Überwachungslösungen zum Einsatz. In vielen Fällen werden auch heute noch nur recht einfache Metriken gesammelt und ausgewertet sowie Prozesse beobachtet um im offensichtlichen Fehlerfall einen Service Desk oder eine 24×7 Rufbereitschaft zu alarmieren. Dies stellt eine stiefmütterliche Behandlung der Überwachungsarchitektur dar und vernachlässigt die Potentiale neuer Methodologien und Softwarelösungen.

Durch eine moderne Überwachungsarchitektur kann die Betriebsstabilität erhöht, Incidents vermieden und Erkenntnisse gewonnen werden:

– Proaktiv Fehler erkennen bevor ein Incident auftritt um Serviceunterbrechnungen zu vermeiden anstatt diese zu erkennen und reaktiv in die Störungsbehebung zu gehen.
– Intelligente Alarmierung durch predictive Analytics anstatt starre Schwellwerte.
– Zentrales Visualisierungstool, dass diverse Datenquellen übereinanderlegen kann anstatt einer fragmentierten Ansammlung von unterschiedlichen Überwachungslösungen.
– Smarte Auswertungen erlauben es aus Daten und Informationen Erkenntnisse zu ziehen.
– Der Status von IT Systemen und Geschäftsprozessen kann in Echtzeit dargestellt werden anstatt mit zeitlicher Verzögerung ausgewertet zu werden.
– Zusätzlich kann beleuchtet werden, wie Anwendungen intern funktionieren und auch Geschäftsprozesse dargestellt werden.
– Einfache Incidents automatisiert lösen (“Self-Healing”) anstatt manueller Fehlerdiagnose und -lösung.

DIE KLASSIKER DER IT ÜBERWACHUNG

Capacity Monitoring – Hier werden die üblichen Betriebssystem Parameter wie CPU, RAM, Dateisystem & Co. Alarme werden bei Überschreitung von vordefinierten Schwellwerten verschickt.

Log Monitoring – Standard Betriebssystem Logs bzw. Events werden hier auf bestimmte Fehlermeldungen überwacht. Bei vordefinierten Fehlermeldungen werden Alarme verschickt.

HINWEIS: Die Kombination aus Capacity und Log Monitoring ist auch als USE Monitoring Methode bekannt und setzt sich aus den englischen Begriffen Utilization, Saturation und Errors zusammen.

Performance Monitoring – Falls Anwendungen nicht wie erwartet funktionieren, werden häufig spezialisierte Tools angewandt um unter die Haube zu schauen. So können z.B. durch die Anwendung verursachte CPU Last, RAM Allokationen, IOPS auf dem Dateisystem, Netzwerkverbindungen und vieles mehr analysiert und dargestellt werden. Häufig sind jedoch besondere Vorbereitungsarbeiten notwendig um anlassbezogene Performanceanalysen durchzuführen.

Business Monitoring – Dies ist keine Überwachung im technischen Sinn. Um aus Daten und Informationen Erkenntnisse zu gewinnen, können Daten aus vielen Systemen zentral in einen Datalake eingespeist werden. Diese werden dann durch ETL Prozesse transformiert und in Visualisierungstools angezeigt und als Grundlage für Geschäftsentscheidungen genutzt.

Damit alle genannten Bereiche abgedeckt werden können, werden eine Vielzahl an kommerziellen Überwachungslösungen wie z.B. HP OpenView, Splunk, Dynatrace und Tableau benötigt. Dies verursacht hohe Lizenzkosten, einen hohen Installationsaufwand durch mehrere Agenten (sowie deren Updates) und für jedes Produkt jeweils spezialisierte Projekt- und Wartungsteams. Das kann man auch anders machen!

DAS MODERNE ZEITALTER DER IT ÜBERWACHUNG

Die zuvor genannten Überwachungsansätze unterliegen inhärenten Beschränkungen und sind für einige Herausforderungen in der modernen IT schlicht ungeeignet. Wo soll denn ein Agent in einem Container installiert werden, der per Definition flüchtig ist und skalierbar sein soll? Wie überwache ich die Performance von einem PaaS Dienst, auf dessen darunterliegende Infrastruktur ich keinen Zugriff habe?

Um die Beschränkungen der zuvor genannten zu überwinden, wurden moderne Lösungsansätze entwickelt.

RED Monitoring Methode – Nein, hat nichts mit dem gleichnamigen Film RED zu tun. Trotzdem ein guter Film. RED steht hier für

• Rate: Anzahl der Anfragen pro Sekunde, die an eine Anwendung gestellt werden
• Errors: Absolute bzw. prozentuale Anzahl der Anfragen, die durch die Anwendung nicht korrekt verarbeitet werden konnten
• Duration: Zeitdauer die benötigt wird, um eine Anfrage zu verarbeiten

Hier werden Dienste wie von Benutzern oder Schnittstellenpartner mit einem bestimmten Input angefragt und die Antwort vom System registriert und die jeweilige Antwort registriert. Die Antworten werden auf bestimmte Schwellwerte geprüft und bei Bedarf ein Alarm ausgelöst.

Container – Traditionelles Capacity Monitoring auf Betriebssystemebene stößt schnell an Limitierungen wenn es darum geht den Ressourcenverbrauch von individuellen Containern zu analysieren, da aus Betriebssystemsicht häufig nur die Container Runtime als Prozess wahrgenommen wird.Hier können spezialisierte Tools wie z.B. cAdvisor Metriken bereitzustellen, die dann durch Monitoring Lösungen gesammelt, aufbereitet und dargestellt werden können.

Anwendungsmetriken – In Anwendungsmetriken schlummert mit das größte Potential moderner Überwachungslösungen, die selten von Unternehmen genutzt werden. Metriken können zur Überwachung technischer Infrastruktur, Überwachung von Anwendungsparametern und Abbildung von Geschäftsprozessen in Echtzeit nutzen. Hierzu ist nur ein Blick auf die Liste von standardmäßig verfügbaren Metriken in Anwendungen, z.B. für Prometheus, notwendig. Zudem können in eigenentwickelter Software z.B. mittels Micrometer anwendungsinterne Zustände für Monitoring System zugänglich gemacht werden und in Visualisierungstools grafisch in Echtzeit dargestellt werden.

VORTEILE, MEHRWERT UND ANWENDUNGSFÄLLE

Der treue Webserver

Szenario: Eine geschäftskritische Webseite wird auf einem Apache Webserver gehostet. Die Webseite wird laufend modifiziert. Durch eine klassische Überwachungslösung werden

• die Auslastung der Ressourcen CPU, RAM und Dateisystem
• den Status vom Apache Prozess
• die Apache Logs auf Fehlermeldungen überwacht.

Vorteile & Mehrwert: Durch den Einsatz der RED Monitoring Methode können Endpunkte am Webserver in kurzen Intervallen abgefragt und die Ergebnisse klassifiziert werden. So können Fehlerzustände schnell entdeckt werden, die durch das o.g. Szenario nicht abgedeckt sind:

• Anzahl der Anfragen (Rate): durch die Anzahl der Anfragen kann angezeigt werden, wie stark die Webseite gerade frequentiert wird sowie den Verlauf in der Vergangenheit.
• HTTP Antwort Codes (Errors): hier kann man z.B. festlegen, dass solange der HTTP Code 200 bei 99,9% aller Anfragen erreicht wird, der Webserver ordnungsgemäß funktioniert. Einzelne HTTP 404 oder 503 Fehlercodes sind z.B. nicht schlimm, da sich Anwender mal in der URL vertippen können. Sollten diese aber z.B. bei 5% der Anfragen auftreten, so sollte man aber prüfen, ob Links noch korrekt funktionieren oder ob ein Konfigurationsproblem auf dem Webserver existiert.
  Auch kann z.B. die verbliebene Laufzeit von TLS Zertifikaten überwacht werden. So kann z.B. sichergestellt werden, dass neue TLS Zertifikate korrekt eingespielt worden sind.
• Antwortzeiten (Duration): die Antwortzeiten entsprechen denen von Endbenutzern. Hierdurch können Performanceprobleme am Webserver identifiziert werden, die trotz geringer CPU/RAM Auslastung auftreten. Ursachen könnten z.B. Probleme auf der Netzwerkebene sein oder eine eingebundene Backendressource, die langsam reagiert.

Die Informationen aus den Errors können in einer modernen IT Organisation den DevOps/SRE Teams wertvolle Informationen dazu liefern, wie sich die Error Budgets am effektivsten nutzen lassen.

Die Schraubenfabrik

Szenario: In einer Schraubenfabrik steuert eine eigenentwickelte Java Anwendung eine Produktionslinie für Schrauben. Am Ende der Produktionslinie wird werden die Schrauben in einer Qualitätskontrolle automatisiert vermessen und bei Toleranzabweichung als Ausschuss aussortiert und der Verschrottung zugeführt. Die Anzahl der Schrauben im Ausschuss wird durch den Schichtleiter zum Tagesende kontrolliert. Falls der Ausschuss zu groß ausfällt, wird die Anlage für Wartungsarbeiten stillgelegt.

Vorteile & Mehrwert: Die eigenentwickelte Java Anwendung kann mittels Micrometer die Anzahl der durch die Qualitätskontrolle aussortierten Schrauben in Echtzeit zählen und bei Überschreitung von einem akzeptablen Schwellwert den Schichtleiter alarmieren. Hierdurch können Maßnahmen zur Reparatur der Produktionsanlage früher getroffen und der Ausschuss reduziert werden.

Ferner sind auch weitere Szenarien denkbar, die Einblicke in die Produktion erlauben:

• Messung einzelner Produktionsschritte und Toleranzen festgelegen, die z.B. auf eine Abnutzung vom Werkzeug dienen und einen präventiven Wartungseinsatz auslösen.
• Messung und Darstellung von Parametern der Produktionsanlage auch außerhalb vom Steuerungsterminal.
• Visualisierung der fertiggestellten Schrauben pro Produktionsschicht und Vergleich von Produktionsschichten untereinander.

Die Blackbox Datenbank

Szenario: Eine eigenentwickelte Anwendung nutzt eine Multi-Mandanten-fähige Datenbank als Daten-Backend. Die Multi-Mandanten Datenbank wird durch einen Drittdientleister betrieben. Es existiert kein administrativer Zugriff auf die Datenbank selbst oder eine Überwachungslösung, die den Betriebszustand der Datenbank anzeigt. Man ist nicht in der Lage selbstständig Performanceprobleme oder Fehler an der Datenbank zu erkennen.

Vorteile & Mehrwert: Die eigenentwickelte Java Anwendung kann die Dauer von SQL Abfragen messen und den Konnektivitätsstatus messen und mittels Micrometer einer Überwachungslösung zugänglich machen. Hierdurch kann die Performance der Multi-Mandanten Datenbank aus Anwendungssicht dargestellt werden und falls die Dauer von SQL Abfragen einen vordefinierten Schwellwert überschreitet, kann ein Alarm verschickt werden und der Drittanbieter kontaktiert werden zur Störungsbehebung.

BRINGING IT ALL TOGETHER

1. Klassische IT Überwachungansätze sind nicht mehr hinreichend – moderne Ansätze sind gefragt um erweiterte Szenarien zu bedienen oder um neue Technologien zusätzlich abdecken zu können. Hier ist wichtig zu verinnerlichen, dass sich z.B. USE und RED Monitoring Methoden gegenseitig ergänzen und nicht einander ersetzen.

2. Kosteneffizienz durch Open-Source – Viele unterschiedliche, kommerzielle Überwachungslösungen können nur auf Teilaspekte einer umfassenden IT Überwachungsarchitektur abdecken und verursachen in Summe hohe Lizenzkosten und spezialisierte Betriebsteams. Es ist in den allermeisten Fällen vorteilhaft, kosteneffizient durch eine geringe Anzahl an Open-Source Lösungen die komplette IT Überwachungsarchitektur abzudecken, auch wenn diese im Detail nicht den kompletten Funktionsumfang von kommerziellen Best-of-Breed Tools abdecken können.

3. Visualisierung von Geschäftsprozessen – Metriken können die Performance von Geschäftsprozessen transparent darstellen. Hierdurch können sowohl präventive als korrigierende Entscheidungen in Echtzeit getroffen und entsprechende Maßnahmen eingeleitet werden.

4. Aus Daten und Informationen zu Erkenntnissen gelangen – Durch die intelligente Zusammenstellung von Dashboards können Zusammenhänge und Optimierungspotentiale identifiziert werden, die zuvor bestenfalls erahnt werden konnten. Dies erlaubt fundierte Entscheidungen zu treffen und Risiken zu minimieren.

---

Wir als CLOUDETEER haben vielfältige Projekterfahrung für sichere Implementierung von Public Cloud-Diensten und als Cloud Managed Service Provider, erleben wir die täglichen Betriebs-Herausforderungen hautnah.

Darüber hinaus unterstützen wir auch Entwickler auf Ihrer Cloud-Reise, um IaaS/PaaS/SaaS optimal und sicher einzusetzen, als auch bei der Einführung von DevSecOps-Prinzipien im täglichen Software-Development-Lifecycle!

Wir LEBEN Cloud-Plattformen in allen Facetten und Kubernetes, Microservices oder Cloud-Security sind bei uns keine Add-Ons, sondern werden immer mitberücksichtigt!

Kommen Sie gerne auf uns zu. Wir erstellen Ihnen professionelle Konzepte, implementieren diese mit Ihnen gemeinsam und helfen Ihnen beim Multi-Cloud Basisbetrieb!

Fragen, Kritik, Hinweise?

Paul Mosler

E-Mail: pm @ cloudeteer.de

CLOUDETEER
Twitter: @cloudeteer
GitHub: @cloudeteer
Meetup: @CloudNatics