Dd Instrument Llmo

Datadog LLM Observability Instrumentation

This skill assesses the current project (backend runtime, LLM/agent framework, existing instrumentation) and routes you to the right reference file under references/ for the actual setup steps. It is fully self-contained — it does not call any Datadog MCP server. Credential provisioning uses the local CreateApiKey tool, and all code changes are made by you, directly, using your own file-editing tools.

Stay within LLM Observability scope. Do not add RUM, APM application instrumentation, or unrelated Datadog products. RUM and a Datadog Agent are relevant only because they change what session/trace linking is achievable (see the "Beyond SDK init" section in the reference files).

Do NOT invent tool names. Use only CreateApiKey as described in references/common-credentials.md; every other step is done with your normal file-editing/search tools.

Do NOT write anything to memory during or after this skill. Project paths, frameworks, credentials, and ML app names are project-specific and must not be stored in persistent memory.

Ground rules while instrumenting

• Verify before you assert. If you're not sure about file content or codebase structure, read the files — do not guess.
• Check for existing instrumentation first. Before touching the backend, check whether ddtrace/dd-trace is already initialized with LLM Observability enabled. If it is, do not add a second, competing init/enable call. This only means skip re-init — it does not mean skip the work. SDK presence is not the same as a well-formed trace or a session ID that actually flows; run the session-ID plumbing audit in Phase 1d and close any gap it finds, even when the SDK is already present.
• Only use packages/features you've explicitly been told to add. Don't decide on your own to enable an additional Datadog product or SDK feature beyond what this skill specifies.
• Persist added dependencies into the deploy's manifest. Any Datadog package you add (ddtrace, dd-trace) must be written into the dependency manifest the build/deploy installs from — the one identified in Phase 1e — not just installed into the local environment. A clean deploy install reads only the manifest and will crash with a missing-module error (e.g. ModuleNotFoundError: No module named 'ddtrace') if the package isn't declared there.
• Don't make stylistic changes to code you're not otherwise touching.
• No package aliases when importing Datadog packages.
• Copy Datadog SDK package names, import paths, and init keyword arguments verbatim from the applicable reference section — do not paraphrase them from memory. The Python LLM Observability import is exactly from ddtrace.llmobs import LLMObs — the module is ddtrace.llmobs, not ddtrace.llm_observability (that module does not exist and produces a deploy-time ModuleNotFoundError). The Node package is dd-trace, initialized with the form that matches the project: CommonJS require('dd-trace').init(...), an ESM import-based form for "type": "module"/.mjs projects, or Next.js's dd-trace/initialize.mjs in instrumentation.ts — all shown in references/llmobs-nodejs.md; never force require(...) into an ESM project. Use the exact LLMObs.enable(...) / .init({...}) keyword arguments shown; do not add, drop, or rename kwargs based on general Datadog knowledge.
• Use a real edit tool for existing files (Edit/Write, not sed -i, awk, or scripted find/replace via Bash). If an edit-by-text-match fails, re-read the file first rather than retrying the identical edit.
• Checklist discipline. Before starting the instrumentation steps, post a short checklist of the steps you're about to take. Check items off as you go, and review the checklist at the end of the run.
• After any code change, check package.json for a lint:fix, fix, or format script (or eslint --fix / prettier --write config) and run it automatically — no need to ask permission.
• Verify the app still builds/runs before declaring success (see references/common-verify-report.md).
• LLM Observability session IDs propagate from the root span only. Never pass a session ID to a child span/decorator — see the "Adding spans" section in references/llmobs-python.md / references/llmobs-nodejs.md.
• Don't promise what the environment doesn't support. If no RUM SDK is detected, don't claim RUM session linking; if no dd-agent is detected, don't claim navigable APM trace linking. State the gap and the upgrade path instead (see the "Beyond SDK init" section in the reference files).

---

Phase 1: Analysis

Inspect the relevant application directory before asking questions or editing files.

1a. Detecting the backend LLM/agent runtime

• Python signals: requirements.txt, pyproject.toml, Pipfile, or *.py files → runtime python
• Node.js signals: a backend entry point (server.js, index.js, an Express/Next.js/Fastify app) → runtime nodejs
• If both exist (e.g. a Next.js app with a Python worker), instrument each backend runtime independently.
• If neither is present, there is nothing to instrument — stop and tell the user.

1b. Detecting the LLM framework/SDK (optional, informational)

Check dependency files for signals of: openai, @anthropic-ai/sdk / anthropic, langchain, langgraph, ai (Vercel AI SDK), boto3 + Bedrock usage, google-generativeai / google-genai, crewai, litellm, pydantic-ai, an MCP SDK, google-adk. This doesn't change the init code (ddtrace/dd-trace auto-instruments these SDKs once the tracer is initialized) — it's only used for confirming the setup with the user and for special-cased frameworks noted in the reference files (Next.js, Vercel AI SDK).

1c. Detecting the backend application framework

• Python: fastapi, flask, or django dependency
• Node.js: express dependency, or next (Next.js API routes / server actions)