Observability as Code und produktiver Betrieb

Observability as Code

0:00 In den letzten Modulen ist viel entstanden: Collector-Konfiguration, Dashboards, Alarmregeln, Service Level Objectives. Die Frage dieses Moduls lautet: Wo liegt das eigentlich? Wenn die Antwort „in der Oberfläche" lautet, haben Sie ein Problem, das erst beim Umzug, beim Ausfall oder bei der zweiten Umgebung sichtbar wird.

0:20 Ein handgeklicktes Dashboard überlebt keinen Umzug. Eine Datei schon. Wir schauen uns an, wie man das ändert — und sprechen über Zugriffsschutz, den man bei Telemetrie gern vergisst.

Observability as Code und produktiver Betrieb

0:31 Drei Kapitel. Zuerst die Versionierung: Was lässt sich als Datei bereitstellen, und wo gehört es hin? Dann der kontrollierte Weg einer Änderung von Test nach Produktion, einschließlich der Frage, wer eigentlich den Observability-Stack überwacht. Und drittens Zugriff und Abgrenzung — Verschlüsselung, Authentifizierung, Mandantentrennung. In der Übung bauen Sie Pfandwerks Observability aus Dateien neu auf.

Konfiguration versionieren

0:57 Beginnen wir mit dem, was überhaupt möglich ist. Die gute Nachricht: fast alles. Grafana kann Datenquellen, Dashboards und Alarmierung aus Dateien beziehen, und die Collector-Konfiguration ist ohnehin schon eine Datei. Es fehlt meist nur die Entscheidung, diesen Weg konsequent zu gehen — und die Bereitschaft, die Oberfläche danach als Anzeige zu behandeln und nicht als Arbeitsplatz.

1:20 Grafana kann Datenquellen, Dashboards, Plugins und Alarmierungsressourcen aus Dateien bereitstellen. Der Bereitstellungsordner gliedert sich entsprechend, und die Dashboard-Anbieter verweisen über einen Pfad auf die JSON-Definitionen im Dateisystem. Das klingt nach einem technischen Detail und ist eine Grundsatzentscheidung: Ab diesem Moment ist die Oberfläche eine Anzeige und nicht mehr die Wahrheit.

1:42 Wer etwas ändern will, ändert die Datei. Das ist ungewohnt und nach zwei Wochen selbstverständlich. Fünf Zeilen, und zwei Dinge sind daran bemerkenswert. Das Erste: Es ist wirklich so einfach — Name, Typ, Adresse, fertig. Die Hemmschwelle ist niedriger, als die meisten vermuten. Das Zweite steht in der Adresszeile: Der Wert kommt aus einer Umgebungsvariablen.

2:04 Damit ist dieselbe Datei für Test und Produktion brauchbar, und Sie brauchen keine zwei Fassungen, die auseinanderlaufen. Genau diese Technik verhindert den häufigsten Fehler beim Einstieg — nämlich je Umgebung eine eigene, leicht abweichende Konfiguration. Die dritte Spalte ist die Begründung. Ohne versionierte Collector-Konfiguration kennt niemand den aktuellen Stand — und das ist im Störfall eine schlechte Ausgangslage.

2:31 Ohne versionierte Datenquellen unterscheiden sie sich je Umgebung, meist unbemerkt. Ohne versionierte Dashboards entstehen Kopien und Karteileichen, wie in Modul sechzehn besprochen. Und ohne versionierte Alarmregeln ist nicht nachvollziehbar, wer wann was geändert hat. Die Fußzeile nennt noch Git Sync, das mit Grafana 13 dazugekommen ist und die Verbindung zum Git-Arbeitsablauf herstellt.

2:54 Der erste Punkt ist der häufigste Rückfall: Dashboards werden bereitgestellt und trotzdem in der Oberfläche verändert — bis die nächste Bereitstellung die Änderung überschreibt und jemand sehr verärgert ist. Klären Sie diese Erwartung im Team. Der zweite ist eine halbe Lösung: Die Dateien existieren, liegen aber in keinem Repository.

3:13 Der dritte ist ein Sicherheitsfehler — Zugangsdaten im Klartext in der Datenquellendatei; dafür sind die Umgebungsvariablen da. Und der vierte ist ein Konfigurationsfehler, der beim Suchen viel Zeit kostet: Der Pfad im Anbieter zeigt woandershin.

Änderungen kontrolliert ausrollen

