mirror of
https://github.com/hanzoai/o11y.git
synced 2026-10-15 12:58:33 +00:00
zeekay
c3dc2f1ecf
HIP-0132 unified o11y_logs, o11y_traces and o11y_metrics into one `event`
database and dropped them. The commit that restored the reads repointed
three files and said so; it was thirty. The rest went on naming databases
that no longer exist, so trace funnels, the Kafka and queue panels, the
v3/v4 logs and traces builders and the PromQL adapter each answered
Code: 81 UNKNOWN_DATABASE, and the golden tests agreed with them because
they pinned the same dead SQL.
pkg/telemetryplane is the one address for the name, imports nothing, and
is reachable from every depth that needs it. Its test walks the tree and
fails the build on a literal that names a dropped database, tests
included — a golden encoding broken SQL is a second vote for the bug, not
coverage.
Two service views turned a failed read into an offer to instrument an
already-instrumented application. A failure now shows the failure, and
onboarding is offered on a successful empty read.
Cherry-picked from salvage/blue-wt-o11y-readers 83ecbec03c.
41 lines
1.8 KiB
Go
41 lines
1.8 KiB
Go
package telemetrytraces
|
|
|
|
import "github.com/hanzoai/o11y/pkg/telemetryplane"
|
|
|
|
// Spans live in the ONE event database beside the other signals, as event.span:
|
|
// singular, because a row is one span. It carries the same 15-column envelope as
|
|
// event.event / event.error / event.log, so correlating a span with an error is a
|
|
// UNION ALL rather than a translation layer, and org is the FIRST column of the sort
|
|
// key rather than a map lookup — spans are tenant-scopable by construction.
|
|
//
|
|
// There are no Distributed wrappers on this deployment, so the distributed and local
|
|
// name of a table are the same string. The pair is kept because the query builders
|
|
// distinguish the two roles.
|
|
const (
|
|
DBName = telemetryplane.DBName
|
|
|
|
SpanTableName = "span"
|
|
SpanLocalTableName = "span"
|
|
)
|
|
|
|
// The names below are NOT part of the applied event schema, which holds event, error,
|
|
// log, span and the metric tables and nothing else. They name the supporting tables
|
|
// the trace query plane reads — attribute autocomplete, resource fingerprints,
|
|
// service-operation rollups — under the one naming scheme, so those paths land in the
|
|
// event plane the day the tables are added rather than carrying a second scheme.
|
|
// Until then a query through them fails on a missing table, which is the honest
|
|
// outcome.
|
|
//
|
|
// The scheme: a table that SUPPORTS a signal is prefixed by that signal, which is what
|
|
// keeps span_attribute and log_attribute apart now that both planes share one database.
|
|
const (
|
|
SpanAttributeTableName = "span_attribute"
|
|
SpanAttributeLocalTableName = "span_attribute"
|
|
SpanKeyTableName = "span_key"
|
|
SpanResourceTableName = "span_resource"
|
|
|
|
// operation is one (service, operation) pair; trace is one whole trace's summary.
|
|
OperationTableName = "operation"
|
|
TraceTableName = "trace"
|
|
)
|