Skip to main content

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

Typevalue requiredbody requiredtrace_id supportedTypical use
metricYesNoNoCPU %, latency, throughput, error rate
logNoYesNoApplication log lines
traceYesNoYesDistributed tracing, span durations
eventNoYesNoKubernetes events, deployments, alerts
profileYesYesNoCPU/memory profiling snapshots
sloYesNoNoSLI 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"
}