Summary
librefang_tool_execution_seconds (added in #6228 / #6233) is the per-tool latency histogram, but it carries only a tool label — no agent dimension:
// crates/librefang-runtime/src/agent_loop/tool_call.rs (record_tool_call_metric)
if let Some(ms) = execution_ms {
metrics::histogram!(
"librefang_tool_execution_seconds",
"tool" => tool, // <-- only label
)
.record(ms as f64 / 1000.0);
}
The sibling counter emitted from the same function already carries agent:
metrics::counter!(
"librefang_tool_call_total",
"agent" => sanitize_tool_label(agent_id),
"tool" => tool.clone(),
...
);
So you can attribute a tool failure to an agent (tool_call_total{agent,tool}, added in #6226), but you cannot attribute a tool latency to an agent. On a host running many agents that share tools, the per-tool p95 is an unweighted blend across every caller — a slow agent and a fast agent on the same tool are indistinguishable.
Proposal
Add the agent label to the histogram, sourced from the agent_id already in scope in record_tool_call_metric:
metrics::histogram!(
"librefang_tool_execution_seconds",
"agent" => sanitize_tool_label(agent_id),
"tool" => tool,
)
.record(ms as f64 / 1000.0);
Cardinality stays bounded — same (agent × tool) product already accepted for librefang_tool_call_total, both labels sanitized/capped.
Secondary: agent label value is inconsistent across the agent-telemetry counters
While adding the label, please make it match the value scheme the other counters use, because right now the three agent-scoped counters disagree on what agent even means:
| Metric |
agent value |
Site |
agent_loop_exits_total |
manifest name |
agent_loop/mod.rs (record_agent_loop_exit, agent_label = manifest.name) |
cron_fires_total |
agent UUID (AgentId) |
kernel/src/cron.rs (record_cron_fire_metric) |
tool_call_total |
agent UUID (session.agent_id) |
agent_loop/tool_call.rs |
Because agent_loop_exits_total keys on the human name while the other two key on the UUID, a dashboard cannot join loop-exit data to tool-call/cron data on agent, and a single agent can appear under two identities across panels.
Suggested fix: standardize agent to the UUID everywhere (stable; names can change or collide, and hands share names), so the new histogram should use the UUID too. Optionally add a separate low-cardinality agent_name label across all four metrics for human-readable grouping — the join key stays the UUID, the display label is the name.
Acceptance
librefang_tool_execution_seconds carries an agent label, enabling per-agent latency p50/p95/p99.
- The
agent label value scheme is consistent across tool_call_total, tool_execution_seconds, agent_loop_exits_total, and cron_fires_total (or an agent_name companion label is added so a stable join key exists).
Notes
Direct follow-up to #6226 (agent dimension on tool_call_total) and #6228 (the histogram). Same dispatch path; the fix is a one-line label add plus aligning record_agent_loop_exit's identifier.
Summary
librefang_tool_execution_seconds(added in #6228 / #6233) is the per-tool latency histogram, but it carries only atoollabel — noagentdimension:The sibling counter emitted from the same function already carries
agent:So you can attribute a tool failure to an agent (
tool_call_total{agent,tool}, added in #6226), but you cannot attribute a tool latency to an agent. On a host running many agents that share tools, the per-tool p95 is an unweighted blend across every caller — a slow agent and a fast agent on the same tool are indistinguishable.Proposal
Add the
agentlabel to the histogram, sourced from theagent_idalready in scope inrecord_tool_call_metric:Cardinality stays bounded — same
(agent × tool)product already accepted forlibrefang_tool_call_total, both labels sanitized/capped.Secondary:
agentlabel value is inconsistent across the agent-telemetry countersWhile adding the label, please make it match the value scheme the other counters use, because right now the three agent-scoped counters disagree on what
agenteven means:agentvalueagent_loop_exits_totalagent_loop/mod.rs(record_agent_loop_exit,agent_label = manifest.name)cron_fires_totalAgentId)kernel/src/cron.rs(record_cron_fire_metric)tool_call_totalsession.agent_id)agent_loop/tool_call.rsBecause
agent_loop_exits_totalkeys on the human name while the other two key on the UUID, a dashboard cannot join loop-exit data to tool-call/cron data onagent, and a single agent can appear under two identities across panels.Suggested fix: standardize
agentto the UUID everywhere (stable; names can change or collide, and hands share names), so the new histogram should use the UUID too. Optionally add a separate low-cardinalityagent_namelabel across all four metrics for human-readable grouping — the join key stays the UUID, the display label is the name.Acceptance
librefang_tool_execution_secondscarries anagentlabel, enabling per-agent latency p50/p95/p99.agentlabel value scheme is consistent acrosstool_call_total,tool_execution_seconds,agent_loop_exits_total, andcron_fires_total(or anagent_namecompanion label is added so a stable join key exists).Notes
Direct follow-up to #6226 (agent dimension on
tool_call_total) and #6228 (the histogram). Same dispatch path; the fix is a one-line label add plus aligningrecord_agent_loop_exit's identifier.