# Observability-Architektur

> Signalpfade, Zugriff, Kosten, Retention und Ausfallmodi als betriebliche Architekturentscheidung gestalten.

Track: [Monitoring, Troubleshooting & Incident Operations](https://opsmith.app/learn/monitoring-incident-operations)  
Kanonische Fassung: https://opsmith.app/learn/monitoring-incident-operations/observability-architecture  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Auch Telemetrie ist ein Produktionssystem

### Die Betriebsfrage

Wenn der Telemetriepfad unter Last ausfällt oder unautorisiert sensible Daten verbreitet, verliert der Betrieb Sicht und schafft ein zusätzliches Risiko. Architektur verbindet Signalnutzen mit Verfügbarkeit, Datenschutz, Kosten und Zugriff.

> **Lernziel:** Du kannst einen Telemetriepfad nach Datenfluss, Vertrauensgrenze, Ausfallmodus und Diagnosenutzen beurteilen.

### Architekturentscheidung

Entscheidungsrelevante Signale priorisieren → Datenklassifikation und Zugriff festlegen → Sampling, Retention und Kosten begrenzen → Pufferung und Degradation planen → Gesundheit des Telemetriepfads selbst überwachen

### Keine Scheinsicherheit

Lange Retention oder maximale Detailtiefe sind keine universellen Ziele. Attribute können Identitäten oder Geheimnisse tragen; Zugriff, Redaction und Datenminimierung gehören vor die zentrale Suche. Bei Backend-Ausfall braucht der Dienst einen definierten Degradationsmodus.

### Im Check

Du ordnest Datenflüsse nach Vertrauensgrenzen und wählst Architekturmaßnahmen, die eine spätere Diagnose ermöglichen, ohne die Produktionspfade unkontrolliert zu belasten.

## Quellen

- opentelemetry.io/docs/concepts/security — https://opentelemetry.io/docs/concepts/security/
- opentelemetry.io/docs/concepts/signals — https://opentelemetry.io/docs/concepts/signals/