Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add pledgeandgrow/pledge-skills --skill opentelemetrygit clone --depth 1 https://github.com/pledgeandgrow/pledge-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pledgeandgrow/pledge-skills/opentelemetry)<a href="https://agentmods.dev/skills/pledgeandgrow/pledge-skills/opentelemetry"><img src="https://agentmods.dev/badge/skills/pledgeandgrow/pledge-skills/opentelemetry/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pledgeandgrow/pledge-skills/opentelemetry"><img src="https://agentmods.dev/badge/skills/pledgeandgrow/pledge-skills/opentelemetry.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00032 | $0.01406 |
| Opus 5 | $0.00016 | $0.00703 |
| Sonnet 5 | $0.00006 | $0.00281 |
| Haiku 4.5 | $0.00003 | $0.00141 |
Grade A, and why
opentelemetry-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
OpenTelemetry
Overview
OpenTelemetry (OTel) is a vendor-neutral, open-source observability framework for instrumenting, generating, collecting, and exporting telemetry data — traces, metrics, and logs. It is an industry standard supported by 90+ observability vendors, integrated by many libraries/services/apps, and adopted by numerous end users.
OpenTelemetry was created as a merger of OpenTracing and OpenCensus.
Key Principles
- You own the data you generate — no vendor lock-in
- Single set of APIs and conventions — learn once, use everywhere
Main Components
- Specification — cross-language requirements for all implementations (API, SDK, Data/OTLP, Semantic Conventions)
- OTLP Protocol — defines the shape of telemetry data transport (gRPC + HTTP/Protobuf)
- Semantic Conventions — standard naming scheme for common telemetry data types
- Language SDKs — implement the specification, APIs, and export of telemetry data (Go, .NET, Java, JavaScript, Python, PHP, Ruby, Rust, Swift, Kotlin, C++)
- Instrumentation Libraries — auto-instrument common libraries and frameworks
- Zero-code Instrumentation — generate telemetry without code changes (Go, .NET, Java, JavaScript, Python, PHP)
- OpenTelemetry Collector — vendor-agnostic proxy that receives, processes, and exports telemetry data
- OpenTelemetry Operator for Kubernetes — injects zero-code instrumentation, manages Collector deployments
- Helm Charts — Collector, Demo, Operator charts for Kubernetes
Signals
| Signal | Description |
|---|---|
| Traces | Path of a request through your application |
| Metrics | Measurements captured at runtime |
| Logs | Recordings of events |
| Baggage | Contextual information passed between signals |
| Profiles | Resource usage at code level (in development) |
Quick Reference
Core Concepts
- Observability — understanding internal state of a system from its outputs
- Context Propagation — mechanism that moves context between services/processes (W3C TraceContext default)
- Instrumentation — code emitting signals (code-based or zero-code)
- Resources — entity producing telemetry (service name, pod, container, etc.)
- Sampling — reducing telemetry volume while maintaining representativeness
What ships with it
9 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 102 lines · 32 tokens per session scan A d7a3fac6abc2
opentelemetry-docs is a skill published in the GitHub repository pledgeandgrow/pledge-skills (10 stars, last pushed 1mo ago), licensed MIT. It adds 32 tokens to every session and 1,406 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
opentelemetry
OpenTelemetry observability patterns: traces, metrics, logs, context propagation, OTLP export, Collector pipelines, and troubleshooting.
opentelemetry-net-instrumentation
Provides guidance for implementing OpenTelemetry instrumentation in .NET codebases, covering tracing (Activities/Spans), metrics, logs, naming conventions, error handling, performance, SDK setup, resources, context propagation, and API design best practices.
netdata-otel-setup
Use when enabling the Netdata otel.plugin, writing /etc/netdata/otel.yaml, defining metric-to-chart mappings, configuring TLS on the OTLP receiver, or debugging OTLP ingestion issues with Netdata. Covers OTLP gRPC ingestion for metrics (v2.7.0+) and logs (v2.9.0+). Traces are not yet supported.
frontmcp-observability
Use when adding tracing, structured logging, metrics, or monitoring to a FrontMCP server. Covers zero-config OpenTelemetry distributed tracing across all flows; the this.telemetry API for custom spans, events, and attributes in tools, plugins, agents, and skills; structured JSON logging with trace correlation and…
observability
Use when instrumenting a service from the inside so an incident can be explained from telemetry alone — wiring OpenTelemetry logs, metrics and traces, standing up a Collector, exporting via OTLP, and defining telemetry-driven alerts. NOT outside-in uptime probes, on-call rotation, or who-gets-paged (that is…
golang-observability-opentelemetry
Instrumenting Go applications with OpenTelemetry for distributed tracing, Prometheus for metrics, and structured logging with slog.