App Telemetry
App Telemetry is Zharp's APM (application performance monitoring). Add the Zharp SDK to an app and its errors, traces, logs and sessions arrive in Zharp, each tied to the user, device and release it came from.
App Telemetry in the dashboard sidebar is where your apps report to. It takes data from the Zharp SDKs — browser, Node.js, Python, Go, PHP, Flutter, Android and iOS — and from any app that already speaks OpenTelemetry. To connect your first app, see Getting Started.
Apps
An app is one codebase on one platform. A web front end and the API behind it are two apps — say Checkout web (Browser) and Checkout API (Node.js) — and a request that starts in one and continues in the other is one trace across both.
Each app has:
- A name, what your team calls it.
- A service name, what the SDK reports as
service.name—checkout-webfor an app namedCheckout webunless you choose another. - An ingest key starting
zpk_, which can only send data. See Keys.
Discovered apps
Data sent with a workspace API key instead of an app key is filed by its service.name. A service name that matches an app goes to that app; one that doesn't creates a Discovered app, listed below your other apps with how much it has sent. Click Name and claim, give it a name and click Claim app to list it with the rest. This is how services sending through the Zharp agent or an OpenTelemetry Collector show up.
What you see
The App Telemetry page shows a card per app: requests (page loads for a browser app, sessions and crash-free sessions for a mobile one), error rate, p95, users who hit an error, and open issues. Open an app for its tabs. Every tab follows the time window at the top — 1 hour, 24 hours, 7 days or 30 days.
| Tab | What it shows |
|---|---|
| Overview | Requests or page loads, error rate, p95, users, and error-free (or crash-free) sessions; traffic with failures and releases marked; the top issues; the slowest routes or pages; and each release with its error rate. |
| Errors | Issues — errors grouped by what broke — with a trend, event and user counts, and when each was first and last seen. Filter by Open, Resolved or Ignored; sort by last seen, first seen, most events or most users. |
| Traces | Requests into this app: page loads and clicks on clients, incoming calls on servers, with the user, release and duration. Errors only is one click. |
| Logs | The app's log lines by level, each one a way into its trace, user and session. The same lines are on the Logs page with the rest of your logs. |
| Sessions | Visits, with their errors, length, device and whether a recording exists. Browser sessions can be replayed. |
| Users | The people you told the SDK about with setUser, their devices, sessions and errors, and everything each one did. |
An issue
An issue's page shows its stack trace (library and runtime frames dimmed so your own code stands out), the release, environment, browser or device and whether it was handled — Yes, caught in code or No, it crashed. Under What happened before are the requests, logs and other errors from the same session leading up to it, and Who it's happening to lists the users affected. Open trace goes to the request it happened in, and Watch replay to the recording, when there is one.
A trace
A trace is one request followed through every app it touched: the browser's click or page load, the API call, the database queries behind it. The trace page draws it as a waterfall, colours spans by app and lists Apps in this trace. Log lines written during a span appear under it, and errors link to their issue. Who and where shows the user, device, session and release.
How errors become issues
Every error the SDKs report — uncaught ones and the ones you report yourself — is an error event. Events are grouped into an issue by the error's type plus the top frames of its stack trace that belong to your app. Line and column numbers, bundle hashes, memory addresses and hostnames are left out, so the same bug in the next build still lands in the same issue. An error with no stack trace is grouped by its type and its message, with numbers, IDs and quoted values taken out — so user 41 not found and user 7 not found are one issue.
- Resolve an issue once it's fixed. If it happens again after that, it reopens by itself and is marked Regressed.
- Ignore one you don't intend to fix. It stays ignored however often it happens.
- Reopen puts a resolved or ignored issue back in the open list.
- An issue first seen in the newest release is marked New in <release> — the quickest way to see what a deploy broke. Set
releasein the SDK to get it.
Upload your build's source maps, R8/ProGuard mapping, Dart symbols or dSYMs and errors are shown — and grouped — by your original functions, files and lines. See Readable stack traces.
Sessions and users
The browser, Flutter, Android and iOS SDKs give every visit a session: everything the person did until they were idle or in the background for 30 minutes, or signed out. Call setUser once someone signs in, and their errors, traces, logs and sessions carry their ID — and their requests to your API carry it too, so your server's errors are filed under the same person. See Who the user is.
Retention
Errors, traces, logs and sessions are kept for your plan's log retention. Session recordings are kept for 7 days, or less if your plan's retention is shorter. Deleting an app deletes all of its data and recordings at once.