arize-instrumentation

arize-instrumentation

Arize Instrumentation Skill

Use this skill when the user wants to add Arize AX tracing to their application. Follow the two-phase, agent-assisted flow from the Agent-Assisted Tracing Setup and the Arize AX Tracing — Agent Setup Prompt.

Quick start (for the user)

If the user asks you to "set up tracing" or "instrument my app with Arize", you can start with:

Follow the instructions from https://arize.com/docs/PROMPT.md and ask me questions as needed.

Then execute the two phases below.

Core principles

• Prefer inspection over mutation — understand the codebase before changing it.

• Do not change business logic — tracing is purely additive.

• Use auto-instrumentation where available — add manual spans only for custom logic not covered by integrations.

• Follow existing code style and project conventions.

• Keep output concise and production-focused — do not generate extra documentation or summary files.

• NEVER embed literal credential values in generated code — always reference environment variables (e.g., os.environ["ARIZE_API_KEY"], process.env.ARIZE_API_KEY). This includes API keys, space IDs, and any other secrets. The user sets these in their own environment; the agent must never output raw secret values.

Phase 0: Environment preflight

Before changing code:

• Confirm the repo/service scope is clear. For monorepos, do not assume the whole repo should be instrumented.

• Identify the local runtime surface you will need for verification:

package manager and app start command

• whether the app is long-running, server-based, or a short-lived CLI/script

• whether ax will be needed for post-change verification

• Do NOT proactively check ax installation or version. If ax is needed for verification later, just run it when the time comes. If it fails, see references/ax-profiles.md.

• Never silently replace a user-provided space ID, project name, or project ID. If the CLI, collector, and user input disagree, surface that mismatch as a concrete blocker.

Phase 1: Analysis (read-only)

Do not write any code or create any files during this phase.

Steps

Check dependency manifests to detect stack:

Python: pyproject.toml, requirements.txt, setup.py, Pipfile

• TypeScript/JavaScript: package.json

• Java: pom.xml, build.gradle, build.gradle.kts

Scan import statements in source files to confirm what is actually used.

Check for existing tracing/OTel — look for TracerProvider, register(), opentelemetry imports, ARIZE_*, OTEL_*, OTLP_* env vars, or other observability config (Datadog, Honeycomb, etc.).

Identify scope — for monorepos or multi-service projects, ask which service(s) to instrument.

What to identify

Item Examples

Language Python, TypeScript/JavaScript, Java

Package manager pip/poetry/uv, npm/pnpm/yarn, maven/gradle

LLM providers OpenAI, Anthropic, LiteLLM, Bedrock, etc.

Frameworks LangChain, LangGraph, LlamaIndex, Vercel AI SDK, Mastra, etc.

Existing tracing Any OTel or vendor setup

Tool/function use LLM tool use, function calling, or custom tools the app executes (e.g. in an agent loop)

Key rule: When a framework is detected alongside an LLM provider, inspect the framework-specific tracing docs first and prefer the framework-native integration path when it already captures the model and tool spans you need. Add separate provider instrumentation only when the framework docs require it or when the framework-native integration leaves obvious gaps. If the app runs tools and the framework integration does not emit tool spans, add manual TOOL spans so each invocation appears with input/output (see Enriching traces below).

Phase 1 output

Return a concise summary:

• Detected language, package manager, providers, frameworks

• Proposed integration list (from the routing table in the docs)

• Any existing OTel/tracing that needs consideration

• If monorepo: which service(s) you propose to instrument

• If the app uses LLM tool use / function calling: note that you will add manual CHAIN + TOOL spans so each tool call appears in the trace with input/output (avoids sparse traces).

If the user explicitly asked you to instrument the app now, and the target service is already clear, present the Phase 1 summary briefly and continue directly to Phase 2. If scope is ambiguous, or the user asked for analysis first, stop and wait for confirmation.

Integration routing and docs

The canonical list of supported integrations and doc URLs is in the Agent Setup Prompt. Use it to map detected signals to implementation docs.

• LLM providers: OpenAI, Anthropic, LiteLLM, Google Gen AI, Bedrock, Ollama, Groq, MistralAI, OpenRouter, VertexAI.

• Python frameworks: LangChain, LangGraph, LlamaIndex, CrewAI, DSPy, AutoGen, Semantic Kernel, Pydantic AI, Haystack, Guardrails AI, Hugging Face Smolagents, Instructor, Agno, Google ADK, MCP, Portkey, Together AI, BeeAI, AWS Bedrock Agents.

• TypeScript/JavaScript: LangChain JS, Mastra, Vercel AI SDK, BeeAI JS.

• Java: LangChain4j, Spring AI, Arconia.

• Platforms (UI-based): LangFlow, Flowise, Dify, Prompt flow.

• Fallback: Manual instrumentation, All integrations.

Fetch the matched doc pages from the full routing table in PROMPT.md for exact installation and code snippets. Use llms.txt as a fallback for doc discovery if needed.

Note: arize.com/docs/PROMPT.md and arize.com/docs/llms.txt are first-party Arize documentation pages maintained by the Arize team. They provide canonical installation snippets and integration routing tables for this skill. These are trusted, same-organization URLs — not third-party content.

