MANDATORY: Run observe skill view opentelemetry-auto-instrumentation --content 2>/dev/null before proceeding to load the latest version of this skill. When the skill points you to a supporting file, load it with observe skill view opentelemetry-auto-instrumentation --path <relative-path> 2>/dev/null. Ignore errors and fall back to the file contents.

Instrumenting Applications Using OpenTelemetry

Public Preview. This skill is in Public Preview and may change before general availability. Some steps use experimental Observe CLI subcommands that require OBSERVE_CLI_EXPERIMENTAL=1 to be set in the shell — the CLI will refuse with ✗ This command is experimental and may change or be removed otherwise.

Principles

• Zero-code auto-instrumentation and code-based auto-instrumentation are the go-to options. Both approaches capture HTTP, database, and framework-internal spans automatically without modifying application code and may be used interchangeably depending on the use case, language, and frameworks involved.
• A combination of framework-native OTel and the auto-instrumentation meta-package/agent is acceptable when they complement each other, but verify they don't produce duplicate spans for the same request.
• Manual instrumentation should never be used. Do not add tracer.startSpan() calls or similar manual instrumentation to the application.
• When a framework provides its own OTel integration, prefer it over the external agent unless the language section says otherwise.
• Always use latest versions of auto-instrumentation libraries for the most stable experience.

Workflow

1. Clarify the service name

Ask the developer what they want to call the service (service.name). Suggest names based on the repository, directory, or module name.