3:28 Wenn die Konfiguration im Repository liegt, stellt sich die nächste Frage: Wie kommt eine Änderung von dort in die Produktion? Die Antwort ist erfreulich langweilig — genauso wie Anwendungscode, mit Prüfung und Beförderung. Dabei stolpern wir allerdings über ein Thema, das viele Teams übersehen und das im Ernstfall teuer wird: Wer überwacht eigentlich die Überwachung?

3:49 Eine Änderung an Dashboards, Regeln oder Collector-Konfiguration durchläuft denselben Weg wie Anwendungscode: Prüfung, Test in einer Umgebung, Beförderung in die nächste. Sichern und Wiederherstellen gehören dazu. Und dann der Satz, der oft für Stirnrunzeln sorgt: die Überwachung des Observability-Stacks durch sich selbst.

4:08 Das klingt zirkulär, ist aber notwendig — wobei der Alarm über einen Weg laufen sollte, der nicht von der überwachten Komponente abhängt. Vier Stationen, und sie sind bewusst identisch mit dem Weg von Anwendungscode. Änderung, Prüfung, Testumgebung, Produktion. Der einzige Unterschied zum Anwendungscode liegt darin, dass die Prüfung anders aussieht: Bei einer Alarmregel prüfen Sie, ob sie in der Testumgebung überhaupt auslösen kann — was oft nicht der Fall ist, weil dort keine Last herrscht.

4:37 Deshalb gehört zur Prüfung meist eine simulierte Störung. Das ist mehr Aufwand als ein Codereview und lohnt sich, weil eine fehlerhafte Alarmregel in Produktion sofort viele Menschen erreicht. Der erste Punkt ist die zentrale Einsicht: Ein stiller Collector erzeugt keine Alarme, weil er keine Daten mehr liefert. Ausbleibende Daten sehen im Dashboard aus wie ein ruhiger Tag — und das ist die gefährlichste aller Darstellungen.

5:02 Prometheus, Collector und Grafana melden eigene Kennzahlen; die sind da, man muss sie nur auswerten. Und der vierte Punkt ist eine konkrete Empfehlung: Mindestens ein Alarm sollte auf fehlende Telemetrie ansprechen. Das ist wenig Aufwand und schließt die größte Lücke im ganzen Aufbau. Der erste Punkt ist der ungeprüfte Regelwechsel, der in Produktion eine Lawine auslöst.

5:24 Der zweite ist das fehlende Backup — ein verlorenes Dashboard ist dauerhaft weg, wenn es nur in der Oberfläche existierte. Der dritte ist der unbemerkte Collector-Ausfall, über den wir gerade gesprochen haben. Und der vierte ist subtil und ärgerlich: Die Testumgebung hat andere Labels, und die Regel greift dort nie — Sie prüfen also erfolgreich etwas, das in Produktion anders aussieht.

5:47 Halten Sie die Labelstruktur zwischen den Umgebungen gleich.

Zugriff und Abgrenzung

5:51 Im letzten Kapitel geht es um ein Thema, das bei Observability erstaunlich oft unter den Tisch fällt: Sicherheit. Dabei ist eine Telemetrie-Pipeline ein offener Eingang ins Netz, sie transportiert fachliche Daten aus Ihren Anwendungen, und sie kostet Geld pro eingespeistem Byte. Drei gute Gründe, genauer hinzusehen, bevor jemand anders es tut.

6:12 Vier Bereiche: OTLP-Endpunkte mit Verschlüsselung und Authentifizierung, Rollen und Berechtigungen in Grafana, Mandantentrennung zwischen Umgebungen und Teams, und der Schutz vor unkontrollierter Einspeisung. Dieser letzte Punkt ist der, den man am seltensten auf der Liste findet. Ein offener OTLP-Endpunkt nimmt von jedem alles entgegen — und das ist nicht nur ein Sicherheitsrisiko, sondern auch ein finanzielles, weil jedes eingespeiste Byte Speicher kostet.

6:38 Diese vier Fragen können Sie als Prüfliste für jede Umgebung verwenden. Ist der Endpunkt verschlüsselt und authentifiziert? Kann jeder beliebig viele Daten schicken? Sieht ein Team die Daten eines anderen? Wie lange bleibt was gespeichert, und was kostet das? Bemerkenswert ist die vierte Frage, weil sie zwei Themen verbindet, die selten zusammen diskutiert werden: Aufbewahrung ist gleichzeitig eine Datenschutz- und eine Kostenfrage.

