MS3 Readiness
This page records the telemetry readiness position agreed at the MS3 catch-up on 21 September 2026. It is a working snapshot: unverified parts of the ingestion architecture are identified explicitly rather than presented as settled design.
Readiness Outcome
Telemetry is ready for MS3 when each in-scope source is registered in the Global Component Registry (GCR), its transport and payload are understood, data reaches the appropriate repository, and the required evidence is visible through Grafana or an agreed output API.
GCR means Global Component Registry in this documentation. It is distinct from Gcore, the CDN provider.
Data Sources
| Source | Expected telemetry | Readiness position |
|---|---|---|
| Arctic Space | Metrics; payload format to be confirmed | Not yet sending data; arrange an onboarding session |
| Varnish | CDN logs containing CMCD | Obtain a sample and agree the transport in an onboarding session |
| Gcore | CDN access logs containing CMCD | Event-driven ingestion is deployed and verified against infrastructure code |
| CloudFront | W3C CDN logs containing CMCD | Event-driven ingestion is deployed with a dead-letter queue |
| AWS media services | Media pipeline telemetry | MediaLive and related services are not yet covered |
The GCR-backed static data is the canonical component inventory published on this site. Every telemetry source, including queue-based sources, must be represented there with the correct transport mechanism.
Current Ingestion Path
Gcore and CloudFront use separate deployments of the same event-driven pattern:
Gcore / CloudFront → S3 → ObjectCreated event → SQS
→ OpenTelemetry Collector (parse, transform, extract CMCD)
├─ parsed logs → OTLP/gRPC → Alloy → Loki
└─ derived metrics → Prometheus remote write
Grafana → Loki + Prometheus
Each log file written to S3 raises an ObjectCreated notification onto an SQS queue. An OpenTelemetry Collector consumes the queue by long polling, retrieves the object, parses each access-log line with OTTL transforms, maps fields to OpenTelemetry semantic conventions, and extracts CMCD client state.
The collector sends parsed logs to Alloy over OTLP/gRPC for forwarding to Loki. It derives request-count metrics across bounded, low-cardinality dimensions and sends those metrics directly to Prometheus over remote write. Metrics deliberately bypass Alloy because its Prometheus exporter discards the first Delta sample of a new series.
The path is verified against the deploying infrastructure code as of 21 September 2026. CloudFront messages move to a dead-letter queue after three failed receives. The Gcore queue is owned by another component, so its failure behaviour remains unconfirmed.
See Telemetry Architecture for Luca Di Vincenzo's detailed ingestion diagram, repository roles, and outputs.
Repositories and Outputs
- Prometheus stores metrics.
- Loki stores logs.
- Tempo stores traces.
- InfluxDB is present but is not actively used by a current service.
- Grafana provides dashboards and the evidence required for MS3.
- Popularity API is a required output endpoint for partners such as Varnish; its interface and delivery path remain to be agreed.
Gaps and Actions
- Obtain sample payloads and agree ingestion methods with Arctic Space and Varnish.
- Confirm ownership and operational responsibility for both collector deployments and their queues.
- Confirm the Gcore queue's retry and failure-handling behaviour.
- Define monitoring and response procedures for the CloudFront dead-letter queue.
- Register every telemetry source in the GCR with its correct transport mechanism.
- Add AWS media services, including MediaLive, to the telemetry design.
- Define the handoff between media streaming pipelines and the Telemetry module.
- Update Grafana dashboards with the new metrics and MS3 evidence.
- Define and deliver the Popularity API for partner access.
Meeting Record
Date: 21 September 2026
Attendees: Kris Brown, Norman Johnson, Chris Clark, Luca Di Vincenzo