Signal coverage¶

Every metric and log event tailscale2otel emits is accounted for here. The table says what each signal is for — whether the shipped dashboard charts it, an alert rule watches it, a recording rule folds it, or it is deliberately query-only.

This page is generated from internal/catalog/signal_dispositions.json, a manifest that is itself gated in CI against three things: the in-code telemetry catalog (so a new signal cannot land undecided), the generated dashboard, and the two alert-rule files (so a visualized or alertable claim has to be true, in both directions). Nothing here comes from a text search over prose.

Regenerate with:

go test ./internal/catalog -run TestSignalDispositionsInSync -update
go test ./internal/catalog -run TestSignalCoverageDocInSync -update

Dispositions¶

A signal can carry several at once (most alerted metrics are also charted). All four are derived — read off the shipped artifacts by the regenerator — so there is nothing here for anyone to assign by hand, and no value that can be written to settle a signal that is not actually on a surface.

drives_a_variable is deliberately not visualized (#527). A presence sentinel's label_values() call references a metric every bit as really as a panel query does, and puts nothing on screen — so while both fed one value, a signal could satisfy the every-signal-reaches-a-panel bar while being invisible. tailscale.subnet_routes.advertised sat in exactly that state, covered only by the sentinel gating a row, and it stayed invisible until #526 deleted that row. tailscale.key.expiring was worse: it counted as covered because its name appears as an option value in a dropdown, which is not a query at all. Both have panels now.

Every emitted signal must appear on a panel, and #526 removed the last three ways round that. raw_only and omitted were deleted first: "deliberately query-only" is indistinguishable, from the outside, from "nobody got round to it", and 35 signals had accrued under the two of them. pending_panel replaced them as an explicitly transitional, shrink-only ledger — a signal could only ever leave it by gaining a panel — and was itself deleted the moment it emptied, which is the only reason it was safe to introduce.

The only exemptions now are three structural classes, each an individually justified entry in catalog.StructuralExemptions() and none of them a judgement about whether a signal is worth charting:

Operational and self-observability coverage are reported separately. They answer different questions ("can I see my tailnet?" versus "can I see the exporter?"), and a well-covered fleet story would otherwise hide a blind exporter.

The units, descriptions and attribute keys for every signal below are in metrics.md; this page only covers what each one is used for.

Summary¶

A signal can carry more than one disposition, so the columns do not sum to the total.

Operational signals¶

Self-observability signals¶