Observability-Plattform auswählen: Checkliste mit 12 Kriterien

Eine Observability-Plattform auszuwählen hieß früher, das Tool mit der längsten Feature-Liste zu nehmen. 2026 decken nahezu alle ernstzunehmenden Anbieter Metriken, Logs, Traces und irgendeine Form von KI-Unterstützung ab. Feature-Listen trennen gute Entscheidungen also nicht mehr von teuren Fehlern. Was sie trennt: wie sich das Preismodell beim Wachstum verhält, ob Ihre Instrumentierung portabel bleibt, wo Ihre Daten liegen und wie schnell die Plattform Ihrem Team nachts um drei die Ursache eines Ausfalls zeigt.

Dieser Beitrag ist eine herstellerneutrale Checkliste mit zwölf Kriterien für den Vergleich von Observability Tools. Sie können sie als Gerüst für einen Anforderungskatalog oder eine Ausschreibung nutzen, als Bewertungsbogen für Ihre Shortlist oder einfach, um im nächsten Anbietergespräch bessere Fragen zu stellen. Am Ende finden Sie einen Plan für den Proof of Concept und eine gewichtete Bewertungsmatrix zum Übernehmen.

Vor dem Vergleich: Aufgabe der Observability-Plattform festlegen

Die meisten Tool-Auswahlverfahren scheitern vor der ersten Demo, weil niemand aufgeschrieben hat, welches Problem die neue Plattform lösen soll. Investieren Sie einen halben Tag in drei Grundlagen:

• Anwendungsfälle nach Nutzen sortiert: Incident Response für kundennahe Services, Kapazitätsplanung, SLO-Reporting, Security-Analysen, Kostenzuordnung, KI- und LLM-Workloads. Priorisieren Sie. Eine Plattform, die bei Ihren drei wichtigsten Fällen exzellent ist, schlägt eine, die bei zehn Fällen Mittelmaß liefert.
• Aktuelle Mengengerüste: Anzahl Hosts und Container, Metrik-Zeitreihen, Log-Volumen pro Tag in GB, Spans pro Tag, Anzahl der Personen mit Zugriff. Kennen Sie diese Zahlen nicht, erheben Sie sie zuerst. Jede Preisdiskussion hängt davon ab.
• Rahmenbedingungen: Datenresidenz, regulatorische Vorgaben (DSGVO, DORA, NIS2, Branchenregeln), Einkaufsrichtlinien, bestehende Verträge mit Laufzeiten und die Teamkapazität für eine Migration.

Diskutiert Ihr Team noch, was Observability über Dashboards hinaus bedeutet, schaffen Sie zuerst ein gemeinsames Verständnis. Unser Grundlagenartikel Was ist Observability? ist dafür ein guter Einstieg.

Die Checkliste: 12 Kriterien für die Auswahl einer Observability-Plattform

Jedes Kriterium enthält die Frage, die Sie stellen sollten, warum sie wichtig ist und wie eine gute Antwort aussieht. Später werden die Kriterien zu Zeilen Ihrer Bewertungsmatrix.

1. Preismodell und Planbarkeit der Kosten

Preise für Observability folgen vier Grundmodellen, die die meisten Anbieter kombinieren:

• Pro Host oder Node: gut planbar bei statischen VM-Landschaften, schwer vorherzusagen bei Autoscaling und kurzlebigen Containern. Fragen Sie, wie Hosts gezählt werden (Spitze, Durchschnitt, Höchststand) und was in Kubernetes und Serverless als Host gilt.
• Pro GB ingestiert oder indexiert: skaliert mit dem Datenvolumen. Klären Sie, ob Sie für Ingestion, Indexierung, Speicherung oder alles zusammen zahlen und ob verworfene Daten kostenfrei sind.
• Pro Signal oder Event: Sie zahlen pro Million Log-Einträge, Spans oder Metrik-Datenpunkte. Das bildet Kosten direkt auf Telemetrie ab, sodass sichtbar wird, welcher Service welche Rechnung verursacht.
• Pro Nutzer oder Lizenz: verbreitet bei Vollzugriffs-Lizenzen. Vorsicht vor dem Anreiz, Engineers aus dem Tool herauszuhalten. Das widerspricht dem Sinn von Observability.

