Services & traces

Ultraviolet shows you every service running in your environment, how they call each other, and the health of each request path — automatically, with no code changes. You’ll find these under APM in the menu.

Services

The Services page is your starting point: a table of every service with its request rate, error count, and latency (p50 / p95 / p99), plus rate and latency charts across the top. Narrow it to a time window or a single site, then click any service to drill in.

Service detail gives you that one service up close. The Overview tab has headline tiles for throughput, error rate, and latency percentiles; rate and p95 trends over time; a latency distribution; and a breakdown of response codes. Depending on what the service does, it also has protocol tabs (HTTP, DNS, Postgres, Redis, MySQL, Kafka, gRPC — each appears only when that traffic exists), a Dependencies tab, and a Saturation tab:

Dependencies — a single-hop map of who calls this service and what it calls, named by service: requests, errors and p95 latency on each edge, or connections, bytes and round-trip time for traffic that isn’t parsed (Redis, encrypted connections). Below it, a table of its outbound calls marked internal or external, with rate, errors, and latency.
Saturation — the service’s CPU and memory (and replica/restart counts when available) over time, so you can tell a slow service from a starved one.

Deploys — see what each release did

Service detail tracks your deploys automatically. A Running version card shows the current image, its revision, and how long it’s been running, with a badge for the last deploy and which images changed — no deploy hooks to wire up.

On the Overview tab, deploy markers are overlaid on the rate and latency charts so you can line a change in behaviour up with the release that caused it, and a Since last deploy table compares rate, error rate, and latency percentiles before vs. after your most recent deploy — the fastest way to answer “did that release make things worse?”

Traces

The Traces page breaks request activity down by protocol, with a tab for each one Ultraviolet understands: HTTP, DNS, Postgres, Redis, MySQL, Kafka, and gRPC. Each tab is its own shareable link.

HTTP — your routes ranked by traffic, errors, and latency, plus a stream of recent requests. Open a request to see its full trace waterfall — every span laid out on one timeline — drill into the connection behind it, or jump straight to the logs for that exact trace.
DNS — the names being looked up, their rates, failed lookups (SERVFAIL, REFUSED, …), and recent lookups. Names that don’t exist (NXDOMAIN) are shown separately as Not found and don’t count as errors anywhere: in Kubernetes most of them are the resolver trying each search domain (api.example.com.svc.cluster.local, …) before the real name resolves.
Postgres and MySQL — queries grouped by operation and table, with recent statements and their outcomes. The values in each statement are replaced with ? before they’re stored (WHERE email = ?), so trace data never holds the email addresses, tokens or passwords your queries carry; an IN list of any length shows as IN (?). Administrators can turn this off with sensor.scrubSqlLiterals: false.
Redis, Kafka, and gRPC — the same golden-signal treatment (rate, errors, latency) for cache, streaming, and RPC traffic.

All of it comes from watching the network — there’s nothing to instrument for any protocol. A shared time-window and site selector persists as you move between tabs.

Dependencies

Dependencies, under APM, lists the services and third parties your workloads call out to — from HTTP requests and DNS lookups — with request rate, error rate and latency percentiles. Turn on External only to hide internal traffic; it’s the quickest way to see which third party is slow or failing. For what that traffic costs, see Cost.

Your code and the network, on one timeline

Ultraviolet builds a single trace from two vantage points. Your instrumented services report spans from inside the code; the sensor observes the very same requests as they cross the network. When a request carries standard trace context — the traceparent header your OpenTelemetry setup already propagates — Ultraviolet stitches the network-observed hop into the same trace as your application spans.

The result is one waterfall where application spans and the underlying network calls line up together, so for a single request you can see both what your code did and what actually went over the wire. Network-observed spans are shown distinctly, with a link icon where they’ve been stitched into an application trace.

Requests that don’t carry trace context still appear as standalone network traces — you lose nothing, you just don’t get the in-code spans beside them. No extra configuration is needed on Ultraviolet’s side: turn on the sensor, keep propagating trace context from your services, and the traces come together on their own.

Each request is counted once. When a service sends its own traces, its HTTP and gRPC requests are seen twice — by your instrumentation and by the sensor. Ultraviolet notices which processes send traces and, for their HTTP and gRPC calls, counts your application’s spans and shows the sensor’s beside them in the trace without counting them again. Calls your instrumentation doesn’t cover — database, cache, DNS and messaging calls, or any service without instrumentation — are still counted from the sensor. For your spans and the sensor’s to land on the same service, set your OpenTelemetry service name (OTEL_SERVICE_NAME) to the workload’s name.

Your spans appear in the same protocol views as the sensor’s — HTTP, gRPC, Postgres, MySQL, Redis, MongoDB and Kafka — recognized from the standard OpenTelemetry attributes, older and current naming alike, and gRPC methods are named the same way from either source (/package.Service/Method), so a filter or alert on a route matches both.

Traces and logs, connected

Every request and log line is correlated. From a slow or failing request you can jump straight to the logs it produced, and from a log line back to its trace — so you follow one problem end to end instead of guessing across tools.