Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Trace each user-facing agent turn as one tree. The root is an invoke_agent span, each model request is a child inference span, and each tool execution is an execute_tool span under the turn that requested it. Every operation should carry metadata by default: names, identities, durations, finish reasons, token counts where the provider supplies them, and a stable error type on failure. Message bodies, tool arguments, and tool results stay out of production traces unless a specific debugging need, an access policy, and a retention limit all justify collecting them.
The trace shape for one agent turn
The operation your users experience is the agent invocation, so it should be the root of the trace. OpenTelemetry’s GenAI semantic conventions describe an invoke_agent operation for agent invocation and recommend execute_tool spans for tool execution. Model inference gets its own span. The parent-child links are what make the trace useful: they show which model request preceded a tool call, how long each step took, and where an error or retry occurred.
The OpenTelemetry project’s May 14, 2026 walkthrough demonstrates this layout: an invoke_agent parent with child chat spans and execute_tool spans beneath it.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute| Operation | Span name | Span kind | What the span covers |
|---|---|---|---|
| Agent invocation | invoke_agent {agent-name} |
INTERNAL for a local agent call; CLIENT for a remote agent invocation | The whole agent turn, from the user’s request to the final response |
| Model inference | chat spans, as named in the OpenTelemetry walkthrough |
Not stated in the GenAI conventions | One logical model call from request through response, including automatic retries that belong to that same call |
| Tool execution | execute_tool {tool-name} |
INTERNAL | One logical tool operation; child spans hold the downstream HTTP, RPC, database, or messaging work |
Keep span names low-cardinality. execute_tool search_orders groups well across thousands of turns. A name that embeds the user’s prompt or an order number creates a new span name for every request, which makes spans hard to aggregate. Put variable values in attributes instead.
#1 Best Overall
What every tool span should carry
- The operation name
execute_tooland a stable tool name ingen_ai.tool.name. - The tool call ID in
gen_ai.tool.call.idwhen the framework provides one. This is the link between the call the model requested and the execution that actually ran. - Tool type and agent name when available.
- Duration, measured from the span boundary, plus status and an
error.typewhen the call fails. - Child spans for the real downstream work (HTTP, RPC, database, messaging) when that instrumentation exists.
Application-owned tools and existing instrumentation
OpenTelemetry recommends that application developers follow the execute-tool convention for their own tools when automatic instrumentation does not reliably cover them. The reverse matters just as much: if existing instrumentation already captures a tool operation reliably, do not record a second equivalent span beside it. Duplicate spans double-count latency and errors on dashboards. MCP tool executions may already be covered by MCP instrumentation, so check that before adding manual spans for them.
Metadata to capture by default
Metadata answers the operational questions: which tool is slow or failing, whether the agent is looping between model and tool operations, which model handled a request, and whether token use moves with latency. The baseline set is:
- Operation name and span kind to show which step ran and how it was invoked.
- Tool name and tool type to find the slow or failing tool, grouped by a bounded name.
- Agent identity to tell which agent produced a turn when several share a service.
- Model and provider identity, where known, to see which model served the request.
- Finish reason to see why the model stopped generating.
- Input and output token counts, where the provider supplies them, to test whether token use tracks latency.
- Duration on every operation, to show where the time went.
- Error type on failure, so failures can be counted by class.
The official walkthrough example shows model identity, input and output token counts, and finish reasons on spans. Treat these as what the conventions allow, not a guarantee: SDKs and frameworks differ in which fields they emit, and not every provider returns token counts. Confirm the fields for your exact library version in a test environment before building a dashboard on them.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep content out of default production traces
Input and output messages, system instructions, retrieval text, tool arguments, and tool results are all flagged as potentially sensitive. The walkthrough’s example defaults to metadata for that reason. Decide which content tier each deployment falls into before writing the instrumentation, not after the first incident asks for prompt text.
Content that is never collected
This tier is the default for production. Message bodies, system instructions, retrieval text, and raw tool arguments and results are not written to spans, span events, or logs. The safe default is that the field does not exist in production telemetry at all, rather than being present and filtered later.
Content collected only in controlled environments
Staging and test environments that use synthetic or non-production data can record full content so engineers can reproduce problems. Keep the same instrumentation code and switch the content setting through environment configuration, so the trace shape you test is the trace shape you ship.
Rank #3
Content captured for a narrow production sample
Use this tier only when a specific debugging question cannot be answered from metadata. Limit it to a named tool or agent, a fixed time window, and a sample rate you choose. Turn it off once the question is answered.
If you enable content capture, work through these steps:
- Write down the debugging question that metadata cannot answer, and the exact fields it needs.
- Gate capture behind an explicit opt-in setting that is off by default.
- Filter or truncate the content before it is attached to the span, so oversized values are cut at the source.
- Restrict who can query the trace backend for those spans.
- Set a retention period for content-bearing telemetry and document it in your data policy.
- Consider redacting identifiers before export, not only inside the backend.
Two traps catch teams. Moving a raw payload into a span event or a log does not make it safer: it is still telemetry and needs the same governance. And never put user identity, raw prompts, or other unbounded values into metric dimensions. Use low-cardinality fields for aggregation, and the trace ID to navigate from an aggregate to one specific trace.
Spans, events, attributes, and metrics
Use a span for any operation with a duration and a meaningful boundary: agent invocation, model inference, and tool execution. Put properties of the whole operation in span attributes, especially those you need at span start for sampling decisions. Use span events for timestamped occurrences inside a longer operation, such as a retry, a fallback, a state transition, or a checkpoint, particularly when each occurrence needs its own timestamp and its own fields. OpenTelemetry’s event conventions separate these named occurrences from operation-wide attributes and recommend structured, queryable event attributes.
Pair traces with aggregate metrics. The following are editorial suggestions rather than fixed instrument names; what is available depends on your SDK and framework.
- Agent-turn latency.
- Model-call latency.
- Tool latency and error rate, grouped by bounded tool name.
- Failure counts by error type.
- Token usage, where the provider supplies it.
Errors, retries, and gaps in coverage
Record a failure on the operation that failed, and classify it with a stable error.type where possible. Keep transport failures distinct from domain-level failures: a tool call can complete at the protocol level and still report that the work did not succeed. The failure should appear on the tool span itself, not only on the agent turn, so that a dashboard can separate the two cases.
Best Value
Preserve the causal path: agent operation, then model request, then tool execution, then downstream dependency. Record a retry or fallback as an event when it only needs a timestamp and a reason, or as a child operation when it has its own latency and outcome worth measuring. The GenAI conventions defer status semantics to OpenTelemetry’s error-recording guidance, so follow the SDK guidance for your language and test that tool-level errors appear on the correct span.
Make tool coverage explicit
An absent tool span looks exactly like an agent that did nothing. Keep a short inventory listing each tool the agent can call, whether automatic instrumentation covers it, and whether a manual execute_tool span is in place. Review the inventory whenever a tool is added or changed.
Troubleshooting a trace that looks wrong
| Symptom | Likely cause | What to check |
|---|---|---|
| Model calls appear, but a tool’s work never shows as a tool span | The tool is application-owned and has no manual span | Whether the tool appears in your coverage inventory; add an execute_tool span following the convention |
| One tool call appears twice | A manual span duplicates one from automatic instrumentation | Which library produces each span; remove the redundant one |
| Tool spans cannot be grouped by name | Span names contain arguments, user input, or IDs | Rename to execute_tool {tool-name} and move the variable value into an attribute |
| A field such as token usage is missing on some model spans | The SDK or framework version does not emit that field for that provider | The attributes emitted in a test run for the exact version you deploy |
| Content text appears in a backend configured as metadata-only | A payload was attached to a span event or a log record, or an exporter lacks redaction | Span events and log records, not only span attributes; collector and exporter configuration |
| Attribute names changed after an upgrade | The GenAI conventions are still marked Development | Diff emitted attributes against the previous version; check that your pinned versions match |
Versioning and stability
The GenAI semantic conventions are still marked Development in the project’s repository. Pin the SDK, framework, and semantic-convention versions you deploy, and keep a document listing the attributes you emit. Review schema changes during every upgrade, because frameworks and exporters do not all implement the conventions in the same way.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Roll out in three stages
- Metadata only. Validate the trace topology: one
invoke_agentroot per turn,chatandexecute_toolchildren in the right order, and errors on the right span. Confirm that every tool in your inventory produces exactly one span. - Pipeline controls. Before volume grows, validate the collector and exporter: backend access policy, retention period, and expected telemetry volume. OpenTelemetry’s security guidance warns that telemetry can include PII, application data, and network patterns, so protect it against disclosure, tampering, and denial of service.
- Scoped content capture, only if needed. Enable payload capture for the narrow case defined in your data policy, and only after the first two stages hold.
Where the traces go
Any OTLP-compatible observability backend can receive GenAI telemetry, so the trace model in this article does not depend on one vendor. Access control, retention, and redaction features do vary between backends, and they need to be verified before you send any content-bearing data to one.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
