Seminar Cloud&Heat Titan / SecuStack – Logging, Monitoring und Alerting

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar entwickelt eine durchgängige Betriebsbeobachtung vom Hardwarezustand über Kubernetes und Yaook bis zu OpenStack und Workloads. Metriken, Dashboards, Logs, Request-IDs, Alarmregeln, Eskalationen und Runbooks werden als integriertes Verfahren behandelt.

Lernziele

• relevante Signalquellen und Verantwortlichkeiten vollständig erfassen
• aussagekräftige Dashboards aus SLOs und Fehlerdomänen ableiten
• Protokolle über Zeit, Objekt-ID und Request-ID korrelieren
• handlungsrelevante Alarmregeln mit geringem Rauschen entwickeln
• Alarmierung, Eskalation und Runbooks praktisch testen

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud Operations, Monitoring, Site Reliability Engineering, Plattformadministration, Network Operations Center und technische Serviceverantwortung.

Voraussetzungen: Grundkenntnisse im Betrieb von Linux, Kubernetes oder OpenStack. Erfahrung mit Metrik- und Logsystemen ist hilfreich.

Seminarinhalte

Tag 1: Signalquellen, Metriken und zentrale Logs

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Monitoring-Architektur und Signalquellen

Monitoring verbindet Infrastruktur-, Kubernetes-, OpenStack- und Workload-Signale zu einer belastbaren Betriebsübersicht.

1. Schritt 1 – Signalquellen erfassen: Hardware-Sensoren, Betriebssysteme, Kubernetes, Operatoren, OpenStack-Dienste und externe Prüfungen werden inventarisiert.
2. Schritt 2 – Verantwortung zuordnen: Metriken werden einem Dienst, einer Fehlerdomäne und einem betrieblichen Eigentümer zugeordnet.
3. Schritt 3 – Erfassungswege prüfen: Exporter, ServiceMonitors, Scraping, Aufbewahrung und Zugriff werden auf Vollständigkeit und Ausfallsicherheit bewertet.
4. Schritt 4 – Lücken erkennen: Nicht überwachte Abhängigkeiten, unklare Grenzwerte und fehlende End-to-End-Prüfungen werden dokumentiert.

Praxisbezug: Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.

Metriken, Dashboards und SLOs

Dashboards werden aus Betriebszielen abgeleitet und trennen Verfügbarkeit, Sättigung, Fehler und Latenz.

1. Schritt 1 – Betriebsziel definieren: Service Level Indicators und messbare Ziele werden für zentrale Plattformfunktionen festgelegt.
2. Schritt 2 – Metriken auswählen: Auslastung, Fehlerquote, Latenz, Queue-Zustand, Replikate und Kapazitätsreserve werden nach Aussagekraft priorisiert.
3. Schritt 3 – Dashboard strukturieren: Gesamtzustand, Dienstsicht, Fehlerdomänen und Detaildiagnose werden in getrennten Ebenen dargestellt.
4. Schritt 4 – Grenzwerte validieren: Warn- und Kritisch-Schwellen werden anhand Normalbetrieb, Lasttest und bekannten Störungen überprüft.

Praxisbezug: Entwurf eines Dashboards für API-Verfügbarkeit, Compute-Kapazität, Netzwerkfehler und Storage-Latenz.

Zentrale Protokollierung und Korrelation

Zentrale Logs ermöglichen die zeitliche und technische Korrelation von Nutzeraktion, API-Aufruf, Operatorreaktion und Infrastrukturereignis.

1. Schritt 1 – Quellen priorisieren: Audit-, API-, Operator-, Kubernetes-, System- und Hardwarelogs werden nach Diagnose- und Nachweiswert bewertet.
2. Schritt 2 – Felder standardisieren: Zeit, Host, Dienst, Namespace, Projekt, Request-ID, Schweregrad und Ereignistyp werden einheitlich erfasst.
3. Schritt 3 – Aufbewahrung festlegen: Hot-, Such- und Archivzeiträume werden aus Betriebs- und Nachweisanforderungen abgeleitet.
4. Schritt 4 – Suchmuster entwickeln: Request-ID, Instanz-ID, Port-ID und Zeitfenster werden für wiederkehrende Diagnosepfade kombiniert.

