Universal OpenTelemetry auto-instrumentation planning and review guidance. Use when deciding whether agent/library instrumentation is sufficient, when tuning auto-instrumented boundaries, when avoiding duplicate manual spans, or when reviewing auto instrumentation for noise, PII, volume, and business value.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Universal OpenTelemetry auto-instrumentation planning and review guidance. Use when deciding whether agent/library instrumentation is sufficient, when tuning auto-instrumented boundaries, when avoiding duplicate manual spans, or when reviewing auto instrumentation for noise, PII, volume, and business value.
OpenTelemetry Auto-Instrumentation
Use this skill when planning, implementing, or reviewing auto-instrumentation.
It is universal guidance. Language-specific setup skills decide how a runtime enables
the chosen auto-instrumentation; this skill decides whether it should be enabled,
constrained, supplemented, or excluded.
Non-Negotiable Rules
Auto-instrumentation availability is not approval to export everything. Include
only services and boundaries that help debug production issues or explain critical
business workflows.
Auto-instrumented boundaries still need scope, signal, privacy, volume, and noise
decisions before SDK setup writes final configuration.
Prefer auto spans for standard boundaries such as HTTP, database, messaging, RPC,
and cache. Do not add manual spans around those same operations unless the manual
work adds business context without duplicating the auto span.
Use auto + manual context when an auto span exists but the trace would otherwise
miss a degraded state, fallback, retry outcome, or business milestone. Annotate the
owning/current span or emit a bounded event instead of wrapping the auto boundary in
another span.
Exclude or suppress low-value expected traffic such as health checks, readiness and
liveness probes, metrics/debug endpoints, static assets, and internal platform probes.
Do not enable capture of request bodies, response bodies, message payloads, cookies,
authorization headers, API keys, tokens, credentials, or other sensitive headers.
Prefer route templates and stable operation names. Avoid raw full URLs, path values
containing IDs, unsanitized SQL values, message payloads, request IDs, timestamps,
usernames, emails, and other unbounded values.
Logs and baggage are not implied by auto-instrumentation. Logs need an explicit
redaction/export policy. Baggage needs explicitly bounded allowlisted keys.
Production sampling must be intentional. Unconditional always_on for production
requires an explicit plan rationale or an explicitly documented downstream sampling
control.
Decision Workflow
For each detected service and boundary:
Identify the business workflow or operational incident this telemetry explains.
Decide whether the service is in scope, out of scope, or lower priority.
Decide whether the boundary is auto, manual, auto + manual context, or excluded.
Identify auto-instrumentation tuning required before export:
endpoint suppressions
service suppressions
signal scope
sampling policy
body/header/payload capture policy
SQL or statement sanitization expectations
propagation policy
Record PII, cardinality, volume, and noise risks in the instrumentation plan.
If the auto span already answers the production-debugging question, do not add
manual instrumentation.
Common Decisions
Auto
Use auto when a standard instrumentation library or agent covers the boundary and
the default span explains the production question.
Examples:
inbound HTTP route latency and status
outbound HTTP dependency latency
JDBC or ORM query latency with sanitized statement metadata
Kafka or queue produce/consume trace continuity
Auto + Manual Context
Use auto + manual context when the auto span exists but misses a meaningful business
or degraded outcome.
Examples:
HTTP request returns 200 with partial data after a fallback
retries eventually succeed but should be visible as degradation
a cache miss triggers a slow downstream dependency call
a message is consumed successfully but routed to a dead-letter path
The manual work should usually annotate the current span or emit a bounded event. Do
not create a duplicate child span around the auto-instrumented HTTP, DB, RPC, messaging,
or cache call.
Manual
Use manual when no auto instrumentation covers the operation and the operation is a
meaningful runtime boundary or critical business milestone.
Examples:
third-party SDK call not covered by HTTP/RPC instrumentation
custom workflow step that owns a user-visible outcome
fallback path that does not cross a separately auto-instrumented boundary
Excluded
Use excluded when telemetry would add cost or cognitive load without improving
runtime understanding.
