Full-stack observability that never leaves your firewall
Ultraviolet Observability runs entirely inside your environment. eBPF sensors capture traces, logs and service topology from the kernel — and every byte of that telemetry stays on your infrastructure. No vendor egress. No per-GB surprise. Works air-gapped.
Every other vendor asks you to ship production out the door.
Datadog and Groundcover are good products with the same structural problem: your telemetry — request payload shapes, internal hostnames, customer identifiers leaking through log lines — has to leave your perimeter to be useful. For regulated, defense, and on-prem workloads, that is where the evaluation ends.
01
Your data stays yours
Spans, logs and traces are written to ClickHouse inside your network and queried from inside your network. There is no vendor pipeline to trust, no DPA to negotiate over telemetry contents, and no third-party breach that can expose your production internals.
No telemetry egress
Customer-owned storage
02
Works with no internet at all
The core is offline-first, not offline-tolerant. Every feature — ingest, query, dashboards, alerting — functions on a cluster that has never resolved a public DNS name. Air-gapped installs run on a hand-carried signed license.
Air-gap licensed
Zero call-home dependency
03
Retention you actually control
Storage is ClickHouse on your disks with your TTL policy. Keeping 90 days of full-fidelity spans is a hardware decision, not a line item — so nobody has to argue about sampling rates to hit a budget.
No per-GB ingest bill
No forced sampling
The only thing that ever crosses your firewall is a license heartbeat — node counts and an expiry date. Never a span, never a log line.
The platform
Kernel-level visibility, assembled into the four pillars.
Traces, logs, topology and alerts — collected without touching application code, stored in ClickHouse you operate, queried through one API.
eBPF sensors, not SDKs
A CO-RE eBPF agent attaches to kernel tracepoints and kprobes on every node. It sees TCP connection lifecycles, RTT and byte volumes at L4, then decodes the payload prefix at L7 — with no libraries added to your services, no sidecars, and no redeploy to start collecting.
Language-agnostic — Go, Java, Rust, a legacy binary nobody can rebuild
CO-RE + BTF: one binary, no kernel headers, no compilation on your nodes
Kubernetes-aware — pod, workload, namespace and node resolved on the sensor
L7 protocol decoding
HTTP/1.1, DNS and Postgres are parsed off the wire and paired into request/response transactions with real latency, status codes and SQLSTATE errors.
Per-route RED
DNS rcode breakdown
SQL op + table attribution
Service map from the kernel
Topology derived from actual sockets, not from a config file someone forgot to update. Edges carry call volume, RTT and byte flow.
Live L4 topology
Client → peer edges
Cross-site rollups
Logs, correlated to traces
OTLP log ingest with severity facets, live tail and full-text search — pivoting both directions between a log line and the trace that produced it.
Trace ID correlation
Severity floor filters
Live tail
Alerting that stays local
Rules are stored and evaluated inside the core on the same signals the dashboards use, so an alert never disagrees with the page you opened to debug it.
Error rate · p95 · throughput
Durable firing history
No external evaluator
One core, many sites
Remote clusters run sensors that dial home over outbound mTLS. No inbound ports at the edge, and site_id is a first-class dimension in every query.
Outbound-only, port 443
Buffered across WAN blips
Per-site + fleet views
OpenTelemetry-native
The ingest gateway speaks OTLP over gRPC. Anything you have already instrumented — an SDK, a Collector — points at it and lands in the same store as the kernel data.
No proprietary agent protocol
Spans and logs, one pipeline
Nothing to rip out
Shipping next
Metrics pipeline
Kubernetes infrastructure
MySQL · Redis · gRPC · Kafka
eBPF log capture
Slack + PagerDuty notifiers
Architecture
The whole stack runs on your side of the boundary.
One core per customer — no multi-tenancy, no shared storage, no shared query layer. Remote sites dial in; we run nothing but a license desk.
Air-gapped? Skip this entirely — carry in an annual license file and reconcile usage with a signed export.
Compare
Same eBPF depth. A different trust boundary.
Groundcover proved that eBPF beats manual instrumentation, and that keeping data in your own cloud beats shipping it to a vendor. We take the last step: the platform itself runs inside your environment, so nothing about it depends on us being reachable.
Deployment model comparison between Ultraviolet Observability, Groundcover and Datadog
Ultraviolet
Groundcover
Datadog
Where telemetry is stored
Your cluster, your disks
Your cloud account, vendor-operated
Vendor cloud
Vendor-managed control plane required
No — the core is yours
Yes — SaaS control plane
Yes — fully SaaS
Runs fully air-gapped
Yes, licensed option
No
No
Collection method
eBPF — no code changes
eBPF — no code changes
Agent + APM libraries per language
Retention policy owner
You — ClickHouse TTL you set
You, within vendor tooling
Vendor plan tiers
Billing unit
Node-minutes, committed + overage
Nodes
Hosts + ingested GB + indexed spans
Cost of keeping more data
Disk
Your cloud storage
Metered per GB and per span
What crosses your firewall
License heartbeat only
Control-plane metadata + queries
All telemetry
Scroll the table sideways to see every column →
Comparison reflects each vendor's publicly documented deployment model. Product capabilities move quickly — we're happy to walk through a current, specific side-by-side on a call.
Pricing
Priced on what ran, not on what you collected.
We sample your active node set every 30 seconds and sum it into node-minutes. Ingest volume, span count, retention window and cardinality are all free — they cost disk you already own, not a metered line item.
Evaluation
Free30 days
A full-function core in your own cluster. Not a hosted sandbox — the real thing, on your nodes.
A node counts while a sensor on it is alive — an installed-but-idle node still meters, a node that scaled down at 14:03 stops metering at 14:03. Usage rolls up in an append-only ledger inside your core, visible to you on the license page before it is ever visible to us.
active nodes
142
committed
200
node-min MTD
1.9M
meter & warn — capacity never blocks ingest
Questions
The things engineers actually ask.
If yours is not here, we would rather answer it directly than write around it.
If the core runs on our hardware, who operates it?
You do — it installs as a Helm umbrella chart (ClickHouse via the Altinity operator, plus our Go services and the portal) and runs like any other workload in your cluster. We size it with you, ship signed images and charts, and support upgrades. There is no hidden dependency that phones us for the core to function.
What does the eBPF sensor cost us in overhead?
The sensor attaches to kernel tracepoints and kprobes and reads a bounded payload prefix — it never copies whole request bodies. Filtering happens in-kernel before anything reaches userspace, so a busy node typically stays under one percent of a core. It ships CO-RE + BTF, so there is no kernel-header build step and no compiler on your nodes.
Do we have to instrument our applications?
No. L4 connections, HTTP, DNS and Postgres are decoded from the wire with no code changes. If your services already emit OpenTelemetry, point them at the ingest gateway and those spans and logs land in the same store, correlated by trace ID.
What actually happens if our license expires?
It degrades, it does not crash. Past expiry you enter a grace window with full function and a renewal banner — on a connected core the auto-renewal normally closes it before anyone notices. Past the hard stop, ingest keeps running (it is your data on your disks; we will not blind you) and the UI locks to the license page until a fresh license is dropped in.
How does billing work if we are air-gapped and you cannot see our usage?
Your core keeps an append-only usage ledger locally. At renewal you export it as a signed report and we reconcile. Capacity is soft — going over your committed nodes produces a warning in the product and a line on the true-up, never a block on ingest.
Can one core serve multiple sites or clusters?
Yes. Remote sites run sensors that dial the core over outbound mTLS on 443 — no inbound ports at the edge — and buffer to disk so a WAN outage delays data rather than losing it. Every span carries a site_id, so you can scope any view to one site or roll up the fleet.
What is the multi-tenancy story?
There is none, deliberately. One core belongs to one customer, and RBAC inside the core is the isolation boundary. That removes an entire class of cross-tenant risk that a shared platform has to engineer around.
How do we get our data out?
It is already out — it is in a ClickHouse cluster you own. Query it with any ClickHouse client, back it up with your existing tooling, and keep it if you ever stop paying us. There is no export request and no proprietary format holding it.
Get started
Run it in your own cluster this week.
A 30-minute call, then an evaluation core on your infrastructure. You will see your own service map — built from your own kernels — before you decide anything.
No data leaves your environment, including during the trial