Prerequisites
Read these first if Play Vitals, Crashlytics, RUM, or SLIs are new.
- Play Vitals — crash/ANR/startup as store-facing health
- Firebase Crashlytics — stack traces and breadcrumbs
- SRE book — SLIs — what to measure vs vanity counters
- OpenTelemetry logs/metrics — separating signals in a telemetry map
More telemetry is not more control
Mobile teams either drown in unsampled logs nobody reads, or fly blind when crash-free sessions move. The fix is not another SDK. Pick signals that drive ship/fix decisions, and own who pages when they move.
ANR forensics live in ANR traces lie by omission. Client↔server correlation lives in telemetry across client and server. This post is the decision bar those essays assume.
Decide with SLIs, not vanity counts
Start with three SLIs the team will defend — for example crash-free users, p95 inbox open, send success. Then map each to a pipe:
| Pipe | Answers | Examples |
|---|---|---|
| Crashes / ANRs / non-fatals | What broke, how often | Stack + breadcrumbs + custom keys |
| Action / product logs | What the user tried | open thread, send, attach (privacy-reviewed) |
| Metrics | Is the system healthy | counters, timers, histograms (cold start, sync p95) |
Play Vitals and vendor dashboards will not match one-to-one. Collection windows differ. That is fine if you page on rate of change and absolute thresholds for the SLIs — not on every log line.
Vanity event counts (“opened screen” × 40 flavors) feel like control and produce neither alerts nor fixes. If everything is a “log,” nothing is an alert. If everything is an alert, nobody pages.
Own the pipe, sample on purpose
- Map each SLI to one primary tool and one human owner (Crashlytics or Play Vitals for crash-free; RUM/custom metrics for p95 open; product analytics for send success — pick what you already operate).
- Alert on the SLI, not on the SDK catalog. Datadog, Sentry, Bugsnag, Perfetto, and Play Console are means; the decision is the SLI.
- Sample per pipe: high capture for crashes/ANRs; aggressive sampling for verbose action logs; cheap continuous metrics. One global “log level” either blinds you or bankrupts storage and privacy review.
Shared concerns everywhere: PII redaction, offline batching, and correlation IDs from APK to backend. Treat action logs as production data, not debug leftovers.
Instrument for decisions. Separate crash, action, and metric pipes so a green chat of log volume cannot hide a red crash-free curve. Pair this bar with the ANR and cross-tier posts — do not paste every stack into a log pipeline and call it observability.
A useful smell test before adding an SDK: name the decision it will change this quarter (ship, rollback, page, or ignore). If you cannot name the decision, you are buying a dashboard, not control.
References
- Datadog Mobile RUM — sessions, errors, and custom metrics in one vendor pipe
- Diagnose crashes — crash-free users as a store-facing SLI, distinct from log volume
- SRE workbook — Alerting on SLOs — page on burn, not on every log line