Otel Guides

OpenTelemetry Language Guides

A selection map over the official OpenTelemetry docs (https://opentelemetry.io/docs/languages/). Pick the language of the code you are instrumenting, read its reference file, then fetch the linked official pages you need — links ending in index.md return the page as raw markdown (the rest are external redirects), so read them directly instead of paraphrasing from memory.

Pick the language

Each reference file lists every section of that language's official docs — what it covers and what to do with it when planning instrumentation (getting started, traces, metrics, logs, instrumentation libraries, zero-code instrumentation where it exists, exporters, resources, sampling, API references, registry).

Cross-language references

Five things are the same whatever the language: the environment variables that configure the SDK (OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_RESOURCE_ATTRIBUTES, ...), the conventions that name what you emit (resource, HTTP, database, messaging, RPC, ...), the generative AI conventions (gen_ai.* spans, token and duration metrics, content capture) with the instrumentation library that emits them per SDK or framework, the option of putting a Collector between the app and the backend (agent, gateway, or neither), and the state of profiling (the signal's status, why a vendor profiler bypasses the Collector, how profiles correlate with traces).

Open the semantic conventions reference for every domain you name things in, the generative AI reference whenever the code calls a model, an agent framework, or an MCP server (its detection section lists the manifest names that mean it does), the Collector reference before deciding between direct OTLP export and a Collector, and the profiling reference before promising profiles — its per-language table says which profiler exists for each language.

Rules

• Always confirm against the fetched official page before recommending a package name, API call, or env var — the linked docs are the source of truth, not memory.
• When a sentence decides a design, read the index.md page raw (curl -sL <url>) rather than through a summarising fetch: a summary dropped the Python distro page's "loaded ... via the entry points ... before any other code is executed", the one sentence that settles where code runs under the zero-code wrapper.
• Prefer zero-code/automatic instrumentation and existing instrumentation libraries over manual spans; check the language's registry section before writing any manual instrumentation.
• The registry pages render client-side, so a text fetch of them often returns nothing. When that happens, fall back in order: the language's contrib repository on GitHub (opentelemetry-<lang>-contrib — for Java it is opentelemetry-java-instrumentation — whose README lists the instrumentation packages), then the package index search (pip index, npm search @opentelemetry, Maven Central, NuGet, crates.io). If a page cannot be fetched at all, say so and mark whatever you derived from it as unverified — never present an unfetched claim as sourced.
• The planning notes in each reference file are a snapshot (last verified 2026-08; the profiling reference, the ## Profiling sections and the Python zero-code, resource-detector and pinning notes 2026-09-05); the fetched official page always overrides them — re-verify any stability or version claim you rely on.
• The local stack is one odd_stack_up away: OTLP on http://localhost:4317 (gRPC) / :4318 (HTTP). localhost holds only for host processes — a containerized app needs the host reachable from inside the container (e.g. host.docker.internal).