Praxisbezug: Korrelation eines fehlgeschlagenen API-Aufrufs über mehrere Dienst- und Operatorlogs.

Tag 2: Alarmierung, Runbooks und Incident-Übergabe

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Alerting und Eskalationslogik

Alarmierung soll handlungsrelevante Zustände melden, Rauschen begrenzen und eine eindeutige Reaktion auslösen.

1. Schritt 1 – Alarmziel bestimmen: Jeder Alarm erhält Ursache, Auswirkung, Zuständigkeit und erwartete Erstreaktion.
2. Schritt 2 – Bedingung formulieren: Schwelle, Dauer, Mehrfachbedingung und Abhängigkeit von Wartungsfenstern werden präzise festgelegt.
3. Schritt 3 – Routing einrichten: Priorität, Bereitschaft, Fachgruppe, Eskalationsstufe und Kommunikationsweg werden zugeordnet.
4. Schritt 4 – Wirksamkeit testen: Auslösung, Zustellung, Quittierung, Runbook-Aufruf und Entwarnung werden regelmäßig geprüft.

Praxisbezug: Entwicklung und Test eines Alarmsets für Kapazitätsmangel, API-Ausfall und gestörte Reconciliation.

Runbooks und Standardverfahren

Runbooks übersetzen bekannte Betriebsfälle in reproduzierbare Schritte mit Vorbedingungen, Prüfungen und Rückfall.

1. Schritt 1 – Auslöser beschreiben: Symptom, Alarm, Grenzwert oder Änderungsanlass wird eindeutig definiert.
2. Schritt 2 – Vorprüfung festlegen: Berechtigung, Ausgangszustand, betroffene Systeme, Backup und Wartungsfenster werden vor dem Eingriff geprüft.
3. Schritt 3 – Handlungsschritte ordnen: Befehle und Kontrollen werden in kleinste prüfbare Einheiten mit erwarteten Ergebnissen zerlegt.
4. Schritt 4 – Abschluss sichern: Funktionstest, Monitoring, Dokumentation, Ticketabschluss und gegebenenfalls Problem-Record werden festgelegt.

Praxisbezug: Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.

Incident Management und Eskalation

Störungen werden nach Auswirkung priorisiert, technisch stabilisiert und mit klarer Kommunikation bis zur Ursachenanalyse geführt.

1. Schritt 1 – Incident eröffnen: Zeitpunkt, Auswirkung, betroffene Services, aktuelle Symptome und verantwortliche Leitung werden festgehalten.
2. Schritt 2 – Stabilisierung priorisieren: Schadensbegrenzung, Wiederherstellung und Beweissicherung werden vor nicht notwendigen Detailanalysen behandelt.
3. Schritt 3 – Arbeitsstränge koordinieren: Infrastruktur, Kubernetes, OpenStack, Netzwerk, Storage und Kommunikation erhalten klar abgegrenzte Aufgaben.
4. Schritt 4 – Nachbereitung durchführen: Ursache, beitragende Faktoren, Wirksamkeit der Reaktion und dauerhafte Maßnahmen werden dokumentiert.

Praxisbezug: Bearbeitung eines simulierten Major Incidents mit Rollen, Lageprotokoll, Stabilisierung und Nachbereitung.

Praxislabor

• Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.
• Entwurf eines Dashboards für API-Verfügbarkeit, Compute-Kapazität, Netzwerkfehler und Storage-Latenz.
• Korrelation eines fehlgeschlagenen API-Aufrufs über mehrere Dienst- und Operatorlogs.
• Entwicklung und Test eines Alarmsets für Kapazitätsmangel, API-Ausfall und gestörte Reconciliation.
• Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.
• Bearbeitung eines simulierten Major Incidents mit Rollen, Lageprotokoll, Stabilisierung und Nachbereitung.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.