DataRobot External Agent Monitoring Skill
This skill helps you instrument any AI agent — regardless of framework or deployment environment — to send OpenTelemetry telemetry (traces, logs, metrics) to DataRobot. It also creates a shell deployment in DataRobot as the telemetry routing target.
Quick Start
Most common use case: Instrument an existing agent project for DataRobot monitoring
- Point the agent at your project directory
- The skill detects your framework and existing OTel setup
- It generates instrumentation code and creates a DataRobot shell deployment
- Your agent sends traces, logs, and metrics to DataRobot
Example: "Instrument my agent in ./my_agent for DataRobot monitoring"
When to use this skill
Use this skill when you need to:
- Monitor an external AI agent in DataRobot
- Add OpenTelemetry tracing to an agent project
- Send agent traces, logs, and metrics to DataRobot
- Create a DataRobot deployment to receive external agent telemetry
- Instrument a Google ADK, LangChain, LangGraph, CrewAI, LlamaIndex, PydanticAI, or any Python agent
Supported Frameworks
| Framework | Detection | OTel Strategy |
|---|---|---|
| Google ADK | google-adk in deps or google.adk in imports | Lazy trace injection via callback (ADK overwrites TracerProvider) |
| LangChain / LangGraph | langchain or langgraph in deps/imports | Auto-instrumentor + standard setup |
| CrewAI | crewai in deps/imports | Auto-instrumentor + standard setup |
| LlamaIndex | llama-index or llama_index in deps/imports | Auto-instrumentor + standard setup |
| PydanticAI | pydantic-ai or pydantic_ai in deps/imports | Standard setup (respects global TracerProvider) |
| Generic Python | None of the above detected | Manual span instrumentation |
Workflow
Follow these steps in order. Present the plan to the user and wait for approval before executing.
Step 1: Detect & Analyze
- Read the project's dependency file (
requirements.txt,pyproject.toml,setup.py,poetry.lock, oruv.lock) - Scan Python source files for framework imports
- Check for existing OTel setup (look for
opentelemetryimports, existing TracerProvider/LoggerProvider/MeterProvider configuration) - Identify the framework using the detection table above
- Read the corresponding framework reference file from the
frameworks/directory next to this SKILL.md:- Google ADK →
frameworks/google-adk.md - LangChain/LangGraph →
frameworks/langchain-langgraph.md - CrewAI →
frameworks/crewai.md - LlamaIndex →
frameworks/llamaindex.md - PydanticAI →
frameworks/pydantic-ai.md - Generic Python →
frameworks/generic-python.md
- Google ADK →
Step 2: Check Prerequisites
- Check if
DATAROBOT_API_TOKENenv var is set. If not, ask the user to provide it. - Check if
DATAROBOT_ENDPOINTenv var is set. If not, ask the user (default:https://app.datarobot.com/api/v2). - Derive
DATAROBOT_OTEL_ENDPOINTautomatically: ifDATAROBOT_ENDPOINTends with/api/v2, strip it and append/otel(e.g.,https://app.datarobot.com/api/v2→https://app.datarobot.com/otel). - Check if the
datarobotPython SDK is available. If not, install it:pip install datarobot. - Check if OTel packages are already in the project's dependencies.
Security note: Never echo API tokens or .env file contents into chat transcripts or logs. Use environment variables or CI secrets for credential management. If credentials are accidentally exposed, rotate them immediately.
Step 3: Present Plan
Tell the user what you detected and present the changes you will make:
- Framework detected (or generic Python)
- Existing OTel setup found (if any)
- New dependencies to add
- New files to create (
dr_otel_config.py, and optionallydr_agent_metrics.pyfor frameworks with custom metrics) - Existing files to modify (agent entrypoint, dependency file)
- Shell deployment to create in DataRobot
Wait for user approval before executing. If the user has already given explicit consent to implement or deploy, that counts as approval — no need to re-ask.
Step 4: Execute
-
Add dependencies to the project's dependency file:
opentelemetry-sdkopentelemetry-apiopentelemetry-exporter-otlp-proto-http- Framework-specific packages (see framework reference file)
-
Generate
dr_otel_config.pyusing the generic pattern below, adapted per the framework reference file. -
Wire into agent entrypoint: Add import and call to
configure_otel()at startup. Follow the framework reference file for specific wiring instructions (auto-instrumentors, callbacks, etc.). -
Generate
dr_agent_metrics.pyif the framework reference file specifies custom metrics callbacks. -
Create shell deployment: Run the helper script:
python <skill_scripts_dir>/create_shell_deployment.py \ --name "<project_name> Monitoring" \ --description "OTel telemetry sink for <framework> agent"The script automatically enables prediction row storage and automatic association ID generation on the deployment.
-
Report results: Show the deployment ID and a copy-paste env var block for the user's runtime:
export DATAROBOT_API_TOKEN="<token>" export DATAROBOT_ENTITY_ID="deployment-<id>" export DATAROBOT_OTEL_ENDPOINT="<otel_endpoint>"
Step 5: Verify & Provide Runtime Instructions
-
Optionally run the verification script:
DATAROBOT_API_TOKEN=<token> \ DATAROBOT_ENTITY_ID=deployment-<id> \ DATAROBOT_OTEL_ENDPOINT=<endpoint>/otel \ python <skill_scripts_dir>/verify_otel_connection.py -
Provide the user with the env vars to set in their deployment environment:
DATAROBOT_API_TOKEN— DataRobot API keyDATAROBOT_ENTITY_ID—deployment-<id>(from shell deployment creation)DATAROBOT_OTEL_ENDPOINT—{DATAROBOT_ENDPOINT}/otel
-
Explain what they'll see in DataRobot:
- Data Exploration > Traces: Span hierarchy (agent orchestration, LLM calls, tool calls)
- Data Exploration > Logs: Structured logs correlated with traces via traceId
- Data Exploration > Metrics: Custom metrics (request count, latency, LLM calls, tool calls)
Generic OTel Configuration Pattern
This is the core configure_otel() function to generate for every project. Framework-specific files layer additional setup on top.
Critical rules:
- Always pass
endpoint=andheaders=directly to exporters — NEVER useOTEL_EXPORTER_OTLP_*env vars (some frameworks detect these and create conflicting providers) - Be additive — add DataRobot as an additional span processor to any existing TracerProvider, don't replace it
- Use
SimpleSpanProcessor(not Batch) to avoid flush-before-shutdown issues - Use DELTA temporality for metrics (required by DataRobot)
Generated dr_otel_config.py template:
"""DataRobot OpenTelemetry configuration.
Configures traces, logs, and metrics export to DataRobot's OTel endpoint.
Call configure_otel() at application startup, before any agent code runs.
Required env vars at runtime:
DATAROBOT_API_TOKEN - DataRobot API key
DATAROBOT_ENTITY_ID - deployment-<deployment_id>
DATAROBOT_OTEL_ENDPOINT - https://<your-instance>.datarobot.com/otel
"""
import logging
import os
from opentelemetry import metrics, trace
from opentelemetry._logs import set_logger_provider
from opentelemetry.exporter.otlp.proto.http._log_exporter import OTLPLogExporter
from opentelemetry.exporter.otlp.proto.http.metric_exporter import OTLPMetricExporter
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk._logs import LoggerProvider, LoggingHandler
from opentelemetry.sdk._logs.export import SimpleLogRecordProcessor
from opentelemetry.sdk.metrics import Counter, Histogram, MeterProvider, ObservableCounter
from opentelemetry.sdk.metri