Observability für Entwickler, gebaut auf offenen Standards
Behalten Sie Ihre OpenTelemetry SDKs, ändern Sie einen Exporter und fragen Sie Traces, Logs und Metriken im Terminal, in der IDE oder per Coding-Agent ab.
Werkzeuge, die zu Ihrer Arbeitsweise passen
Keine proprietären Agenten, kein neuer Workflow: Obseria ist dort, wo Sie ohnehin arbeiten, im Terminal, im Editor und im Pull Request.OpenTelemetry-nativ
Jedes OTel SDK und jeder Collector funktioniert ab dem ersten Tag. Semantic Conventions werden direkt genutzt, nicht in ein proprietäres Modell übersetzt.
Eine Abfragesprache
OQL nutzt eine gut lesbare Pipe-Syntax für Logs, Metriken, Traces und Events. PromQL und SQL funktionieren auf denselben Daten.
CLI, API und MCP-Server
Alles, was die Oberfläche kann, lässt sich abfragen, automatisieren und skripten. Der MCP-Server gibt Coding-Agenten dieselben Daten mit Ihren Berechtigungen.
Configuration as Code
Dashboards, Alerts, SLOs und Workflows liegen in Git, werden per Pull Request geprüft und über Ihre Pipeline ausgerollt.
IDE-Integrationen
Produktions-Traces, Fehler und Profile direkt neben dem Code in VS Code und JetBrains, ohne Kontextwechsel.
Kein Lock-in
Ihre Telemetrie bleibt in offenen Formaten. Export per OTLP jederzeit möglich, Ihre Instrumentierung bleibt Ihre.
Schon mit OpenTelemetry unterwegs? Exporter ändern, fertig
Wenn Ihre Services bereits an einen OpenTelemetry Collector senden, ergänzen Sie Obseria als OTLP-Exporter und laden die Konfiguration neu. Traces, Logs und Metriken behalten ihre Resource-Attribute und Semantic Conventions, Service-Namen, Umgebungen und Versionen erscheinen genau so, wie Sie sie definiert haben.
- Standard-OTLP über gRPC oder HTTP, kein herstellerspezifischer Receiver
- Authentifizierung per Token in einem einzigen Header
- Während der Evaluierung parallel an Obseria und Ihr bisheriges Backend senden
- Filtern, Anreichern und PII-Maskierung beim Ingest mit Obseria Pipeline
# otel-collector.yaml: add Obseria as an OTLP exporter
exporters:
otlp/obseria:
endpoint: ${OBSERIA_OTLP_ENDPOINT}
headers:
authorization: "Bearer ${OBSERIA_TOKEN}"
processors:
batch: {}
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/obseria]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp/obseria]Jedes OpenTelemetry SDK direkt anbinden
Auch ohne Collector können die SDKs direkt exportieren. Die Standardvariablen OTEL_* funktionieren in jeder Sprache gleich, das Setup ist für Java, .NET, Node.js, Python, Go, Ruby und PHP identisch. In Kubernetes injiziert der Obseria Operator automatische Instrumentierung für Java, .NET, Node.js, Python und Go.
- Zero-Code-Instrumentierung für gängige Frameworks und Bibliotheken
- Service-Name und Umgebung einmal setzen, überall konsistent filtern
- Eigene Spans und Attribute mit der normalen OpenTelemetry-API
- Continuous Profiling mit unter 1 % Overhead verknüpft Hotspots mit Traces
# Jedes OpenTelemetry SDK liest diese Standardvariablen
export OTEL_SERVICE_NAME=checkout
export OTEL_EXPORTER_OTLP_ENDPOINT=${OBSERIA_OTLP_ENDPOINT}
export OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer%20${OBSERIA_TOKEN}"
export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production
# Beispiel: Zero-Code-Instrumentierung für einen Python-Service
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
opentelemetry-instrument python app.pyAbfragen aus Terminal, Skripten und Coding-Agenten
Die obseria CLI und die öffentliche API bieten dieselben Abfragen, Dashboards und Alerts wie die Oberfläche. Über den MCP-Server schlagen Coding-Agenten Traces, Fehler und Logs nach, während sie an Ihrem Code arbeiten, mit denselben rollenbasierten Berechtigungen wie ein Mensch.
- OQL, PromQL und SQL auf der Kommandozeile
- JSON-Ausgabe für Skripte, CI-Gates und Release-Checks
- MCP-Server für Coding-Agenten, per RBAC eingeschränkt
- API und CLI in jedem Tarif enthalten, kein Add-on
# Traces mit OQL direkt im Terminal abfragen
obseria query 'fetch spans
| filter status == "ERROR"
| summarize count(), by:{service.name}' --last 1h
# Gleiche Daten, andere Sprachen: PromQL und SQL gehen auch
obseria query --promql 'rate(http_server_requests_total[5m])'
# Ergebnisse in Skripte oder CI-Checks weiterreichen
obseria query 'fetch logs | filter service == "payments"' \
--last 15m --output json | jq '.[0]'Dashboards, Alerts und Workflows in Git
Behandeln Sie Observability wie den Rest Ihres Stacks. Dashboards, Alert-Regeln, SLOs und Automatisierungs-Workflows werden als Dateien definiert, per Pull Request geprüft und pro Umgebung über Ihre CI/CD-Pipeline ausgerollt. Abweichungen zwischen Staging und Produktion werden zum Diff statt zum Rätsel.
- Versionierte, prüfbare Definitionen statt Klickarbeit
- Dieselben Definitionen von Staging bis Produktion
- Workflows as Code für Remediation und Benachrichtigungen
- Audit-Logs zeigen, wer wann was geändert hat
Ihre erste Trace in 15 Minuten
- Schritt 1
Kostenlos testen
Workspace anlegen, Datenregion wählen und Ingest-Token erzeugen. Keine Kreditkarte erforderlich.
- Schritt 2
Exporter einstellen
OTLP-Exporter im Collector ergänzen oder die OTEL_*-Variablen im Service setzen. Bestehende Instrumentierung bleibt unverändert.
- Schritt 3
Traffic senden und erkunden
Service aufrufen, Trace-Ansicht öffnen oder eine OQL-Abfrage per CLI starten. Topologie und Service-Maps entstehen automatisch aus den Daten.
Unterstützte Sprachen und ihre Instrumentierung
| Sprache | Instrumentierung | Typische Frameworks |
|---|---|---|
| Java | OpenTelemetry Java Agent oder automatische Injektion über den Obseria Operator | Spring Boot, Quarkus, Micronaut |
| .NET | Automatische Instrumentierung von OpenTelemetry .NET oder Operator-Injektion | ASP.NET Core, gRPC, Entity Framework |
| Node.js | OpenTelemetry Auto-Instrumentations für Node.js oder Operator-Injektion | Express, Fastify, NestJS |
| Python | Wrapper opentelemetry-instrument oder Operator-Injektion | Django, Flask, FastAPI |
| Go | OpenTelemetry Go SDK mit Instrumentierungsbibliotheken oder Operator-Injektion | net/http, gRPC, database/sql |
| Ruby | OpenTelemetry Ruby SDK mit Instrumentierungs-Gems | Rails, Sinatra, Sidekiq |
| PHP | OpenTelemetry-PHP-Extension mit Auto-Instrumentierungspaketen | Laravel, Symfony, Slim |
Weiterlesen
OpenTelemetry
Wie Obseria OTLP nativ verarbeitet, ohne proprietäre Agenten.
Dokumentation
Anleitungen, API-Referenz und CLI-Befehle.
Distributed Tracing
Requests über Services, Queues und Datenbanken hinweg verfolgen.
Was ist OpenTelemetry?
Der offene Standard für Traces, Metriken und Logs, verständlich erklärt.
Häufig gestellte Fragen
Nein. Obseria nimmt OTLP von jedem OpenTelemetry SDK und Collector an. Der optionale Obseria Agent ergänzt Host-Metriken, Logs, Profile und Security-Signale, für Anwendungstelemetrie genügt aber reines OpenTelemetry.
Jede Sprache mit OpenTelemetry SDK kann Daten senden. Automatische Instrumentierung gibt es für Java, .NET, Node.js, Python und Go über den Obseria Operator in Kubernetes. Ruby und PHP werden über ihre OpenTelemetry SDKs und Instrumentierungspakete abgedeckt.
Ja. Der Obseria MCP-Server stellt Coding-Agenten Traces, Logs, Metriken und Probleme bereit. Der Zugriff folgt denselben rollenbasierten Berechtigungen wie bei Menschen, ein Agent sieht also nur, was sein Token erlaubt.
Ja. Dashboards, Alerts, SLOs und Workflows lassen sich als Dateien definieren, in Git versionieren und per CLI oder API aus Ihrer CI/CD-Pipeline ausrollen. Audit-Logs protokollieren jede Änderung.
Der 14-tägige Test umfasst alle Funktionen, auch CLI, API, MCP-Server, Pipeline und Automation, mit unbegrenzt vielen Nutzern und ohne Kreditkarte. Danach zahlen Sie pro aufgenommenem und gespeichertem Signal, ohne Host- oder Seat-Gebühren.
Ihre erste Trace ist 15 Minuten entfernt.
Starten Sie den 14-tägigen Test: alle Funktionen, unbegrenzte Nutzer, keine Kreditkarte und keine proprietären Agenten.