Für eine Kostenschätzung rechnen Sie Ihr Mengengerüst in die Abrechnungseinheit jedes Anbieters um. Ein bewährter Ansatz: Zählen Sie Log-Einträge pro Tag statt GB (kennen Sie nur GB, messen Sie die durchschnittliche Eintragsgröße; strukturierte Logs liegen häufig zwischen einigen hundert Byte und etwa einem Kilobyte), leiten Sie Spans pro Tag aus Ihrer Sampling-Rate ab und multiplizieren Sie aktive Metrik-Zeitreihen mit der Scrape-Frequenz. Legen Sie dann eine Tabelle mit drei Zeilen an: heute, doppeltes und dreifaches Volumen. Ein Modell, das heute günstig aussieht, aber schneller wächst als Ihr Traffic, ist ein Risiko und keine Ersparnis.

2. OpenTelemetry-Unterstützung und Lock-in

Instrumentierung ist der teuerste Teil jeder Einführung, wenn man sie wiederholen muss. Fragen Sie, ob die Plattform OTLP nativ für Traces, Metriken und Logs annimmt, ob sie die OpenTelemetry Semantic Conventions ohne proprietäre Umbenennung nutzt und ob Sie Ihre Daten jederzeit in einem offenen Format exportieren können. Wer für Kernfunktionen eigene SDKs oder Agents verlangt, erzeugt Wechselkosten, die erst Jahre später sichtbar werden. Falls Sie mit dem Standard noch nicht vertraut sind, lesen Sie vor den Anbietergesprächen Was ist OpenTelemetry?.

3. Datenresidenz und DSGVO

Telemetrie enthält öfter personenbezogene Daten als gedacht: IP-Adressen, Nutzer-IDs in URLs, E-Mail-Adressen in Log-Meldungen. Klären Sie, in welchen Regionen Daten gespeichert und verarbeitet werden, welche Unterauftragsverarbeiter beteiligt sind, ob es eine Option für den Betrieb im eigenen Cloud-Konto gibt und ob personenbezogene Daten vor der Speicherung maskiert werden können. Fordern Sie den Auftragsverarbeitungsvertrag früh an. Die juristische Prüfung dauert oft länger als die technische.

4. Sicherheitszertifizierungen und Zugriffskontrolle

Verlangen Sie aktuelle Berichte statt Logos: ISO 27001, SOC 2 Type II und für den öffentlichen Sektor oder regulierte Branchen in Deutschland BSI C5. Prüfen Sie SSO und SCIM, rollenbasierte Rechte bis auf Feld- oder Datensatzebene, Audit-Logs und ob Kundendaten zum Training von KI-Modellen verwendet werden.

5. Abdeckung und Korrelation der Signale

Jede Plattform zeigt Metriken, Logs und Traces. Der eigentliche Test ist die Korrelation: Kommen Sie vom Alert zum langsamen Trace, vom Trace zu den Logs genau dieses Requests und von dort zum Host oder Pod, ohne IDs zwischen Tabs zu kopieren? Ergänzen Sie Profiling, Real User Monitoring und synthetische Checks, wenn sie auf Ihrer Liste stehen.

6. KI und Root-Cause-Analyse

KI-Funktionen reichen vom Chat über die Dokumentation bis zu Analysen, die Topologie, Änderungen und Anomalien verknüpfen. Lassen Sie sich die Belege hinter einer KI-Schlussfolgerung zeigen, nicht nur das Ergebnis. Ein guter Assistent nennt die Traces, Metriken und Deployments, auf die er sich stützt, sodass ein Engineer die Antwort in unter einer Minute prüfen kann.

7. Skalierung und Kardinalität

Attribute mit hoher Kardinalität wie Kunden-ID, Mandant oder Pod-Name machen Telemetrie erst nützlich für die Fehlersuche. Fragen Sie, ob Kardinalität Preis, Abfragegeschwindigkeit oder Aufbewahrung beeinflusst und was passiert, wenn ein Team versehentlich ein Label mit Millionen Werten ausrollt.

8. Abfragesprache und Datenzugriff

Engineers verbringen viele Stunden in der Abfrageoberfläche. Prüfen Sie, ob vertraute Sprachen wie PromQL oder SQL unterstützt werden, wie jemand ohne Expertenwissen eine Abfrage baut und ob Abfragen über API und CLI automatisierbar sind.

9. Aufbewahrung und Speicherklassen

