Skip to content

Tool Runtime Observability & Operations

Document ID: TRT-006
File Path: docs/07-tool-runtime/observability-ops.md
Version: 1.0.0
Status: Draft
Owner: AI Platform Team
Last Updated: 2026-06-27


This document defines how the Tool Runtime is observed and operated: the logs, metrics, traces, and audit it emits; its health surfaces; its service-level objectives; and the runbooks for common operational situations.

It complements the framework’s audit, metrics, tracing, and health sections with the operational view of the running service.


SignalExamples
LogsStructured, correlation-ID tagged, per execution stage
MetricsQueue time, start latency, run duration, success/error rate, resource use, warm-pool hit ratio
TracesOpenTelemetry spans: dispatch → authorize → schedule → sandbox → execute
AuditPer-execution tamper-evident record (see Security §11)
Eventstool.execution.* published to the Event Bus

All signals carry tenant, tool, version, and execution_id for correlation.


# Throughput / latency
tool_executions_total{tool,version,status}
tool_queue_seconds{pool} (histogram)
tool_start_latency_seconds{backend} (histogram)
tool_duration_seconds{tool} (histogram)
# Resources
tool_cpu_ms{tool}
tool_peak_memory_bytes{tool}
tool_egress_bytes{tenant}
# Fleet
worker_utilization{pool}
warm_pool_hit_ratio{backend}
sandbox_provision_failures_total{backend}
# Safety
authorization_denied_total{reason}
resource_exceeded_total{resource}
sandbox_killed_total{cause}

A single execution produces one trace spanning the control and data planes:

span: execution
├─ dispatch (resolve tool/version)
├─ authorize (policy)
├─ schedule (worker selection + queue wait)
├─ sandbox.provision (backend, warm/cold)
├─ execute (tool run)
└─ teardown (destroy + reclaim)

Traces propagate the caller’s correlation_id so a tool execution links back to the originating agent goal or workflow step.


EndpointMeaning
/healthzProcess liveness
/readyzReady to accept work (registry reachable, ≥1 worker pool healthy)
/metricsPrometheus metrics

Workers additionally report capability, capacity, and load to the scheduler via heartbeat (see Worker Pool §10).


SLOTarget
Control-plane availability99.99%
Interactive start latency (warm)p95 < 20 ms
Queue wait (healthy fleet)p95 < 50 ms
Execution success rate (excl. tool_error)> 99.9%
Cross-tenant isolation violations0

Error-budget burn on these SLOs drives alerting and scale decisions.


AlertCondition
High queue waittool_queue_seconds p95 > SLO for 5m
Provision failuressandbox_provision_failures_total rate spike
Elevated kills`sandbox_killed_total{cause=oom
Authorization spikeauthorization_denied_total anomalous (possible misconfig/abuse)
Egress anomalyper-tenant tool_egress_bytes exceeds baseline
Warm-pool starvationwarm_pool_hit_ratio < threshold

  • Per-tenant execution counts, durations, and resource usage feed showback/chargeback.
  • Cost events publish to the Event Bus and roll up in the dashboard alongside LLM Gateway cost and Memory Engine usage.
  • Warm-pool sizing is tuned to balance start-latency SLOs against idle cost.

SituationAction
Queue backing upVerify autoscaler; check for a hot tool/tenant; raise pool min
A tool failing widelyInspect traces/audit; pin/rollback tool version in registry
Sandbox escape suspicionQuarantine pool; force microVM floor; rotate node images
Worker node unhealthyDrain and recycle; reschedule idempotent in-flight work
Secret leak suspectedRotate affected secret refs; audit secrets_used; revoke grants
Cost spikeIdentify tenant/tool via metrics; apply rate limit/quota

  • Tool version pinning / rollback via the registry without redeploying the Runtime.
  • Quarantine a tool or worker pool to stop execution immediately.
  • Drain workers for maintenance with no dropped in-flight work.
  • Rate-limit / quota adjustments per tenant/tool applied live.



VersionDateDescription
1.0.02026-06-27Initial Tool Runtime Observability & Operations specification