Observability

When a request fails halfway through three services and a queue, the question is "where, and for whom?". Traces answer where (one tree of timed spans per request), metrics answer how often and how much (counts and distributions over time), logs answer what exactly happened at a point (structured events tied to the trace). OpenTelemetry produces all three in one vendor-neutral format (OTLP), so you instrument once and change backends by configuration. Read the file for the job:

Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]

The job	Read
Wire the Node SDK, custom spans and metrics, log correlation, request context, errors, sampling, tracing through queues	INSTRUMENT.md
Where telemetry goes: direct export, one collector, agent plus gateway, local stacks, Grafana Cloud	COLLECTOR.md
Liveness and readiness endpoints and what they check	HEALTH.md
Read monitoring graphs and diagnose traffic, latency, error, saturation, pool and queue patterns	DIAGNOSE.md
Triage and mitigate an incident, observe a deploy, compare slow trends and write the postmortem	INCIDENT-RESPONSE.md
Design structured/wide log events, context, levels, schema and privacy; distinguish log policies from trace sampling	LOGGING.md

observability

Observability

The rules