Fragen Sie nach der Standard-Aufbewahrung pro Signal, dem Preis für längere Fristen und ob Sie heiße Daten für Tage und günstigere Archivdaten für Monate halten können. Compliance-Anforderungen an Audit-Logs unterscheiden sich oft von dem, was die Fehlersuche braucht.

10. Integrationen und Migrationsaufwand

Listen Sie die 20 Technologien auf, die für Sie am wichtigsten sind (Cloud-Services, Datenbanken, Queues, Kubernetes, CI/CD, Incident-Tools), und prüfen Sie jede einzeln, statt einer Integrationszahl zu vertrauen. Schätzen Sie den Migrationsaufwand in Personenwochen: Agents, Dashboards, Alerts, Runbooks und Schulung.

11. Betrieb und Passung zu Ihren Abläufen

Prüfen Sie Alerting, SLOs, Anbindung an Rufbereitschafts-Tools und ob sich Dashboards und Alerts als Code verwalten lassen. Was sich nicht in Git versionieren lässt, driftet auseinander.

12. Gesamtkosten (TCO) und Vertragsbedingungen

Die Lizenz ist nur eine Position. Zu den Gesamtkosten gehören Ingestion und Speicherung, Personalaufwand für den Betrieb von Agents und Pipelines, Migration, Schulung und die Opportunitätskosten langsamer Incident-Bearbeitung. Prüfen Sie auch Vertragsdetails: Mindestabnahmen, Regeln für Mehrverbrauch, Nachberechnungen und Ausstiegsklauseln.

So schätzen Sie die Gesamtkosten realistisch

Ein einfaches TCO-Modell besteht aus vier Blöcken. Halten Sie die Annahmen sichtbar, damit Stakeholder sie hinterfragen können:

1. Plattformgebühren: Ihr Mengengerüst in den Einheiten jedes Anbieters bei einfachem, doppeltem und dreifachem Volumen, inklusive Aufbewahrung und der Zusatzmodule, die Sie wirklich brauchen.
2. Betriebsaufwand: Stunden pro Monat für Agent-Updates, den Betrieb von Collector oder Pipeline, Index-Pflege und Kapazitätsplanung, multipliziert mit einem Vollkostensatz.
3. Einmalige Migration: Neu-Instrumentierung, Migration von Dashboards und Alerts, Kosten des Parallelbetriebs (Sie zahlen einige Wochen zwei Anbieter) und Schulung.
4. Risiko und Nutzen: schwerer zu beziffern, aber halten Sie es fest: erwartete Veränderung der Zeit bis zur Erkennung und Behebung von Incidents und die Kosten eines Lock-ins, falls Sie erneut wechseln müssen.

Zwei Praxistipps: Lassen Sie Anbieter Ihre Tabelle bepreisen, nicht deren Referenzkunden. Und rechnen Sie durch, was passiert, wenn Sie 30 bis 50 Prozent wenig wertvoller Logs schon bei der Ingestion filtern. Plattformen, die für verworfene Daten wenig oder nichts berechnen, belohnen gute Datenhygiene.

Proof of Concept in zwei bis vier Wochen

Ein Proof of Concept soll Ihre wichtigsten Fragen mit Ihren eigenen Daten beantworten. Eine Struktur, die in zwei bis vier Wochen passt:

1. Woche 0, Vorbereitung: Wählen Sie zwei oder drei repräsentative Services, idealerweise einen mit bekannten Performance-Problemen. Legen Sie fünf bis acht Erfolgskriterien aus der Checkliste fest, jeweils mit verantwortlicher Person.
2. Woche 1, Datenanbindung: Senden Sie Telemetrie möglichst über OpenTelemetry, damit dieselbe Instrumentierung alle Kandidaten versorgt. Messen Sie die Zeit bis zum ersten aussagekräftigen Trace und den Aufwand pro Service.
3. Woche 2, Alltag: Bauen Sie die drei wichtigsten Dashboards und fünf kritische Alerts nach. Lassen Sie die Rufbereitschaft echte Fragen mit der Plattform beantworten.
4. Woche 3, Incident-Übung: Spielen Sie einen realistischen Fehler nach (langsame Abhängigkeit, fehlerhaftes Deployment, Speicherleck) und messen Sie, wie lange jedes Team bis zur Ursache braucht.
5. Woche 4, Kosten und Sicherheit: Gleichen Sie gemessene Volumen mit den Preisen ab, schließen Sie den Sicherheitsfragebogen ab und sammeln Sie strukturiertes Feedback.

