/quickstart/ai-agent
OTLP / standard env vars
free plan / 1 gb-mo
telemtra.io
// quickstart / ai agent

Paste one prompt.
Your AI agent ships the telemetry.

Telemtra is OpenTelemetry-native, so any capable coding agent — Claude Code, Cursor, Cline — can wire up the SDK, set the env vars, and start sending data without you writing a line of instrumentation. Copy a prompt below, drop into your agent, get your first span in under a minute.

// three steps

Three steps to live telemetry.

Get a key, set four env vars, paste a prompt into your agent. The agent handles the rest.

[01] / get your api key

Sign up and copy your API key.

Sign up with email, confirm, and your free workspace is created. Open Workspace settings → API keys and copy the key. You will paste it into .env in step 2.

[02] / set your .env

Add four OpenTelemetry env vars.

These follow the OpenTelemetry standard — every official SDK reads them automatically. Drop them into your project's .env file:

shell .env
TELEMTRA_API_KEY=tk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}

Replace tk_live_xxx... with the key from step 1. The prompt itself contains no secrets — your agent reads them from this file at runtime.

[03] / paste into your agent

Pick your stack, copy the prompt, paste.

Each prompt is self-contained: it tells the agent which packages to install, how to wire the framework, and how to verify the result. Approve the agent's edits, run the app, and check app.telemtra.io/overview.

// pick your stack

Copy the right prompt for your stack.

Generic works for anything. The stack-specific prompts are pre-tailored to the common frameworks in each ecosystem.

// generic

Generic prompt (any stack)

Use this when your stack is not in the list below, or when you want the agent to detect the language and framework itself. Works well with Claude Code and Cursor; weaker agents may need a nudge.

prompt generic
You are helping me instrument my application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Authentication: x-api-key header
- Configuration is via standard OpenTelemetry environment variables — the SDK reads them automatically when initialized:
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<auto-detect from project name>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<auto-detect>
- All env vars live in my .env file.

GOAL:
1. Detect the primary language and framework (check package.json, Cargo.toml, pyproject.toml/requirements.txt, go.mod, *.csproj, pom.xml, build.gradle, Gemfile).
2. Install the OFFICIAL OpenTelemetry SDK + auto-instrumentation packages for that stack (no third-party reimplementations).
3. Add the env vars above to .env. For OTEL_SERVICE_NAME, use the project's package name. For deployment.environment, read from NODE_ENV / ENV / ENVIRONMENT / RAILS_ENV / ASPNETCORE_ENVIRONMENT (whichever is conventional for this stack); default to "development".
4. Initialize the SDK as early as possible in the entry point (before other modules in load-order-sensitive languages like Node/Python).
5. Ensure auto-instrumentation is enabled so HTTP/db/messaging calls are captured without manual span code.

CONSTRAINTS:
- Use OTLP HTTP (http/protobuf), not gRPC.
- If existing OpenTelemetry setup is detected, STOP and ask me before modifying it.
- Do not commit .env. Add it to .gitignore if not present.
- Do not inline the API key in source.

VERIFY:
After implementation, give me an exact command to start the app and a curl command to hit a known route (detect the port and an endpoint from the code). Run both, then open https://app.telemtra.io/overview — my service should appear within 60 seconds.
// node.js

Node.js / TypeScript prompt

Auto-instruments Express, Fastify, NestJS, Koa, and most popular Node libraries via the official auto-instrumentations-node bundle. Works for both CommonJS and ESM projects.

prompt node.js
You are helping me instrument my Node.js / TypeScript application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Auth: x-api-key header.
- Required env vars in .env (loaded via dotenv):
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<package.json name>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<NODE_ENV or "development">

GOAL:
1. Install via the project's package manager (detect from lockfile):
     @opentelemetry/sdk-node
     @opentelemetry/auto-instrumentations-node
     @opentelemetry/exporter-trace-otlp-http
     @opentelemetry/exporter-metrics-otlp-http
     @opentelemetry/exporter-logs-otlp-http
     dotenv (if not present)
2. Create tracing.js (CommonJS) or instrumentation.ts (ESM/TS) at the project root. In it:
   - require('dotenv').config() (or import 'dotenv/config') at the top.
   - Instantiate NodeSDK with getNodeAutoInstrumentations() — this auto-wires HTTP, Express, Fastify, MySQL, PostgreSQL, Redis, Mongoose, ioredis, etc.
   - The OTLP exporters read OTEL_EXPORTER_OTLP_* env vars automatically — don't hardcode URL or headers.
   - sdk.start();
   - process.on('SIGTERM', () => sdk.shutdown());
