Telemetry
The data a running app sends out about itself: logs, numbers, and timings. The raw material every dashboard and alert is built from.
See it
What it is
Telemetry is everything a running system says about itself: log lines, numeric measurements, request timings, profiles. It is the raw material. Observability is what you get when the raw material is good enough to answer questions with. OpenTelemetry is the standard shape for it, so you can instrument once and change vendors later instead of rewriting every call site.
Emit it from day one, at low volume. The cheap starter kit: one structured log line per request carrying method, route, status, duration, and user or tenant id, plus counters for the handful of things you would page someone about. Attach resource attributes (service.name, deployment.environment, service.version) once at startup so every signal is attributable.
Gotcha: telemetry bills scale with volume and with distinct values, not with usefulness. A single label like user_id can multiply one metric into a million time series, which is the classic cardinality explosion. The other trap is legal, not financial: telemetry sprayed with emails, tokens, and full request bodies turns your log store into a breach waiting to happen, so redact at the emit point rather than the storage point.
Ask AI for it
Add an OpenTelemetry telemetry layer to this service. Configure a global resource with service.name, service.version (git SHA), and deployment.environment. Auto-instrument HTTP, the database client, and the job queue, then add manual spans around the two slowest business operations. Emit a counter for requests, a histogram for request duration in milliseconds, and a gauge for queue depth. Export everything over OTLP to a single configurable endpoint, sample traces at 10 percent in production and 100 percent in development, and redact authorization headers and email fields before export.