Monitoring → Observability

Jede regulierte IT-Abteilung betreibt bereits Monitoring. Nagios oder Checkmk überwacht Hosts, ein paar hundert Schwellenwert-Alerts, eine Grafana-Wand im NOC und eine Pikett-Rotation, die gelernt hat, welche Alerts man ignoriert. Das funktioniert — in dem Sinne, dass Ausfälle bemerkt werden.

Dann stellt ein Prüfer eine Frage, die Monitoring nicht beantworten kann: Zeigen Sie mir, dass während des Vorfalls vom 12. März keine Kundendaten die Schweiz verlassen haben, und zeigen Sie mir, wer sie hätte sehen können. Kein Schwellenwert-Alert hat dazu eine Meinung. Das ist die Lücke, die Observability schliessen soll — und in einer regulierten Schweizer Umgebung (FINMA-Rundschreiben 2018/3 Outsourcing, revDSG, das interne Kontrollsystem einer Kantonalbank) ist das Schliessen dieser Lücke eine andere Aufgabe als bei einem Startup.

Die Unterscheidung, auf die es wirklich ankommt

Die Lehrbuchdefinition — Monitoring sagt Ihnen, ob etwas Bekanntes kaputtging, Observability lässt Sie fragen, warum etwas kaputtging, das niemand erwartet hat — ist richtig, aber für ein Budgetgespräch wenig brauchbar. In einem regulierten Bestand ist der praktische Unterschied enger und schärfer:

• Monitoring beantwortet Fragen, die Sie vorher aufgeschrieben haben. Jeder Check ist eine Hypothese, die jemand hatte: Disk über 90 %, Dienst antwortet nicht, Zertifikat läuft ab. Wurde ein Fehlermodus nicht vorhergesehen, gibt es keinen Check dafür.
• Observability hält genug Nachweise vor, um Fragen zu beantworten, an die Sie noch nicht gedacht haben. Das ist das ganze Versprechen. Und genau deshalb kostet es mehr und interessiert es die Compliance: Sie halten jetzt eine deutlich reichhaltigere Aufzeichnung dessen vor, was Ihre Systeme getan haben — und ein Teil dieser Aufzeichnung besteht aus regulierten Daten.

Diesen zweiten Punkt überspringen die meisten Migrationspläne. Observability ist nicht nur besserer Betrieb — sie ist eine Entscheidung über die Aufbewahrung von Daten, und in einer regulierten Umgebung ist eine Aufbewahrungsentscheidung eine rechtliche.

Wonach ein Prüfer tatsächlich fragt

Engineering-Teams bereiten sich meist auf die falsche Prüfung vor. Die Fragen, die in einem FINMA-relevanten Audit oder einer internen IKS-Prüfung aufkommen, betreffen selten die Qualität der Dashboards:

• Wo werden diese Daten verarbeitet, und durch wen? Nicht „welcher SaaS-Anbieter” — welche Rechtseinheit, in welcher Jurisdiktion, unter welchem Vertrag, mit welchen Unterauftragsverarbeitern.
• Was steckt darin? Ob Telemetrie Personendaten nach revDSG oder kundenidentifizierende Daten unter dem Bankkundengeheimnis enthält, ist eine Frage des Inhalts, nicht des Werkzeugs. Warum das zwei verschiedene Probleme sind und ein Scanner nur eines davon löst, steht in PII vs CID (englisch).
• Wer kann ändern, was erfasst wird? Wenn jeder Engineer eine Collector-Konfiguration auf einem Host bearbeiten und ein neues Feld an einen Dritten schicken kann, ist Ihre Kontrolle Dokumentation, keine Durchsetzung.
• Können Sie belegen, was am 12. März lief? Nicht, was das Repository als Sollzustand auswies — was der Node tatsächlich ausführte. Das ist Config-Drift, und es ist die Frage, die aus einem sauberen Audit eine Feststellung macht.

Keine dieser vier Fragen wird dadurch beantwortet, dass Sie Traces hinzufügen. Sie werden beantwortet, indem Sie die Erfassungsschicht kontrollieren.

Warum die übliche Migrationsreihenfolge verkehrt herum ist

Der gängige Plan lautet: Observability-Backend auswählen, alles hineinschicken, dann über Governance nachdenken. In einem regulierten Bestand scheitert das auf eine spezifische und teure Weise.

Sobald Telemetrie in einem Backend eines Dritten liegt, ist jede weitere Compliance-Frage rückwirkend. Sie verhandeln nun Löschung, feldgenaue Zugriffsrechte und Datenresidenz mit einem Anbieter, dessen Produkt nicht um Ihre kantonale Aufsicht herum entworfen wurde. Der günstigste Moment, um zu entscheiden, was Ihr Netzwerk verlässt, ist bevor es Ihr Netzwerk verlässt — was heisst, dass die Entscheidung in die Erfassungsschicht gehört, nicht ins Backend.