Bleiben Sie fair: dieselben Services, derselbe Zeitraum und dieselben Szenarien für jeden Anbieter.

Bewertungsmatrix für Ihren Anforderungskatalog

Gewichten Sie jedes Kriterium nach Ihren Prioritäten (Summe 100), vergeben Sie pro Anbieter 1 bis 5 Punkte und multiplizieren Sie. Die Beispielgewichte passen zu einer mittelgroßen Engineering-Organisation mit DSGVO-Anforderungen; passen Sie sie an Ihre Situation an.

Kriterium	Gewicht	So sieht eine 5 aus	Anbieter A	Anbieter B
Preismodell und Planbarkeit	12	Kosten wachsen linear mit der Telemetrie; verworfene Daten sind günstig oder kostenlos
OpenTelemetry und Portabilität	12	Natives OTLP für alle Signale; Export jederzeit
Datenresidenz und DSGVO	10	EU-Region oder eigenes Cloud-Konto; PII-Maskierung bei Ingestion
Sicherheit und Zertifizierungen	8	Aktuelle ISO-27001- und SOC-2-Type-II-Berichte; Rechte auf Feldebene
Korrelation der Signale	10	Vom Alert über Trace und Log zum Host in wenigen Klicks
KI und Root-Cause-Analyse	8	Antworten mit nachprüfbaren Belegen
Skalierung und Kardinalität	8	Hohe Kardinalität ohne Aufpreis oder langsame Abfragen
Abfragesprache und API	6	PromQL oder SQL; vollständige API und CLI
Aufbewahrung und Speicherklassen	5	Flexible Aufbewahrung pro Signal
Integrationen und Migrationsaufwand	8	Ihre Top-20-Technologien im PoC geprüft
Betrieb und As-Code-Workflows	5	Dashboards, Alerts und SLOs in Git
TCO und Vertragsbedingungen	8	Niedrigste Drei-Jahres-TCO bei dreifachem Volumen; faire Ausstiegsregeln

Behandeln Sie Kriterien, die für Ihre Organisation zwingend sind, etwa Datenhaltung in der EU, als K.-o.-Kriterium vor der Bewertung und nicht als Gewicht.

Fragen, die in jede Ausschreibung gehören

• Bitte bepreisen Sie unser Mengengerüst bei einfachem, doppeltem und dreifachem Volumen, inklusive Aufbewahrung und aller genannten Funktionen.
• Für welche Daten zahlen wir, wenn wir sie bei der Ingestion verwerfen oder samplen?
• Welche Funktionen erfordern proprietäre Agents oder SDKs statt OpenTelemetry?
• Wie exportieren wir alle unsere Daten, in welchem Format und zu welchen Kosten?
• In welchen Regionen werden Daten gespeichert und verarbeitet, und wer sind Ihre Unterauftragsverarbeiter?
• Werden Kundendaten zum Training von KI-Modellen verwendet?
• Welche Migrationsunterstützung bieten Sie, und wer trägt die Kosten des Parallelbetriebs?

Unabhängige Gegenüberstellungen helfen bei der Vorbereitung dieser Gespräche. Einen Monitoring-Tool-Vergleich gängiger Plattformen finden Sie in unserer Vergleichsübersicht.

Wo Obseria einzuordnen ist

Wir haben Obseria entlang der oben genannten Kriterien gebaut, deshalb hier kurz unsere Antworten. Obseria ist OpenTelemetry-nativ und erlaubt jederzeit den Export per OTLP. Die Preise richten sich nach Signalen, ohne Host- oder Nutzerlizenzen; gefilterte Daten kosten nur die Ingestion, und alle Funktionen sind enthalten. Daten bleiben auf Wunsch in der EU, im Vereinigten Königreich oder in Ihrem eigenen Cloud-Konto; Zertifizierungen und Berichte finden Sie auf der Seite Security und Trust. Wechseln Sie von einem anderen Tool, plant unser Migrationsteam den Parallelbetrieb mit Ihnen. Am schnellsten bewerten Sie uns mit Ihrer eigenen Checkliste in einer 14-tägigen kostenlosen Testphase mit Ihren eigenen Daten.