Loakesh Indiran
f16e8e53ff
Synthetics performance and correctness work. Four areas: caching the
config reads on the job path, a false-alarm bug in validation, four HA
correctness bugs found by auditing what happens with more than one alert
manager, and the Steps tab moving to a step-grain stream.
Pairs with o2-enterprise#2325 — **merge this first**, that one calls
functions introduced here.
---
## Caching
- [x] Probe-token auth cache — 10s TTL, negative results cached so a bad
token can't force a query per request
- [x] Locations whole-table cache — 30s, serves `get` / `find_by_pool` /
`list_visible` from one load
- [x] Check definition cache via `get_cached()` — was read twice per job
(resolve + ack)
- [x] Agent capabilities cache via `get_cached()` — was read on every
lease poll
- [x] Org ingest-token cache — `find_default_enabled()` replaces three
hand-rolled `list_by_org().find(enabled)` copies
- [x] `list_by_locations()` — one batched agents query, replacing one
per location
## Cross-node invalidation
- [x] `coordinator::synthetics` — event invalidation following the
alerts/pipelines pattern
- [x] Write paths call `invalidate_and_publish()`, the watcher calls
plain `invalidate_cache()` so events don't echo
- [x] Deletes emit a delete event, so coordinator keys don't accumulate
one per check ever created
- [x] Ingest-token invalidation reuses the existing
`/org_ingestion_tokens/` watch — no second event stream
- [x] SQLite write mutex released before emitting — `get_lock()` and the
coordinator's `put()` take the same lock, so emitting while holding it
deadlocked the process
## HA — correctness with more than one alert manager
Confirmed with @subhradeep that a region can run multiple alert
managers. The synthetics scheduler, dispatcher, reaper and staleness
watcher all run on **every** one of them.
- [x] **Duplicate runs** — `claim_due()` claims due checks with `SELECT
… FOR UPDATE SKIP LOCKED`, advancing the schedule inside the same
transaction
- [x] **Duplicate "location down" pages** — the one-shot flag moved from
an in-process `HashSet` to `synthetics_locations.down_notified_at`,
claimed with a CAS
- [x] **Duplicate run completion** — `increment_jobs_done` claims
completion via `completed_at IS NULL`; two acks of the same run could
both be told they completed it
- [x] **Inert dedup index** — `scheduled_ts` is now the schedule slot,
not each node's tick clock, so the existing `synthetics_jobs_dedup_uq` +
`ON CONFLICT DO NOTHING` actually fires
- [x] Migration `m20260803_000001` adds `down_notified_at`, defaulted so
no backfill is needed
- [x] `DB_SCHEMA_VERSION` 62 → 63 — without it the migration never runs
on an already-upgraded deployment
## The false-alarm fix
- [x] Validate against the run budget (840s), not the job lease (900s)
- [x] The three bounds are deployment-configurable:
`O2_SYNTHETICS_MAX_CHECK_BUDGET_SECS` / `_JOB_LEASE_SECS` /
`_MAX_NET_TIMEOUT_MS`
- [x] Rejected limits are logged, not fatal — nothing installed means
validation keeps the conservative defaults
- [x] Browser retries capped at 2; protocol types stay at 3; default
stays 0 for every type
## Steps tab — the step-grain stream (B10)
- [x] Three `GROUP BY`s over the step stream replace downloading 5000
execution rows and tallying their JSON in the browser
- [x] Falls back to the old tally when the stream is empty, so the tab
does not blank for checks whose agents have not been upgraded
- [x] Gated on the `step_id` column rather than stream existence — a
partially-created stream would otherwise cause four failed queries
## Overview KPIs
- [x] Count tiles summed from the cached histogram; `buildKpiSql`
deleted
## Rename
- [x] `synthetics_monitors` → `synthetics_checks`, `monitor_type` →
`check_type`
- [x] Three UI call sites that read the old field names, including a
delete guard that silently disabled itself
---
**Why validation moved off the lease.** Three bounds stack:
```
check worst case <= max_check_budget_secs < job_lease_secs
840s 840s 900s
```
Validation used the lease, so the server accepted checks the execution
environment cannot finish. On the managed path the probe is a Lambda,
and a function that hits its timeout is killed mid-run — lease headroom
is irrelevant once the process is gone. The net probe's function timeout
had drifted to **60s** while validation accepted up to 900s, so a plain
`timeout_ms=30s, retries=2` (worst case 100s) was accepted and then
killed, reporting a failure the target never had.
**Why the limits are ENT-declared but OSS-consumed.** Synthetics is
enterprise-only, so the values live in `SyntheticsConfig`. The
validation they bound lives in `config`, which cannot depend on
`o2_enterprise`. `SyntheticsLimits` + `init_limits` is the seam, falling
back to built-in defaults in OSS builds and tests. A bad limit is logged
rather than fatal: refusing to start ingest, search and dashboards
because a probe ceiling is misconfigured would be the worse outage.
**The duplicate-run bug.** `fetch_due` was a plain `SELECT` and the
advance was an unconditional `UPDATE … WHERE id = ?`, so nothing stopped
two alert managers firing the same check. Each inserted its own
`synthetics_runs` row under a fresh KSUID, which made the resulting job
rows genuinely distinct — `lease_batch`'s `status = 0` guard cannot
collapse them, because they are not contending for one row. N alert
managers meant every check ran N times.
`SKIP LOCKED` rather than a compare-and-swap because it *distributes*: a
second scheduler skips the rows the first holds and picks up different
due checks, so N replicas split the backlog. A CAS gives the same
exactly-once guarantee but every node reads the same candidates, one
wins them all, and the losers each issue a doomed `UPDATE`. The lock and
the advance share a transaction because the locks only live until
`COMMIT`; the fan-out stays outside it so config rows are not locked
across N job inserts.
**Duplicate run completion needed no second alert manager.** The
increment was atomic, but the completion decision re-read the row in a
second statement and returned "complete" to whichever caller saw
`jobs_done >= job_count` — which both acks of a 2-job run do. Acks are
served on ingesters, of which every environment runs two, and the probes
of one run finish independently. Effect: `consecutive_failures` counted
one run twice on every check, plus a genuinely duplicated notification
on checks left at the default `cooldown_mins = 0`.
**The Steps tab was truncating silently.** It downloaded up to 5000
execution rows and tallied `last_attempt_steps` in the browser. On the
busiest check measured — 18,079 executions over 7 days — that cap
covered 4 of the 7 days and reported a **56.3% fail rate against a true
33.7%**. The win is correctness; the ~18MB payload reduction is
secondary.
## Verification
`cargo check --workspace`, clippy, fmt clean. Config 98, infra 33
synthetics tests pass. Frontend: **839 synthetics tests pass**. Three
frontend spec files fail to import on `useLocalTimezone` — verified
identical on clean `main`, unrelated to this branch.
Open source Datadog alternative for logs, metrics, traces, and frontend monitoring. Modern observability platform: 10x easier, 140x lower storage cost, high performance, petabyte scale.
Cloud · Documentation · Slack · Quickstart
OpenObserve (O2) is a cloud-native observability platform for logs, metrics, traces, analytics, Real User Monitoring (RUM), and AI/LLM observability. It's a cost-effective alternative to Datadog, Splunk, and Elasticsearch for teams that need full observability without the complexity or cost — with Parquet columnar storage and an S3-native design that cuts storage costs by up to 140x.
Table of Contents
- Why OpenObserve?
- Quick Start
- Product Tour
- Architecture
- Comparisons
- Production Ready
- Security & Compliance
- Enterprise Edition
- Community & Support
- Contributing
- FAQ
- License
- SBOM
Why OpenObserve?
A single platform for all of your observability signals. Here's why teams choose OpenObserve:
| Benefit | Description |
|---|---|
| 140x lower storage cost | Parquet columnar storage + S3-native architecture dramatically reduce costs vs Elasticsearch |
| Single binary deployment | Up and running in under 2 minutes — no complex cluster setup required |
| OpenTelemetry native | Built on the OpenTelemetry standard — no vendor lock-in |
| Unified platform | Logs, metrics, traces, RUM, dashboards, alerts, and incidents in one tool |
| High performance | Better query performance than Elasticsearch on a quarter of the hardware |
| SQL + PromQL | Query logs and traces with SQL, metrics with SQL or PromQL — no proprietary query language |
| Built in Rust | Memory-safe, high-performance, single binary |
Cost comparison: OpenObserve vs Elasticsearch
Quick Start
OpenObserve Cloud (fastest way)
Get started in minutes without managing infrastructure. The free tier includes up to 50 GB/day of ingestion.
🐳 Docker
docker run -d \
--name openobserve \
-v $PWD/data:/data \
-p 5080:5080 \
-e ZO_ROOT_USER_EMAIL="root@example.com" \
-e ZO_ROOT_USER_PASSWORD="Complexpass#123" \
public.ecr.aws/zinclabs/openobserve:latest
Then open http://localhost:5080 and log in with the credentials above.
For other installation methods, see the quickstart documentation. For clustered deployments, see the High Availability deployment guide.
Product Tour
OpenObserve ships with a powerful, unified web UI for every signal — logs, traces, metrics, dashboards, RUM, alerts, incidents, pipelines, and AI observability.
🏠 Unified Overview
A single home for your workspace — active incidents, service health (error rate, latency, requests), anomalies, and recent events at a glance.
📊 Logs
Centralized log management with full-text search, SQL queries, quick filters, and a visual query builder. Instantly search across all your logs, build dashboards from log data, and set up alerts — all on Parquet columnar storage for 140x lower storage cost than Elasticsearch. Read more →
🔍 Distributed Tracing
Powered by OpenTelemetry, tracing helps you follow requests across services and pinpoint performance bottlenecks. Explore the full request flow with waterfalls, flame graphs, and Gantt charts; click any span to drill into the trace. Read more →
🕸️ Service Graph
Visualize service-to-service dependencies and request flow across your system, with per-edge request counts and health-based coloring (healthy, degraded, warning, critical) to spot problem hotspots at a glance.
📈 Metrics
Explore metrics from your infrastructure and applications, then query them with SQL or PromQL. Browse thousands of metrics with faceted filters, preview them inline, combine multiple queries with formulae, and visualize the results with 19+ chart types. Read more →
📉 Dashboards
Build custom dashboards from any signal with 19+ built-in chart types and 200+ visualization variations, a drag-and-drop panel builder, template variables, and geo maps. Read more →
👀 Frontend Monitoring (RUM)
Real User Monitoring with Core Web Vitals, error tracking, performance analytics, and full session replay — so you can see exactly what your users experience. Read more →
🔔 Alerts
Get notified when something unusual happens on any signal — logs, metrics, or traces. Define thresholds, scheduled or real-time alerts, and notification channels, with alert history and anomaly detection to catch issues early. Read more →
🚨 Incidents
Correlate related alerts into incidents and track them through their lifecycle — open, acknowledged, and resolved — with severity and dimension context for faster response.
🔀 Pipelines
Enrich, redact, reduce, or normalize data at ingest time with a visual editor. Build stream-processing flows — including logs-to-metrics conversion — from source, transform (VRL functions and conditions), and destination nodes. No external tools required. Read more →
🤖 AI Observability
Monitor your GenAI and LLM applications: track cost, tokens, latency percentiles, and error rates across models, with agent graphs, session traces, and evaluation/quality scoring.
✨ O2 AI Assistant
An in-product assistant that writes your SQL, VRL, and PromQL and walks you through logs, traces, metrics, and incidents — turning natural-language questions into queries, dashboards, and alerts.
For the full feature list, see the documentation.
Architecture
OpenObserve achieves 140x lower storage costs and high performance through a modern, cloud-native architecture:
- Parquet columnar storage — efficient compression and fast analytical queries
- S3-native design — inexpensive object storage with intelligent caching
- Built in Rust — memory-safe, high-performance, single binary
- Partitioning, indexing, and smart caching — reduces search space by up to 99% for most queries
- Native multi-tenancy — organizations and streams as first-class concepts with complete data isolation
- Stateless architecture — rapid scaling and low RPO/RTO for disaster recovery
Scale & Deployment
- Thousands of concurrent users can query a single cluster simultaneously
- Single binary scales to terabytes — unique in the observability space
- High Availability mode scales to petabytes for the most demanding workloads
- Multi-region deployments with cluster federation via Super Cluster architecture (Enterprise)
- Federated search across regions and clusters (Enterprise)
High Availability & Disaster Recovery
Deploy in High Availability mode with clustering for mission-critical workloads requiring maximum uptime. OpenObserve's stateless architecture with S3-backed storage enables very low Recovery Point Objective (RPO) and Recovery Time Objective (RTO): stateless nodes restart rapidly, and durability is guaranteed by S3's 99.999999999% (11 nines).
Read the architecture documentation → · Read the enterprise deployment guide →
Comparisons
OpenObserve vs Datadog
| Aspect | OpenObserve | Datadog |
|---|---|---|
| Deployment | Self-hosted or Cloud | SaaS only |
| Pricing model | Per-GB (free up to 200 GB/day) | Per-host + per-GB |
| Open source | Yes (AGPL-3.0) | No |
| OpenTelemetry | Native OTLP | Supported |
| Query language | SQL + PromQL | Proprietary |
| Vendor lock-in | None | High |
OpenObserve vs Elasticsearch
| Aspect | OpenObserve | Elasticsearch |
|---|---|---|
| Storage cost | 140x lower | High (hot/warm/cold tiers) |
| Setup complexity | Single binary | Complex cluster management |
| Query language | SQL | Lucene/KQL |
| Hardware requirements | ~1/4 the resources | High memory/CPU |
OpenObserve vs Splunk
| Aspect | OpenObserve | Splunk |
|---|---|---|
| Licensing | Open source | Expensive enterprise licensing |
| Deployment | Single binary or HA cluster | Complex |
| Query language | SQL + PromQL | SPL (proprietary) |
| Cost | Predictable, low | Unpredictable, high |
OpenObserve vs Grafana/Loki/Prometheus Stack
| Aspect | OpenObserve | Grafana Stack |
|---|---|---|
| Components | Single platform | Multiple tools (Grafana + Loki + Prometheus + Tempo) |
| Management | One binary | Multiple deployments |
| High cardinality | Full support | Loki struggles with high cardinality |
| Query performance | Fast on large volumes | Loki slow on large data |
Production Ready
OpenObserve is battle-tested in production environments worldwide:
- Thousands of active deployments across diverse industries
- Largest deployment: 2+ PB/day ingestion
- Single binary scales to terabytes — unique in the observability space
Security & Compliance
Security Features
- Secure by design with hardened container images
- Data encryption at rest and in transit
- Sensitive Data Redaction (SDR) — automatically redact sensitive data at ingestion and query time (Enterprise)
- Single Sign-On (SSO) — OIDC, OAuth, SAML, LDAP/AD integration (Enterprise)
- Role-Based Access Control (RBAC) — granular permissions (Enterprise) — Learn more →
Compliance Certifications
- ✅ SOC 2 Type II certified
- ✅ ISO 27001 certified
- ✅ GDPR compliant
- ✅ HIPAA ready (BAA available with Enterprise contracts)
OpenObserve meets the stringent security and compliance requirements of regulated industries including finance, healthcare, and government.
Enterprise Edition
OpenObserve is a true open source project. The open source edition is feature-complete and production-ready — logs, metrics, traces, dashboards, alerts, pipelines, and everything you need to run observability at scale. It will always remain actively maintained and free to use without restrictions.
For organizations that need enterprise-grade features and support, an Enterprise edition adds:
Enterprise features
- Single Sign-On (SSO) — OIDC, OAuth, SAML 2.0, LDAP/AD, and major identity providers (Okta, Azure Entra, Google, GitHub, GitLab, Keycloak)
- Advanced RBAC — granular role-based access control with custom roles — Learn more →
- Audit trails — comprehensive immutable audit logs with configurable retention
- Federated search — query across multiple clusters and regions with Super Cluster
- Sensitive Data Redaction (SDR) — automatically redact PII at ingestion and query time
- Advanced encryption — AES-256 SIV cipher keys with Google Tink KeySet and Akeyless integration
- Query & workload management (QoS) — control query resource usage and priorities in multi-tenant environments
Support & SLAs
- Dedicated support with contractual SLA guarantees and priority response times
- Technical account management, architecture review, and deployment assistance
- Migration support from existing tools, plus training and onboarding
Pricing
- Free tier: up to 50 GB/day of ingestion (~1.5 TB/month), including full commercial use (registration required at 50 GB/day)
- Volume discounts and multi-year contracts available
- View the complete feature comparison →
For enterprise inquiries and custom deployments, contact our sales team.
Community & Support
The best way to get help, share ideas, and connect with other OpenObserve users is through our community channels.
🔗 Join us on Slack
Our Slack community is the most active place for installation and configuration help, sharing best practices, discussing the roadmap, and connecting with the core team.
📱 Join the OpenObserve community on WeChat
Other ways to connect
- 💬 GitHub Discussions — longer-form discussions and Q&A
- 🐛 GitHub Issues — report bugs or request features
- 📖 Documentation — guides, tutorials, and API references
Contributing
We welcome contributions from the community! Whether you're fixing bugs, adding features, improving documentation, or sharing feedback, your help makes OpenObserve better for everyone.
To get started, read our Contributing Guide, which covers setting up your development environment, code standards, submitting pull requests, and reporting issues.
FAQ
How does OpenObserve achieve 140x lower storage costs?
Through a combination of Parquet columnar storage (efficient compression) and an S3-native architecture (inexpensive object storage). See the cost comparison chart in the Why OpenObserve? section.
What are the limitations?
All data in OpenObserve is immutable — once ingested, it cannot be modified or deleted (only entire retention periods can be dropped). This is by design and is a feature for logs and compliance use cases, ensuring data integrity and audit trails.
Is this production-ready?
Yes. OpenObserve runs in production across thousands of deployments worldwide, including environments processing in excess of 2 PB/day. See our customer stories for real-world examples.
How does query performance compare to Elasticsearch?
OpenObserve delivers better performance than Elasticsearch for most workloads, with faster search and significantly faster analytics — while using about a quarter of the hardware. The columnar Parquet format is particularly effective for complex aggregations and analytics.
Is there a steep learning curve?
No. OpenObserve is designed to be intuitive from day one:
- Familiar query languages — SQL for logs and traces, PromQL for metrics; no proprietary query language to learn
- Easy-to-use GUI — an intuitive interface with a drag-and-drop dashboard builder
- No complex tuning — unlike Elasticsearch, there are no shards, replicas, or heap sizes to manage. Just install and go.
Most users are productive within hours, not weeks.
License
Open Source Edition — licensed under AGPL-3.0. We chose AGPL to ensure that improvements to OpenObserve remain open source and benefit the entire community, while still allowing free commercial use. Why AGPL, and why it's good for the community →
Enterprise Edition — licensed under a commercial Enterprise License Agreement (not AGPL), which provides additional flexibility for enterprise deployments.
SBOM
Software Bill of Materials for OpenObserve. You can analyze either SBOM with Dependency-Track.
Rust
The SBOM is available here. To regenerate it:
cargo install cargo-cyclonedx
cargo-cyclonedx cyclonedx
JavaScript
The SBOM is available here. To regenerate it:
npm install --global @cyclonedx/cyclonedx-npm
cd web
cyclonedx-npm > sbom.json