Die Reihenfolge, die ein Audit übersteht, ist:

1. Erfassung standardisieren. Ein Agent, ein Wire-Format. OpenTelemetry ist die naheliegende Wahl, weil es ein Standard ist und nicht der Agent eines Anbieters — eine ehrliche Abgrenzung steht in was OpenTelemetry ersetzen kann und was nicht.
2. Eine Pipeline in die Mitte setzen. Eine Schicht, die Sie kontrollieren, zwischen den Systemen, die Telemetrie erzeugen, und dem, was sie speichert. Das ist das Stück, das den meisten Stacks fehlt; dort finden Redaction, Routing und Volumenkontrolle physisch statt.
3. Erst dann Backends wählen. Möglicherweise mehrere. Ist die Erfassung standardisiert und die Pipeline Ihre, wird das Backend zu einer austauschbaren Komponente statt zu einer Zehnjahresbindung.

In dieser Reihenfolge werden die Compliance-Kontrollen strukturell: Ein Feld, das auf dem Host maskiert wird, kann nicht aus einem Backend lecken, weil es nie dort ankam.

Wie das in der Praxis aussieht

Konkret leisten drei Kontrollen den grössten Teil der Arbeit in einem regulierten Bestand:

• An der Quelle maskieren. Redaction läuft im Collector auf dem Host, vor dem Egress, sodass der sensible Wert die Netzwerkgrenze nie überschreitet. Das ist eine materiell andere Aussage als „der Anbieter verschlüsselt at rest” — siehe PII in Logs maskieren.
• Nach Klassifizierung routen. Kundenidentifizierende Datensätze gehen an ein On-Premises-Ziel; anonyme Betriebsmetriken dürfen an ein Cloud-Backend. Eine Pipeline, verschiedene Ziele, entschieden per Attribut statt in der Hoffnung, dass Teams ihre Agents richtig konfigurieren — Route Telemetry by Attribute (englisch).
• Die Konfiguration autoritativ und auditierbar machen. Zentrale Config, versioniert, über OpAMP ausgerollt, mit einer Aufzeichnung, wer wann was geändert hat. Lokale Edits hören auf, die Autorität zu sein — was Drift von etwas, das man erkennt, in etwas verwandelt, das grösstenteils gar nicht passieren kann: Governance und Durchsetzung.

Die ehrlichen Kompromisse

Das ist nicht gratis, und ein Plan, der etwas anderes behauptet, übersteht den ersten Lenkungsausschuss nicht:

• Sie betreiben jetzt eine Pipeline. Sie ist Infrastruktur, die ausfallen kann, sitzt zwischen Ihrer Telemetrie und Ihren Backends und braucht ein eigenes Verfügbarkeitskonzept — siehe Collector-High-Availability.
• Das Telemetrievolumen wächst. Reichhaltigere Nachweise sind mehr Bytes. Die Kostenkontrolle muss von Anfang an mitentworfen werden, statt auf einer Rechnung entdeckt zu werden.
• OpenTelemetry ersetzt Ihr Backend nicht. Es ersetzt Erfassung und Transport. Dashboards, Alert-Regeln und Langzeitspeicherung müssen weiterhin von irgendwoher kommen, und sie neu zu bauen ist echte Arbeit.
• Traces sind der schwierigste Teil. Metriken und Logs lassen sich leicht migrieren. Distributed Tracing verlangt Instrumentierung der Anwendungen, also Entwicklungskapazität, also ein Roadmap-Gespräch statt eines Infrastrukturgesprächs.

Wo anfangen

Wenn Ihr Monitoring funktioniert und Ihr Prüfer härtere Fragen stellt, müssen Sie nichts herausreissen. Beginnen Sie dort, wo Compliance-Risiko und Kosten beide sitzen:

1. Inventarisieren Sie, was heute das Netzwerk verlässt — welche Agents schicken was, an wen, unter welchem Vertrag. Die meisten Bestände entdecken hier mindestens eine Überraschung.
2. Setzen Sie einen Collector in den Pfad für ein volumenstarkes, wenig sensibles Signal. Erproben Sie das Muster, ohne regulierte Daten anzufassen.
3. Ergänzen Sie Redaction und Routing für eine wirklich sensible Quelle und verifizieren Sie die Maskierung an einem echten erfassten Sample statt an einem Unit-Test.
4. Dann erweitern Sie Backend für Backend, während die Erfassungsschicht konstant bleibt.