Send and verify events with Semantic Kernel agent telemetry
Use Semantic Kernel agent telemetry where your app knows the final result. Collect only the fields you need, then verify a test event before building charts.
- 1
Choose the outcome
Semantic Kernel agent monitoring
- 2
Define the contract
operation_id, workflow, plugin_name, function_name, agent_name, model_alias, and release
- 3
Log the final result
Wrap Kernel.InvokeAsync or the agent call. Emit one final application outcome after it completes.
- 4
Check the stored event
Exercise a known fixture, then inspect agent_run_completed for one correctly typed terminal row.
Before you start
Before you start
- Semantic Kernel configured in a trusted .NET service
- A shared Telemetry Log API wrapper with a short timeout and server-side key
- Stable plugin, function, agent, model, workflow, and release names
Delivery setup
Install and initialize server-side
Use one shared HttpClient with a server-side key, a short timeout, and a small allowlisted Log API wrapper. Keep ingestion credentials out of browser bundles, client-visible environment variables, source control, logs, and exception messages.
- 1Create one reusable server-side client. Set its timeout and retry limit.
- 2Log an event when the operation succeeds, fails, retries, or times out.
- 3Send test events with known results and inspect the stored rows before enabling an alert.
Snippet
Start with one structured event
Add this shape where the workflow completes, fails, or retries. Then build the dashboard from real fields.
Semantic Kernel agent telemetry event
var startedAt = Stopwatch.GetTimestamp();
var status = "success";
string? errorType = null;
try
{
return await kernel.InvokeAsync(
"SupportPlugin",
"ResolveCase",
arguments,
cancellationToken
);
}
catch (Exception error)
{
status = "failed";
errorType = ClassifyAgentError(error);
throw;
}
finally
{
await telemetry.LogAsync("agent_run_completed", new
{
operation_id = operationId,
workflow = "support_resolution",
plugin_name = "SupportPlugin",
function_name = "ResolveCase",
status,
error_type = errorType,
duration_ms = Stopwatch.GetElapsedTime(startedAt).TotalMilliseconds,
release = appRelease,
}, cancellationToken);
}Event schema
operation_id, workflow, plugin_name, function_name, agent_name, model_alias, and release
status, duration_ms, tool_call_count, retry_count, human_handoff, and error_type
input_tokens, output_tokens, estimated_cost_usd, accepted, and environment when approved
Check your setup
Checkpoint 1
Wrap Kernel.InvokeAsync or the agent call. Emit one final application outcome after it completes.
Checkpoint 2
Semantic Kernel emits OpenTelemetry-compatible logs, metrics, and traces. Keep detailed spans in that backend instead of copying all span attributes into Telemetry.
Checkpoint 3
Do not send prompts, chat history, function arguments, function results, tool payloads, model content, credentials, or unrestricted exception messages.
Verification
Prove the event arrived
Run this after exercising known success and failure cases. Replace the fallback table name if your final event contract differs from the snippet.
Semantic Kernel agent telemetry verification query
SELECT *
FROM agent_run_completed
ORDER BY timestamp_utc DESC
LIMIT 20;Implementation references
Review the event contract, data-safety guidance, and upstream primary documentation before enabling a new production path.
Where to log
Keep the outcome event small and recoverable
This pattern provides
- Record the outcome as an event you can query with SQL.
- Stable fields for dashboards, alerts, and cross-event correlation.
- Test events for checking success, failure, retries, and timeouts.
This pattern does not provide
- An OTLP exporter, automatic collection pipeline, or replacement for detailed traces and diagnostic logs.
- Exactly-once delivery merely because the payload contains an event ID.
- Permission to collect raw provider payloads, user content, credentials, or regulated data.
Example event schemas
Event schemas for this workflow
Check what each event records, when to send it, and which field types it needs. Review the example payload and privacy checklist before using it in production.
Use these queries in Telemetry
Learn about AI agent monitoring
Query agent events to compare tool use, model costs, and outcomes for each run.
Related SQL recipes
More SQL recipes
Run the query using this workflow's event fields and check the example result. Save the result to a dashboard or set up an alert.
Reconstruct a correlated workflow timeline
What happened, in order, during the latest failed workflow?
Open recipeQuery nested AI tool-call events
Which AI tools and arguments are associated with the most failed calls?
Open recipeMeasure LLM time to first token
Which model and feature combinations feel slow before output begins?
Open recipeMeasure accepted AI outputs per dollar
Which model and feature combination produces the most accepted outputs per dollar?
Open recipeBrowse by implementation family
Compare related integration patterns
Templates to pair with this integration
AI agent observability template
Track agent runs, tool calls, retries, latency, errors, and accepted outputs in event tables you can query with SQL.
Open templateAI agent security audit template
Record tool authorization decisions, policy versions, human approvals, and final outcomes. Use selected event fields to keep sensitive payloads out.
Open templateLLM cost tracker
Measure model spend, token usage, latency, failures, and accepted outputs by feature, user, and account.
Open templateMore integrations
OpenAI agent telemetry
Log OpenAI agent runs, tool calls, model usage, latency, cost, and final outcomes with structured events.
Open guideCrewAI workflow telemetry
Track CrewAI crew and flow outcomes, task counts, handoffs, retries, latency, cost, and accepted results without retaining agent conversations.
Open guideClaude Agent SDK telemetry
Track Claude Agent SDK run outcomes, duration, tool activity, turns, cost, and approved product signals without storing prompts or tool payloads.
Open guide