7:04 Wer beides zusammen betrachtet, kommt oft zu kürzeren Fristen — und zu niedrigeren Rechnungen. Vier Punkte. Wer senden darf, kann das Budget eines anderen aufbrauchen — ein fehlerhaft konfigurierter Testdienst genügt. Telemetrie enthält fachliche Attribute und damit oft Schützenswertes; das ist die direkte Folge davon, dass wir in Modul sechs fachliche Attribute eingeführt haben.

7:27 Ohne Mandantentrennung sieht jede Rolle alle Umgebungen. Und der vierte Punkt ist eine praktische Empfehlung: Aufbewahrungszeiten sind die wirksamste Kostenstellschraube — und gleichzeitig die am wenigsten diskutierte. Sie sichern jetzt den OTLP-Endpunkt ab, sodass nur authentifizierte Absender angenommen werden. Erfolgskriterium ist nicht die Konfiguration, sondern die Gegenprobe: Ein Sendeversuch ohne Berechtigung wird abgewiesen und ist im Protokoll nachweisbar.

7:55 Der Hinweis sagt, warum das so formuliert ist — eine Konfiguration ohne Gegenprobe ist eine Absichtserklärung. Ich habe schon Endpunkte gesehen, die nach allen Regeln abgesichert aussahen und wegen einer Reihenfolge in der Konfiguration trotzdem alles annahmen. Der erste Punkt ist genau dieser Fall: Der Endpunkt ist erreichbar, weil die Absicherung nur im Gateway gedacht war — die Agenten aber direkt erreichbar sind.

8:20 Der zweite ist Verwaltungsaufwand, der irgendwann kippt: Berechtigungen je Person statt je Rolle. Der dritte ist eine verschenkte Stellschraube — überall dieselbe Aufbewahrung, obwohl Traces, Metriken und Logs sehr unterschiedlich viel kosten. Und der vierte ist eine Scheinlösung: Mandantentrennung über ein gemeinsames Label. Ein Label ist keine Grenze, es ist eine Beschriftung.

Übung

8:43 In der Übung überführen Sie die gesamte Umgebung in Dateien — und machen dann die einzige Probe, die wirklich zählt: Sie bauen alles aus dem Nichts neu auf. Was dabei fehlt, existierte nur in der Oberfläche. Diese Probe ist unbestechlich, und sie fördert in fast jedem Projekt mindestens eine Kleinigkeit zutage, die jemand zwischendurch geklickt hat.

9:03 Das Ziel: Collector-Konfiguration, Datenquellen, Dashboard und Alarmregeln liegen als Dateien im Repository, lassen sich automatisiert bereitstellen, und der Weg einer Änderung ist beschrieben. Der Hinweis nennt die Probe: Eine leere Grafana-Instanz muss allein aus den Dateien wieder dieselbe Umgebung ergeben. Diese Probe ist unbestechlich.

9:23 Sie werden mit ziemlicher Sicherheit mindestens eine Kleinigkeit finden, die jemand zwischendurch geklickt hat — und genau dafür macht man sie. Der rote Faden sammelt zusammen, was in den letzten Modulen entstanden ist: erst die Collector-Konfiguration aus den Modulen acht bis zehn, dann Datenquellen und Dashboard, dann die Regeln aus siebzehn und achtzehn.

9:43 Im vierten Schritt der Neuaufbau aus dem Nichts. Und im fünften der Änderungsweg samt Prüfung und Zuständigkeit — denn eine reproduzierbare Umgebung ohne geklärten Änderungsweg läuft innerhalb von Wochen wieder auseinander. Die Fußzeile bringt es auf den Punkt: Erst der erfolgreiche Neuaufbau ist der Beweis. Der erste Punkt ist die ausgelassene Probe — und damit die unentdeckte handgeklickte Einstellung.

10:07 Der zweite ist ein Sicherheitsfehler, der beim Versionieren besonders leicht passiert: Zugangsdaten wandern mit ins Repository; einmal dort, sind sie in der Historie und müssen als kompromittiert gelten. Der dritte ist eine halbe Umsetzung: Dateien ja, Automatisierung nein — dann bleibt die Bereitstellung Handarbeit mit anderen Mitteln.

10:26 Und der vierte ist der organisatorische Dauerbrenner: Der Änderungsweg ist beschrieben, aber niemand ist für die Prüfung benannt.