Get the signal in, with enough context to be joined up later
Everything downstream depends on what arrives. ZipLogger enriches each record with the release, commit SHA, environment and trace id, which is what makes the later steps possible at all.
All your services, one query
What it does. Full-text and field search across every service in the workspace, with a histogram you click to zoom into a spike, a field explorer over everything you have sent, and saved views the whole workspace can open. Live tail shows new lines as they arrive, any line opens onto the lines logged just before and after it, and the matches download as CSV or NDJSON.
Why it matters. Structure is what turns a log line into evidence. Anything you pass as a
field is queryable as fields.orderId:83112, and the SDKs attach the release, the
commit SHA and the environment without you writing that code.
How it connects. A log carries its trace id and span id, so any line is one click from the request it belongs to, and its stack trace is what step 5 blames.
Read ten templates instead of ten thousand lines
What it does. Near-identical log lines are clustered into templates, with the variable parts shown as the diff between them. Each template has a stable hash, a severity mix, first and last seen, and example events.
The problem it solves. An error storm is thousands of rows that all say the same thing. Scrolling them tells you nothing about how many distinct failures you actually have.
How it connects. A pattern is the unit everything else attaches to: attribution runs on a pattern, not a line, and the same pattern is what correlates back to affected users.
# 4 templates cover 214 events
142,801 Order <*> processed in <*>ms
98,112 Cache miss for key <*>
214 NullReference in
PaymentProcessor.Charge()
7 Timeout calling <*> after <*>msFollow one request across every service it touched
What it does. A native OpenTelemetry receiver over HTTP takes your spans and renders them as a waterfall, with a field explorer over every span attribute and keep-only or exclude filters on any value.
Why it matters here. The browser SDK adds a W3C traceparent header to
same-origin fetches, so a click in the page and the server call it triggered share one trace
id. That single fact is what lets a user-visible failure reach a backend stack trace.
How it connects. Logs carry the trace id, so a trace links to its logs and a log links to its trace. Error traces are kept for your full plan retention.
See which endpoint got slower, and what it was waiting on
The problem it solves. A trace shows one slow request. It does not tell you whether the endpoint is slow for everyone, since when, or whether the time went to your code, the database or another service.
What it does. APM turns your OpenTelemetry traces into latency (P50, P95, P99), error rate and traffic for every service and endpoint. It lists each dependency a service calls, draws a service map from the calls it actually observed, and splits an endpoint’s time between the calls that were in flight. It compares two releases or two time windows, and it opens a regression when an endpoint’s P95 rises well above its own baseline and stays there. Service-level objectives track availability or latency targets over 7, 28 or 30 days, with the error budget left and burn-rate alerts that page only while the budget is still burning.
Honest about its numbers. Every figure says where it came from. With ZipLogger request metrics you get complete request counts; with traces alone, counts are labeled as observed spans, because sampled traces are not your request total.
How it connects. From a slow endpoint you open its slow, typical and failed traces, their logs, the session replay, the related issues and, when spans carry Kubernetes attributes, the workload and Pod they ran on. A P95 or error-rate alert rule pages through the same on-call routing as every other alert. A slowdown that starts with a deploy is shown as observed alongside that release, not as proof that the release caused it. Set up APM →
# APM · checkout-api · POST /checkout/{cartId}
Source Request metrics · Sampled
Latency P50 · P95 · P99, release 1.5.0 first seen
# Where the time goes (mean per request)
db:postgresql/orders ███████
inventory-api ████
Unattributed ██
Regression Open · P95 vs its own baseline
→ compare 1.5.0 with 1.4.0Chart and alert on any metric you send
What it does. The Metrics page charts any metric: OpenTelemetry metrics such as host CPU and memory from the Collector, counts and values a log pipeline extracts from your logs, and ASP.NET Core request durations. Pick an aggregation (average, sum, p95, p99, rate and more), filter by label and group by host, service or any label. The query lives in the URL, and Add to dashboard turns the chart into a Metric widget.
How it connects. The same names work in metric monitors, with one incident per host or group, and in anomaly monitors that compare a value with the same time on previous days or weeks. Request metrics also give APM complete request counts, so its error rates, percentiles and SLOs do not depend on how much you sample traces.
Know which workload broke, and the reason Kubernetes gave
The problem it solves. When a Deployment stops serving, the answer is usually already in
the cluster: a pod waiting on a Secret that does not exist, an image tag that was never pushed, a
node out of memory. It is spread across pod states, events and specs, and someone has to put it
together with kubectl while users wait.
How it works. Create a collector key under Kubernetes → Install and run one
helm install. The chart runs the upstream OpenTelemetry Collector in your cluster: a
cluster collector that watches objects and events, and an agent on each node for usage and
container logs. Access is read-only (get, list and watch), it cannot read Secrets or ConfigMaps,
environment variable values never leave the cluster, and all traffic is outbound HTTPS.
What you get. Every node, namespace, workload and pod, with CPU and memory against limits. Over twenty problem types, from crash loops, image pull errors and missing Secrets to unschedulable pods, stuck rollouts, failed Jobs and nodes that are not ready. Each problem names the workload a person would fix, the pods it affects, the cause when Kubernetes stated one, and the evidence. A timeline puts events, rollouts, problems, error logs and error traces in one order.
How it connects. Built-in monitors turn problems into incidents, one per problem, resolved on their own when the problem clears. Installing the chart does not set up paging: route a monitor to an escalation policy, or connect a PagerDuty or Opsgenie destination, and it pages through the same on-call path as every other alert. If the cluster itself goes quiet, that opens an incident too. Install and permissions →
- Your cluster
- Read-only collectors
- HTTPS out
- Problem + cause
- Incident
# Kubernetes · Problems
Missing Secret / ConfigMap (config error)
Deployment checkout-api · namespace shop
Pods 3 affected (0/3 available)
Reason CreateContainerConfigError
Cause Secret "payments-db" was not found.
Container "api" reads it through env
DATABASE_PASSWORD.
→ one incident, resolved when the pods startContinuous profiling
Which functions a service spends CPU, wall time and memory in, as flame graphs per release, compared with a baseline, and linked from a profiled trace. Send profiles from the open-source Pyroscope profilers (Go, Python, Node.js, .NET, Ruby, Rust) or from Sentry SDKs. Use it when APM shows a slower endpoint whose time is unattributed: APM cannot tell CPU from uninstrumented waiting, a profile can. Profiles are kept 14 days. Java JFR and OpenTelemetry profiles are not supported.
Browser RUM
How fast your site is for real visitors: Core Web Vitals (LCP, INP, CLS, plus FCP and TTFB), page load
phases, the API calls each page makes and its slowest assets, as percentiles computed on the server.
A slow call links to its backend trace. Turn it on in @ziplogger/browser 0.8.0 or later,
after consent, with the sample rate you choose. The numbers describe the sampled, consented page views,
not your total traffic.
Database monitoring On request
For PostgreSQL, MySQL and MariaDB: connections against the limit, normalized queries ranked by time, sessions blocked on a lock, query regressions and, where the engine allows, execution plans. You run one OpenTelemetry Collector next to the database with a read-only login. It is built but not switched on for every workspace: ask us to enable it. Other engines are not supported.
