Observability Platform  ·  View 13 of 25  ·  Data

Data Model

Nine entities: the telemetry, the owners who pay for it, and the record of what the platform refused.

Editable source SVG draw.io All views
team team_id PK name series_budget retention_class cost_centre service service_id PK team_id FK -> team environment region log_classes sampling_policy metric_series series_id PK service_id FK -> service metric_name label_set_hash first_seen last_seen exemplar series_id FK -> metric_series ts value trace_id FK -> trace usage_ledger day PK team_id FK -> team signal bytes_ingested active_series queries cost enforcement_event event_id PK service_id FK -> service kind attribute records_affected ts trace trace_id PK root_service_id FK duration_ms status keep_reason effective_rate span span_id PK trace_id FK -> trace parent_span_id service_id FK name start_ts duration_ms log_record log_id PK service_id FK class ts trace_id FK -> trace body_redacted subject_key_id 1 : N 1 : N 1 : N N : 1 1 : N 1 : N 1 : N 1 : N Data Model — Telemetry, Its Owners and Its Enforcement Record trace_id on log_record is optional by design: a log from an unsampled request still exists, and the join simply returns nothing rather than the record being discarded. Alert rules and SLO definitions are control-plane config and live in the store shown in view 12. v 1.0 · owner Reliability Architecture · date 2026-09

Decisions

  • effective_rate and keep_reason live on the trace, not in a pipeline config. A trace that cannot say why it survived or at what rate cannot be corrected for, and a count derived from it has to be refused.
  • enforcement_event is a first-class entity, not a log line. Every dropped label, rejected series and shed class is a record with an attribute, a team and a count — which is what makes "never silently drop telemetry" checkable.
  • trace_id on log_record is optional: a log from an unsampled request still exists, and the join returns nothing rather than the record being discarded.

Assumptions

  • Budget and retention class are held on the team and overridable per service. If real tenancy turns out to be per-service with no team layer, usage_ledger and the scorecards in view 06 lose their natural grain.

Deliberately omitted

  • Alert rules and SLO definitions are control-plane configuration and live in the store shown in view 12; modelling them here would suggest they sit beside telemetry, which is exactly the coupling view 10 avoids.
◀  Storage Zones All views Retention Tiers  ▶
Solution Architecture v1.0 · Amazon Web Services with open-source collection and storage · Reliability Architecture · 2026-09 · 25 views13-data-model