About the telemetry tables

What each sigiro_* table stores and how to query the machine that emitted the telemetry.

sigiro stores telemetry sent over OTLP. Every row describes the service and machine that emitted it; Sigiro does not expose live host information from the machine running the server.

Stored signals

• sigiro_spans — traces and span timing
• sigiro_logs — log records
• sigiro_metrics_gauge — point-in-time values
• sigiro_metrics_sum — monotonic and non-monotonic sums
• sigiro_metrics_histogram — explicit-bucket histograms
• sigiro_metrics_exp_histogram — exponential histograms
• sigiro_profiles — profile samples
• sigiro_anomalies — detected regime shifts

Metrics use four tables because OTLP defines four different metric shapes. Keeping them separate avoids null-heavy rows and write-time projections. Use UNION ALL when a query needs several metric types.

Ask about the right machine

Host CPU, memory, filesystem and network questions belong in the sigiro_metrics_* tables. The answer is about the machine that exported those metrics, not the machine running Sigiro.

SELECT service_name, metric_name, value, timestamp
FROM sigiro_metrics_gauge
WHERE service_name = 'checkout'
  AND metric_name LIKE 'system.filesystem%'
  AND timestamp >= TIMESTAMP '2026-09-12 00:00:00'
  AND timestamp <  TIMESTAMP '2026-09-13 00:00:00'
ORDER BY timestamp DESC;

An empty result means that service did not send matching host metrics. Fix the instrumentation rather than substituting data from another machine.

Query rule

Raw telemetry queries must include a finite half-open timestamp range: timestamp >= ... AND timestamp < ....

Read next

• About evidence instead of a dashboard
• Send telemetry to hosted sigiro