3. Wire the entry point to load tracing BEFORE app code:
     "start": "node --require ./tracing.js ./src/index.js"      (CommonJS)
     "start": "node --import ./instrumentation.js ./src/index.js"   (ESM)

CONSTRAINTS:
- Use ONLY official @opentelemetry/* packages.
- Tracing file MUST load first — otherwise auto-instrumentation can't patch the require/import hooks.
- If @opentelemetry/* is already in dependencies, STOP and ask me before modifying.
- Do not commit .env.

VERIFY:
Run npm start (or yarn/pnpm equivalent), then give me a curl command for a known route in the app (detect the port — likely 3000 — and a route from the code). Run the curl, then open https://app.telemtra.io/overview — telemetry should appear within 60 seconds.
// rust

Rust prompt (traces + metrics + logs)

Wires opentelemetry-otlp 0.27 for all three signals plus tracing-opentelemetry so existing tracing::info! and #[instrument] macros stream through. Handles axum, actix-web, rocket, warp, and tonic.

prompt rust
You are helping me instrument my Rust application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Auth: x-api-key header.
- Required env vars (add to .env, load via dotenvy):
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<Cargo package name>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<see GOAL step 4>

GOAL:
1. Detect the framework from Cargo.toml: axum, actix-web, rocket, warp, or tonic (gRPC). If none, set up basic tracing only.
2. Add crates to Cargo.toml [dependencies] (latest stable):
     opentelemetry = { version = "0.27", features = ["trace", "metrics", "logs"] }
     opentelemetry_sdk = { version = "0.27", features = ["rt-tokio", "trace", "metrics", "logs"] }
     opentelemetry-otlp = { version = "0.27", features = ["http-proto", "reqwest-client", "trace", "metrics", "logs"] }
     opentelemetry-appender-tracing = "0.27"
     tracing = "0.1"
     tracing-subscriber = { version = "0.3", features = ["env-filter"] }
     tracing-opentelemetry = "0.28"
     dotenvy = "0.15"
3. Framework wiring:
   - axum:      tower-http with "trace" feature → TraceLayer::new_for_http().
   - actix-web: actix-web-opentelemetry = "0.19" → wrap App with RequestTracing.
   - tonic:     interceptor that propagates OTel context.
4. In main(), BEFORE the tokio runtime starts:
   - dotenvy::dotenv().ok();
   - Read ENV or ENVIRONMENT env var, default "development", set OTEL_RESOURCE_ATTRIBUTES accordingly.
   - Build OtlpExporter for all three signals (trace, metrics, logs) via env-var-based config (the SDK reads OTEL_EXPORTER_OTLP_* automatically — don't hardcode URLs).
   - Build TracerProvider with batch span processor on tokio runtime.
   - Build MeterProvider with periodic reader (60s interval).
   - Build LoggerProvider; wire opentelemetry_appender_tracing so tracing::info! events emit as OTel logs.
   - Initialize tracing_subscriber::Registry layered with tracing_opentelemetry::layer().with_tracer(tracer).
5. Register graceful shutdown calling provider.shutdown() on all three.

CONSTRAINTS:
- Use OTLP HTTP/protobuf, not gRPC.
- If opentelemetry or tracing-opentelemetry is already in Cargo.toml, STOP and ask me before modifying.
- Do not commit .env to git.

VERIFY:
Run cargo run, then give me a curl command for a known route in the app (detect the port — likely 8080/3000 — and a route from the code). Run the curl, then open https://app.telemtra.io/overview — traces, metrics, and logs should appear within 60 seconds.
// python

Python prompt

Auto-instruments Flask, Django, FastAPI, Starlette, aiohttp, Celery, SQLAlchemy, psycopg, redis, and more via the official opentelemetry-distro. Launches your app under opentelemetry-instrument so no source changes are needed.

prompt python
You are helping me instrument my Python application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Auth: x-api-key header.
- Required env vars in .env (loaded via python-dotenv or shell):
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<pyproject.toml / setup.py project name>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<ENV or "development">

GOAL:
1. Detect the package manager (pip, poetry, uv, pdm, pipenv) and the web framework (Flask, Django, FastAPI, Starlette, aiohttp). Install:
     opentelemetry-distro
     opentelemetry-exporter-otlp-proto-http
     python-dotenv (if not already used)
   Then run: opentelemetry-bootstrap --action=install
   This installs the matching instrumentation packages for libraries already in the project (Flask, requests, psycopg2, redis, sqlalchemy, etc.).
2. Add the env vars above to .env. Read them at process start.
3. Update the start command to launch under the auto-instrumentation wrapper:
     opentelemetry-instrument python app.py
   or, for Django:
     opentelemetry-instrument python manage.py runserver
   or, for FastAPI via uvicorn:
     opentelemetry-instrument uvicorn main:app --host 0.0.0.0 --port 8000
   For poetry/uv/pdm-managed projects, prepend the package manager's run command appropriately.
4. If the project has a Procfile, Dockerfile, or systemd unit, update the start command there too.

CONSTRAINTS:
- Use the official opentelemetry-* packages from PyPI.
- Use OTLP HTTP (http/protobuf), not gRPC.
- If opentelemetry-* is already in requirements/pyproject, STOP and ask me before modifying.
- Do not commit .env to git.

VERIFY:
Start the app under opentelemetry-instrument, then give me a curl command for a known route (detect the port — likely 5000/8000 — and an endpoint from the code). Run the curl, then open https://app.telemtra.io/overview — telemetry should appear within 60 seconds.
// go

Go prompt

Go has no autoload — instrumentation is wired explicitly in main(). The prompt sets up trace, metric, and log providers with OTLP HTTP exporters, then adds per-library middleware (otelhttp, otelgin, otelpgx) based on what your project uses.

prompt go
You are helping me instrument my Go application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Auth: x-api-key header.
- Required env vars in .env (loaded via godotenv or shell):
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<go.mod module's last path segment>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<ENV or "development">

GOAL:
1. Detect the HTTP framework / router from go.mod and imports: net/http (stdlib), gin, echo, fiber, chi, gorilla/mux, gRPC (tonic). Detect databases: pgx, database/sql + lib/pq, mongo-driver, go-redis.
2. Add modules via go get (latest stable):
     go.opentelemetry.io/otel
     go.opentelemetry.io/otel/sdk
     go.opentelemetry.io/otel/sdk/metric
     go.opentelemetry.io/otel/sdk/log
     go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
     go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
     go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
     go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
     github.com/joho/godotenv
   Plus per-library packages for detected frameworks:
     gin       → go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin
     echo      → go.opentelemetry.io/contrib/instrumentation/github.com/labstack/echo/otelecho
     pgx       → github.com/exaring/otelpgx
     database/sql → go.opentelemetry.io/contrib/instrumentation/database/sql/otelsql
     mongo     → go.opentelemetry.io/contrib/instrumentation/go.mongodb.org/mongo-driver/mongo/otelmongo
3. Create internal/telemetry/telemetry.go (or similar). Export a Setup(ctx) function that:
   - godotenv.Load()
   - Builds an otlptracehttp exporter (reads OTEL_EXPORTER_OTLP_* automatically).
   - Builds an otlpmetrichttp exporter; wraps in a periodic reader.
   - Builds an otlploghttp exporter.
   - Builds resource with semconv attributes.
   - Sets the global TracerProvider, MeterProvider, LoggerProvider.
   - Returns a shutdown() func that flushes all three.
4. In main(), call Setup(ctx) before starting the server, defer shutdown(ctx) for graceful exit.
5. Wrap HTTP handlers: stdlib → otelhttp.NewHandler; gin → router.Use(otelgin.Middleware(serviceName)); echo → e.Use(otelecho.Middleware(serviceName)).
6. Wrap database/sql connections via otelsql.Open or otelpgx.NewTracer for pgx.

CONSTRAINTS:
- Use OTLP HTTP, not gRPC.
- Use ONLY official go.opentelemetry.io/* and contrib packages where they exist; otelpgx is an accepted community alternative.
- If go.opentelemetry.io/otel is already in go.mod, STOP and ask me before modifying.
- Do not commit .env.

VERIFY:
Run go run . (or whatever the project's run command is), then give me a curl command for a known route (detect the port and an endpoint from the code). Run the curl, then open https://app.telemtra.io/overview — telemetry should appear within 60 seconds.
// .net

.NET prompt

For ASP.NET Core projects, wires OpenTelemetry via the standard builder.Services.AddOpenTelemetry() pattern. Auto-instruments ASP.NET Core, HttpClient, SqlClient, and the .NET runtime. Reads standard OTEL_EXPORTER_OTLP_* env vars.

prompt .net
You are helping me instrument my .NET / ASP.NET Core application with OpenTelemetry, sending telemetry to Telemtra (https://telemtra.io).

CONTEXT:
- Telemtra is OTLP-native. Endpoint: https://ingest.telemtra.io
- Auth: x-api-key header.
- Required env vars (set in appsettings.Development.json's Logging section, in launchSettings.json, in Docker env, or in a .env loaded via DotNetEnv):
    TELEMTRA_API_KEY=<my-key>
    OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS=x-api-key=${TELEMTRA_API_KEY}
    OTEL_SERVICE_NAME=<*.csproj AssemblyName or project name>
    OTEL_RESOURCE_ATTRIBUTES=deployment.environment=<ASPNETCORE_ENVIRONMENT or "Development">

GOAL:
1. Detect the project type from *.csproj (ASP.NET Core web app, Worker Service, Console). Add these NuGet packages via dotnet add package:
     OpenTelemetry
     OpenTelemetry.Extensions.Hosting
     OpenTelemetry.Exporter.OpenTelemetryProtocol
     OpenTelemetry.Instrumentation.AspNetCore      (web apps only)
     OpenTelemetry.Instrumentation.Http
     OpenTelemetry.Instrumentation.SqlClient        (if EF Core or System.Data.SqlClient is used)
     OpenTelemetry.Instrumentation.Runtime
     DotNetEnv                                       (only if loading from a .env file)
2. In Program.cs (minimal hosting model), add before builder.Build():
     builder.Services.AddOpenTelemetry()
       .ConfigureResource(r => r.AddService(serviceName: builder.Environment.ApplicationName))
       .WithTracing(t => t
         .AddAspNetCoreInstrumentation()
         .AddHttpClientInstrumentation()
         .AddSqlClientInstrumentation()       // if used
         .AddOtlpExporter())                  // reads OTEL_EXPORTER_OTLP_* env vars
       .WithMetrics(m => m
         .AddAspNetCoreInstrumentation()
         .AddHttpClientInstrumentation()
         .AddRuntimeInstrumentation()
         .AddOtlpExporter())
       .WithLogging(l => l
         .AddOtlpExporter());
3. If the project uses appsettings.json, add an "OpenTelemetry" section mirroring the env-var convention so devs can override per environment.
4. If a .env file is requested, add DotNetEnv.Env.Load() at the very top of Main / Program.cs.

CONSTRAINTS:
- Use OTLP HTTP (http/protobuf), not gRPC.
- Use ONLY official OpenTelemetry.* NuGet packages.
- If OpenTelemetry is already a PackageReference in the csproj, STOP and ask me before modifying.
- Do not commit .env or secret-bearing appsettings to git.

VERIFY:
Run dotnet run, then give me a curl command for a known route (detect the port from launchSettings.json — likely 5000/5001 — and an endpoint from a Controller or Minimal API mapping). Run the curl, then open https://app.telemtra.io/overview — telemetry should appear within 60 seconds.
// agent tips

How to paste, per agent.

All five agents below can handle these prompts. The mechanics differ slightly.

Claude Code

Run claude in your project root, paste the prompt at the chat, press enter.

Cursor

Open the project, press Cmd/Ctrl + L to open the chat, paste, press enter.

Cline

Open the Cline panel in VS Code, paste the prompt, send. Approve file edits as they appear.

Aider

Run aider in your project, paste the prompt at the > prompt, press enter.

Copilot Chat

Open the Copilot chat panel, use /workspace to anchor on your project, paste prompt.

// prefer to wire it yourself?

Manual quickstart is still here.

The original copy-paste-code quickstart with hand-written snippets for Python, Node.js, Go, Java, .NET, Kubernetes, and the Collector is one click away.

// faq

Questions.

Which AI coding agents does this work with?

Any agent that can read your codebase and edit files. Tested mental model with Claude Code, Cursor, Cline, Roo Cline, Aider, and Continue.dev. Copilot Chat works for the simpler stacks (Node, Python) but may need a follow-up nudge on Rust or .NET wiring.

Does my API key leak when I paste the prompt?

No. The prompt does not contain your key. It instructs the agent to read TELEMTRA_API_KEY from your local .env file at runtime. You add the key to .env once, then the prompt is safe to paste anywhere — chat history, screenshots, public gists.

What if my project already has OpenTelemetry installed?

The prompt explicitly tells the agent to STOP and ask you before modifying an existing setup. Nothing gets overwritten silently. You can review the agent's plan and approve or redirect.

Why OTLP HTTP instead of gRPC?

HTTP/protobuf works through every corporate firewall and proxy without extra config. gRPC is slightly more efficient but trips on TLS termination, ALPN, and HTTP/2 quirks. For first-run, HTTP wins. You can switch to gRPC later by changing OTEL_EXPORTER_OTLP_PROTOCOL.

Will this work for non-listed languages (Ruby, PHP, Java, Elixir)?

Yes — use the Generic prompt. A capable agent (Claude Code or Cursor) will detect the stack and install the right official OpenTelemetry SDK. The stack-specific prompts just produce slightly higher-quality output because they pre-bake framework wiring.