Observability for developers, built on open standards
Keep your OpenTelemetry SDKs, change one exporter and query traces, logs and metrics from the terminal, your IDE or your coding agent. First trace in 15 minutes.
Tools that fit the way you already work
No proprietary agents to learn, no new workflow to adopt: Obseria meets you in the terminal, the editor and the pull request.OpenTelemetry native
Every OTel SDK and Collector works from day one. Semantic conventions are first-class, not mapped into a proprietary model.
One query language
OQL uses a readable pipe syntax across logs, metrics, traces and events. PromQL and SQL work on the same data.
CLI, API and MCP server
Query, automate and script everything you can do in the UI. The MCP server gives coding agents the same data with your permissions.
Configuration as code
Dashboards, alerts, SLOs and workflows live in Git, are reviewed in pull requests and are rolled out by your pipeline.
IDE integrations
See production traces, errors and profiles next to the code in VS Code and JetBrains, without switching context.
No lock-in
Your telemetry stays in open formats. Export via OTLP at any time and keep your instrumentation if you ever move on.
Already on OpenTelemetry? Change the exporter
If your services already send data to an OpenTelemetry Collector, add Obseria as an OTLP exporter and reload. Traces, logs and metrics keep their resource attributes and semantic conventions, so service names, environments and versions show up exactly as you defined them.
- Standard OTLP over gRPC or HTTP, no vendor-specific receiver
- Token-based authentication via a single header
- Fan out to Obseria and your current backend in parallel while you evaluate
- Filtering, enrichment and PII masking can run in Obseria Pipeline at ingest
# 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]Point any OpenTelemetry SDK at Obseria
Without a Collector, the SDKs can export directly. The standard OTEL_* environment variables work the same in every language, so the setup is identical for Java, .NET, Node.js, Python, Go, Ruby and PHP. In Kubernetes, the Obseria Operator can inject automatic instrumentation for Java, .NET, Node.js, Python and Go.
- Zero-code instrumentation for common frameworks and libraries
- Set service name and environment once, get consistent filters everywhere
- Add custom spans and attributes with the plain OpenTelemetry API
- Continuous profiling with under 1% overhead links hot code paths to traces
# Any OpenTelemetry SDK reads these standard variables
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
# Example: zero-code instrumentation for a Python service
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
opentelemetry-instrument python app.pyQuery from the terminal, scripts and coding agents
The obseria CLI and the public API expose the same queries, dashboards and alerts as the UI. The MCP server lets coding agents look up traces, errors and logs while they work on your code, with the same role-based permissions as a human user.
- OQL, PromQL and SQL from the command line
- JSON output for scripts, CI gates and release checks
- MCP server for coding agents, scoped by RBAC
- API and CLI included in every plan, no add-on
# Query traces from the terminal with OQL
obseria query 'fetch spans
| filter status == "ERROR"
| summarize count(), by:{service.name}' --last 1h
# Same data, other languages: PromQL and SQL work too
obseria query --promql 'rate(http_server_requests_total[5m])'
# Pipe results into scripts or CI checks
obseria query 'fetch logs | filter service == "payments"' \
--last 15m --output json | jq '.[0]'Dashboards, alerts and workflows in Git
Treat observability like the rest of your stack. Define dashboards, alert rules, SLOs and automation workflows as files, review changes in pull requests and roll them out per environment through your CI/CD pipeline. Drift between staging and production becomes a diff, not a mystery.
- Versioned, reviewable definitions instead of click-ops
- Same definitions promoted from staging to production
- Workflows as code for remediation and notifications
- Audit logs show who changed what and when
Your first trace in 15 minutes
- Step 1
Start a free trial
Create a workspace, pick your data region and generate an ingest token. No credit card required.
- Step 2
Point your exporter
Add the OTLP exporter to your Collector or set the OTEL_* variables in your service. Existing instrumentation stays as it is.
- Step 3
Send traffic and explore
Call your service, open the trace view or run an OQL query from the CLI. Topology and service maps build themselves from the data.
Supported languages and how to instrument them
| Language | Instrumentation | Typical frameworks |
|---|---|---|
| Java | OpenTelemetry Java agent, or automatic injection via the Obseria Operator | Spring Boot, Quarkus, Micronaut |
| .NET | OpenTelemetry .NET automatic instrumentation, or Operator injection | ASP.NET Core, gRPC, Entity Framework |
| Node.js | OpenTelemetry auto-instrumentations for Node.js, or Operator injection | Express, Fastify, NestJS |
| Python | opentelemetry-instrument wrapper, or Operator injection | Django, Flask, FastAPI |
| Go | OpenTelemetry Go SDK with instrumentation libraries, or Operator injection | net/http, gRPC, database/sql |
| Ruby | OpenTelemetry Ruby SDK with instrumentation gems | Rails, Sinatra, Sidekiq |
| PHP | OpenTelemetry PHP extension with auto-instrumentation packages | Laravel, Symfony, Slim |
Frequently asked questions
No. Obseria accepts OTLP from any OpenTelemetry SDK or Collector. The optional Obseria Agent adds host-level metrics, logs, profiles and security signals, but application telemetry works with plain OpenTelemetry.
Every language with an OpenTelemetry SDK can send data. Automatic instrumentation is available for Java, .NET, Node.js, Python and Go via the Obseria Operator in Kubernetes, and Ruby and PHP are covered by their OpenTelemetry SDKs and instrumentation packages.
Yes. The Obseria MCP server exposes traces, logs, metrics and problems to coding agents. Access follows the same role-based permissions as a human user, so an agent only sees what its token allows.
Yes. Dashboards, alerts, SLOs and workflows can be defined as files, stored in Git and rolled out via the CLI or API from your CI/CD pipeline. Audit logs record every change.
The 14-day trial includes every feature, including the CLI, API, MCP server, Pipeline and automation, with unlimited users and no credit card. Afterwards you pay per signal ingested and stored, with no host or seat fees.
Your first trace is 15 minutes away.
Start the 14-day free trial: every feature, unlimited users, no credit card and no proprietary agents.