Telemetry Types
InfraSage supports six telemetry types. The type you send decides which fields are required, where the record is stored, and how it gets analyzed.
Type reference
| Type | value required | body required | trace_id supported | Typical use |
|---|---|---|---|---|
metric | Yes | No | No | CPU %, latency, throughput, error rate |
log | No | Yes | No | Application log lines |
trace | Yes | No | Yes | Distributed tracing, span durations |
event | No | Yes | No | Kubernetes events, deployments, alerts |
profile | Yes | Yes | No | CPU/memory profiling snapshots |
slo | Yes | No | No | SLI measurements for SLO tracking |
If type is omitted, it defaults to metric.
metric
Numeric time-series data, and by far the most common type. Use it for infrastructure metrics, application KPIs, and your own business metrics.
{
"service_id": "api-gateway",
"type": "metric",
"metric_name": "request_latency_p99_ms",
"value": 342.1,
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"region": "us-east-1",
"method": "POST",
"path": "/api/v1/checkout"
}
}
Anomaly detection is active for metric records. The Watchdog monitors each (service_id, metric_name) pair independently and keeps a sliding window of historical values to compute Z-scores from.
log
Textual log entries. The text goes in body, and no numeric value is required.
{
"service_id": "auth-service",
"type": "log",
"body": "Login failed: invalid credentials for user u-12345",
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"level": "warn",
"user_id": "u-12345",
"ip": "203.0.113.42"
}
}
Logs are stored in ClickHouse and can be queried via the Admin UI or directly through ClickHouse SQL. They are also correlated with metrics and traces during RCA.
trace
Distributed trace spans. Requires a trace_id to link spans across services.
{
"service_id": "checkout-service",
"type": "trace",
"metric_name": "checkout.handle_payment",
"value": 0.342,
"trace_id": "abc123def4567890",
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"span_id": "span-001",
"parent_span_id": "span-root",
"status": "ok"
}
}
Trace data is stored in infrasage_exemplars (high-cardinality store) and linked back to metric anomalies for root cause analysis.
event
Discrete occurrences with no continuous numeric value: deployments, Kubernetes events, feature flag changes.
{
"service_id": "k8s-cluster",
"type": "event",
"body": "Pod checkout-api-7f9d4b crashed with OOMKilled",
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"kind": "Pod",
"namespace": "production",
"reason": "OOMKilled",
"count": "3"
}
}
Events are correlated with anomalies during RCA. If a pod crash event precedes a latency spike, Claude surfaces this in its root-cause explanation.
profile
Profiling snapshots with both a numeric summary and raw body data.
{
"service_id": "payment-service",
"type": "profile",
"metric_name": "cpu_flame_graph_sample_count",
"value": 4200,
"body": "... base64-encoded pprof data ...",
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"profile_type": "cpu",
"duration_ms": "5000"
}
}
slo
Service Level Objective measurements. Track SLI compliance over time.
{
"service_id": "api-gateway",
"type": "slo",
"metric_name": "availability_percent",
"value": 99.97,
"timestamp": "2026-04-10T12:00:00Z",
"attributes": {
"slo_name": "API Availability",
"target": "99.9",
"window": "30d"
}
}
SLO records are stored in infrasage_slo and tracked separately from general metrics to avoid polluting anomaly detection baselines with intentional threshold measurements.
Custom attributes
Every telemetry type accepts arbitrary key-value attributes. They go into a JSON column in ClickHouse and are indexed for fast filtering.
Two habits worth keeping: use dot-separated namespaces such as aws.region, k8s.namespace, and app.version, and keep cardinality down by leaving user IDs and request IDs out of attribute keys. Attributes travel with the RCA context that is sent to Claude.
Listing supported types via API
curl $INFRASAGE_URL/api/v1/telemetry-types
{
"types": ["metric", "log", "trace", "event", "profile", "slo"],
"default": "metric"
}