# 16.8 Watching it run: telemetry (/building-ai-workers/skills-and-plugins/watching-it-run)

---
type: Document
title: "16.8 Watching it run: telemetry"
description: "Taught through OpenTelemetry: traces, spans, metrics and log events, what each part of a plugin can report, trace context into a connector, and two limits. Telemetry does not reach inside code that is not instrumented, and it shows that work ran, never that it was right."
status: stable
order: 316.08
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-02T19:44:48Z
chapter: "16"
part: III
expert_status: co-build
concepts: [ "16.8" ]
last_verified: 2026-11-02
generated:
  at: 2026-11-02T19:44:48Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** A delivery company tracks every package. The scan at each stop says where the package was and when. A late truck shows up as a long gap between two scans. But the tracking never tells you whether the right item is inside the box. Only opening it does.

**What you will learn.** How to see a plugin at work: which steps ran, how long they took and what they cost. What that data cannot show. What must stay out of it.

**Why it matters.** People need to watch software they cannot sit beside, so you must know what this evidence proves, and what it does not.

### What is telemetry?

**Telemetry** is data that running software sends about what it did, so people can watch it without sitting beside it. A plugin packages abilities, and telemetry is how you see them run. **OpenTelemetry** (opentelemetry.io, checked November 2, 2026) is the open standard for it, not tied to any one company. A product that follows it can send its data to any **collector**, a service that receives telemetry, and any tool can read it.

### What does it send?

Three main kinds of signal:

| Signal | What it is | Example for the triage skill |
| --- | --- | --- |
| **Trace**, made of **spans** | One request from start to finish. A span is one timed step inside it, and one span can sit inside another | The request, the skill's turn, a connector call, the script run |
| **Metric** | A number measured over time | Tokens used, estimated cost in USD, calls per hour |
| **Log event** | A record that something happened, at a moment | The plugin loaded, a skill was used, a tool was denied |

Each signal carries **attributes**, name and value pairs such as a skill's name. An **exporter** sends the signals, to a collector or simply to the console, which means your terminal. A host that exports telemetry can report when a plugin loaded and which skill ran. It can also report each model request with its tokens and estimated cost, each connector call, and each tool it allowed or denied. A host may also export the plugin version it loaded, though most do not. Products differ in how much they export ([16.10](both-ai-vendors.md)).

### Can one trace cross programs?

Yes, if both sides take part. OpenTelemetry's **semantic conventions** are shared names for the same things, so every product's data reads the same way. Its conventions for MCP, the standard for connectors, are at **Development** status, so the names may still change. They also say how a connector call joins the agent's trace. The agent passes **trace context**, a small identifier, inside each connector request. A connector that reads it adds its own spans under the agent's. [16.10](both-ai-vendors.md) lists the names.

### What can the host not see?

What happens inside a program. The host can time a connector call or a script, but it cannot see inside, such as which rule each invoice matched. Only code you own can add spans of its own. Brightline's connector is ready-made, so in this chapter it is seen only from outside. Chapter 17's connector is yours, and you instrument it there, which means you add code that sends its own telemetry.

### Does a clean trace mean the answer is right?

No. Telemetry shows that work ran, never that it was right. A trace can show a skill that ran fast, cost little and had no errors, and still printed a wrong total. Correctness comes from tests and evaluations ([16.3](writing-a-skill-with-the-expert.md), [16.6](shipping-a-version.md)).

### What must stay out of it?

Prompts, replies and tool content, which can hold customer names, amounts and bank details. Most products leave them out of telemetry unless you turn each one on. Leave them off, and send telemetry only to a collector your organization controls.

**At work.** The builder turns on one product's telemetry for one session, sends it to the console, and runs the Monday report. The log events show the plugin loading and a skill being used, and the cost records show the run's tokens and cost. The product hides the skill and plugin names until the builder asks for them. `NOTES.md` says that the evidence for the counts 4, 2, 2 and 5 is the test.

**The operating rule:** export telemetry to the open standard so any tool can read it. Keep sensitive content out of it, and instrument the code you own. Never take a clean trace as proof of a right answer.

![One run drawn as a trace. At the top, the request, the outer span. Below it, the skill's turn, invoice-triage. Below that, three spans: a model request with tokens and cost, a connector call, list_directory, and a script run, 3.1 seconds. A dashed note says inside: not instrumented. An arrow along the bottom shows time. Beside the trace, a separate box: test result, 4 2 2 5, pass. A note says the trace shows what ran, the test shows it was right.](img/trace.png)

*Figure 16.12. One triage run as a trace. The host times what it can see. Only the test says the answer is right.*

**Practice it.** [Practice: watching it run](both-ai-vendors.md#practice-watching-it-run), in your own tool, ten minutes.