otel-instrument

Add OpenTelemetry tracing and metrics to applications via SDK and auto-instrumentation.

12|8|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/signalfx/obstudio --skill otel-instrument-signalfx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: otel-instrument
Source: https://github.com/signalfx/obstudio/tree/main/skills/otel-instrument
Command: npx skills add https://github.com/signalfx/obstudio --skill otel-instrument-signalfx

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It removes the guesswork of how to add OpenTelemetry observability by guiding you through safe, evidence-based instrumentation that preserves the app’s existing runtime shape.

Core Features & Use Cases

  • Preflight, evidence-first setup: identifies the correct language/framework, the real process start surface, service.name and environment sources, and whether OTel SDK is already initialized.
  • Auto-instrumentation first: wires official OTel SDK and the appropriate auto-instrumentation libraries so HTTP/server spans and related telemetry appear without large refactors.
  • Targeted custom instrumentation: adds only the custom spans/metrics requested after auto-instrumentation is confirmed, with explicit error-status behavior for APM backends.
  • Validation-ready defaults: ensures HTTP duration metrics are emitted (e.g., via the recommended HTTP server wrapping) and that OTLP export is configurable via standard environment variables.

Quick Start

Tell the assistant: “Instrument this service with OpenTelemetry for tracing and metrics, using auto-instrumentation, and add one custom span for the business operation that handles payments.”

Frequently Asked Questions about otel-instrument

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add OpenTelemetry tracing and metrics to an existing application?

You can add OpenTelemetry tracing and metrics by applying official SDK auto-instrumentation to your existing application entrypoint, which generates HTTP server spans and request-duration metrics without requiring large code refactors.

What is the best way to avoid duplicate OpenTelemetry SDK initialization when instrumenting a service?

To avoid duplicate OpenTelemetry SDK initialization, perform an evidence-first preflight check to detect existing SDK initialization, then safely apply auto-instrumentation that reuses the existing runtime entrypoint instead of creating a new one.

Can I add custom OpenTelemetry spans for specific business operations after using auto-instrumentation?

Yes, you can add custom OpenTelemetry spans for specific business operations after auto-instrumentation is confirmed, applying explicit error-status behavior so APM backends can accurately track targeted business signals.

Does OpenTelemetry auto-instrumentation support Python, Node.js, Java, and Go services?

Yes, OpenTelemetry auto-instrumentation supports Python, Node.js, Java, and Go services by applying the appropriate language-specific official SDKs and libraries to automatically wire up tracing and HTTP server telemetry.

How do I configure OTLP export and service identity for OpenTelemetry instrumentation?

You configure OTLP export and service identity for OpenTelemetry instrumentation by setting standard environment variables, ensuring the service.name and export endpoints are defined without hardcoding values into the application logic.

Why are HTTP request-duration metrics not showing up after adding OpenTelemetry tracing?

HTTP request-duration metrics may not appear if the OpenTelemetry setup lacks the recommended HTTP server wrapping, which is required to ensure HTTP server telemetry includes validation-ready request-duration metrics alongside traces.