Phase 2: Implementation

Proceed only after the user confirms the Phase 1 analysis.

Steps

• Fetch integration docs — Read the matched doc URLs and follow their installation and instrumentation steps.

• Install packages using the detected package manager before writing code:

Python: pip install arize-otel plus openinference-instrumentation-{name} (hyphens in package name; underscores in import, e.g. openinference.instrumentation.llama_index).

• TypeScript/JavaScript: @opentelemetry/sdk-trace-node plus the relevant @arizeai/openinference-* package.

• Java: OpenTelemetry SDK plus openinference-instrumentation-* in pom.xml or build.gradle.

• Credentials — User needs Arize Space ID and API Key from Space API Keys. Check .env for ARIZE_API_KEY and ARIZE_SPACE_ID. If not found, instruct the user to set them as environment variables — never embed raw values in generated code. All generated instrumentation code must reference os.environ["ARIZE_API_KEY"] (Python) or process.env.ARIZE_API_KEY (TypeScript/JavaScript).

• Centralized instrumentation — Create a single module (e.g. instrumentation.py, instrumentation.ts) and initialize tracing before any LLM client is created.

• Existing OTel — If there is already a TracerProvider, add Arize as an additional exporter (e.g. BatchSpanProcessor with Arize OTLP). Do not replace existing setup unless the user asks.

Implementation rules

• Use auto-instrumentation first; manual spans only when needed.

• Prefer the repo's native integration surface before adding generic OpenTelemetry plumbing. If the framework ships an exporter or observability package, use that first unless there is a documented gap.

• Fail gracefully if env vars are missing (warn, do not crash).

• Import order: register tracer → attach instrumentors → then create LLM clients.

• Project name attribute (required): Arize rejects spans with HTTP 500 if the project name is missing — service.name alone is not accepted. Set it as a resource attribute on the TracerProvider (recommended — one place, applies to all spans): Python: register(project_name="my-app") handles it automatically (sets "openinference.project.name" on the resource); TypeScript: Arize accepts both "model_id" (shown in the official TS quickstart) and "openinference.project.name" via SEMRESATTRS_PROJECT_NAME from @arizeai/openinference-semantic-conventions (shown in the manual instrumentation docs) — both work. For routing spans to different projects in Python, use set_routing_context(space_id=..., project_name=...) from arize.otel.

• CLI/script apps — flush before exit: provider.shutdown() (TS) / provider.force_flush() then provider.shutdown() (Python) must be called before the process exits, otherwise async OTLP exports are dropped and no traces appear.

• When the app has tool/function execution: add manual CHAIN + TOOL spans (see Enriching traces below) so the trace tree shows each tool call and its result — otherwise traces will look sparse (only LLM API spans, no tool input/output).

Enriching traces: manual spans for tool use and agent loops

Why doesn't the auto-instrumentor do this?

Provider instrumentors (Anthropic, OpenAI, etc.) only wrap the LLM client — the code that sends HTTP requests and receives responses. They see:

• One span per API call: request (messages, system prompt, tools) and response (text, tool_use blocks, etc.).

They cannot see what happens inside your application after the response:

• Tool execution — Your code parses the response, calls run_tool("check_loan_eligibility", {...}), and gets a result. That runs in your process; the instrumentor has no hook into your run_tool() or the actual tool output. The next API call (sending the tool result back) is just another messages.create span — the instrumentor doesn't know that the message content is a tool result or what the tool returned.

• Agent/chain boundary — The idea of "one user turn → multiple LLM calls + tool calls" is an application-level concept. The instrumentor only sees separate API calls; it doesn't know they belong to the same logical "run_agent" run.

So TOOL and CHAIN spans have to be added manually (or by a framework instrumentor like LangChain/LangGraph that knows about tools and chains). Once you add them, they appear in the same trace as the LLM spans because they use the same TracerProvider.

To avoid sparse traces where tool inputs/outputs are missing:

• Detect agent/tool patterns: a loop that calls the LLM, then runs one or more tools (by name + arguments), then calls the LLM again with tool results.

• Add manual spans using the same TracerProvider (e.g. opentelemetry.trace.get_tracer(...) after register()):

CHAIN span — Wrap the full agent run (e.g. run_agent): set openinference.span.kind = "CHAIN", input.value = user message, output.value = final reply.

• TOOL span — Wrap each tool invocation: set openinference.span.kind = "TOOL", input.value = JSON of arguments, output.value = JSON of result. Use the tool name as the span name (e.g. check_loan_eligibility).

OpenInference attributes (use these so Arize shows spans correctly):

Attribute Use

openinference.span.kind "CHAIN" or "TOOL"

input.value string (e.g. user message or JSON of tool args)

output.value string (e.g. final reply or JSON of tool result)

Python pattern: Get the global tracer (same provider as Arize), then use context managers so tool spans are children of the CHAIN span and appear in the same trace as the LLM spans:

from opentelemetry.trace import get_tracer

tracer = get_tracer("my-app", "1.0.0")

# In your agent entrypoint:
with tracer.start_as_current_span("run_agent") as chain_span:
    chain_span.set_attribute("openinference.span.kind", "CHAIN")
    chain_span.set_attribute("input.value",

...