The Components in One Map

Enterprise problem: An operator who cannot say which component owns each telemetry transition will route data through overlapping tools, hide failure boundaries, and lengthen incidents for customers.

Whole-course context: The incoming evidence is a four-signal design with collection, storage, query, rules, and notification responsibilities already introduced; this day turns those parts into one reviewable component contract.

Today’s slice: We map application instrumentation, exporters, collectors, specialized backends, Grafana, rulers, Alertmanager, and object storage without treating any product name as the customer outcome.

End-of-day evidence: A component matrix and two traced journeys show the producer, consumer, owner, protocol, and terminal evidence at every boundary.

Still unsolved: Deployment scale, signal economics, schema governance, and privacy policy remain deliberately outside today’s component map.

Without customer jobs, a component inventory becomes a shopping list and teams cannot tell whether a missing or duplicated component breaks an investigation. These use cases anchor the map in two observable outcomes.

Use case ID	Actor	Customer job	Success outcome	Denial or recovery evidence
D17-UC-01	On-call engineer	Follow a checkout symptom from metric to trace and logs	One investigation links the anomaly to a responsible service and immutable trace	A broken correlation link names the boundary, rejected query, and unaffected metric query
D17-UC-02	Platform operator	Prove every telemetry hop has one accountable owner	The map names the ingress, transform, store, query, rule, and notification owner	An unknown or duplicate owner fails review and produces a remediation record

Vague architecture goals cannot be accepted or rejected, so each actor needs an observable story tied to the same use-case contract.

Story ID	Use case IDs	User story	Observable acceptance conditions
D17-US-01	D17-UC-01	As an on-call engineer, I want correlated signal links, so that I can move from customer impact to causal evidence without guessing	A recorded investigation starts at a metric, opens one trace and its related logs, and records a negative lookup for an invalid trace ID
D17-US-02	D17-UC-02	As a platform operator, I want an owned component map, so that gaps and overlapping responsibilities are reviewable	Every arrow names a protocol and owner; one intentionally removed owner makes the validation fail

A component map is only credible when customer actions traverse it, otherwise arrows may describe no usable product flow. The happy and failure paths below end in reviewable evidence.

Flow ID	Use case IDs	Path	Trigger	Numbered steps	Terminal evidence
D17-FLOW-01	D17-UC-01	Happy	Engineer selects a checkout error-rate exemplar in Grafana	1. Grafana queries Prometheus or Mimir.<br>2. The exemplar supplies a trace reference.<br>3. Grafana queries Tempo.<br>4. The trace context selects related Loki logs.<br>5. The engineer records the service owner and action.	Actor, tenant, query ranges, expected links, observed links, environment, timestamp, trace ID, and investigation run ID
D17-FLOW-02	D17-UC-02	Failure	Operator validates a proposed component map	1. Validator walks every producer-consumer edge.<br>2. It checks protocol and accountable owner.<br>3. A missing owner rejects publication.<br>4. A known-good edge remains queryable as a positive control.	Failed edge, expected owner, observed absence, unchanged positive control, map revision, environment, timestamp, and validation run ID

If services are named independently of the flows, the diagram hides unnecessary hops and ownerless state. This design includes only components required by the two customer journeys.

Use case ID	Entry point	Responsible services	Authoritative store	Failure evidence
D17-UC-01	Grafana Explore or dashboard exemplar	Grafana query layer, Prometheus or Mimir, Tempo, Loki, identity proxy	Specialized telemetry stores owned by their backend teams	Query error, missing correlation reference, or tenant-scope denial tied to the investigation run
D17-UC-02	Component-map validation action	Architecture registry, policy validator, collector owners, backend owners	Versioned component registry owned by the platform team	Unowned edge, protocol mismatch, duplicate responsibility, and unaffected-edge control

Ownerless metadata makes a correct diagram decay after the first reorganization, so the map itself needs durable identity, revision, and evidence records. No generated customer application is being built here.

Generated-application database: Not created in this slice — durable control-plane component contracts and investigation evidence are sufficient.

Record or entity	Store and owner	Primary key	Foreign key or opaque reference	Tenant key	Material constraint	Lifecycle and deletion	Use case IDs
ComponentContract	Architecture registry, platform architecture owner	component_id	None — root record for a platform component	organization_id	Component name and active revision are unique per organization; exactly one accountable owner	Version on change, retire after migration, retain revisions for audit, delete under metadata policy	D17-UC-01, D17-UC-02
ComponentEdge	Architecture registry, platform architecture owner	edge_id	component_id_from and component_id_to local FKs	organization_id	Producer, consumer, protocol, and evidence type are mandatory	Replace by revision, tombstone on component retirement, retain with parent audit history	D17-UC-01, D17-UC-02
InvestigationRun	Evidence store, incident tooling owner	run_id	Opaque trace, query, alert, and map-revision references	organization_id	Actor, scope, expected and observed results, environment, and timestamp are immutable	Retain to incident policy, export with incident, expire payload before audit metadata	D17-UC-01, D17-UC-02

When similar tools appear adjacent, teams can accidentally assign the same job twice and lose the actual failure boundary. The decisive question is what each component consumes and what durable interface it exposes.

Component	Primary responsibility	Consumes	Produces or exposes
Application instrumentation	Create evidence with domain meaning	Runtime events	Metrics, logs, spans, and profiles
Exporter	Translate system-specific state	Native system data	Prometheus exposition or OpenTelemetry data
OpenTelemetry SDK	Describe application operations and propagate context	Application execution	OpenTelemetry Protocol (OTLP) telemetry
OpenTelemetry Collector or Grafana Alloy	Receive, protect, transform, batch, and route	OTLP, scrape targets, logs, profiles	Backend-specific writes and pipeline health
Prometheus	Discover and scrape targets; query local metrics and evaluate rules	Prometheus exposition endpoints	PromQL API, local time series, alerts, remote write
Mimir	Supply shared, scalable, long-retention metrics	Remote write or OpenTelemetry metrics	Prometheus-compatible query API
Loki	Store and query label-organized log streams	Log streams	LogQL API
Tempo	Store and reconstruct distributed traces	Spans	Trace lookup and TraceQL API
Pyroscope	Attribute sampled resource use to code	Profile samples	Profile queries and flame graphs
Grafana	Correlate and visualize signals	Backend query APIs	Dashboards, exploration, and alert views
Ruler and Alertmanager	Recognize conditions, then group and route notifications	Queries, rules, and firing alerts	Recorded series, alert state, silences, notifications
Object storage	Persist economical historical blocks and chunks	Backend blocks	Durable historical objects under retention policy

Application instrumentation owns business semantics: only the checkout code knows whether a payment was duplicated or a policy denied. A collector can normalize and redact that evidence, but cannot reconstruct missing domain meaning. Backends specialize in storing and querying signal shapes; Grafana correlates their APIs rather than becoming their authoritative store.

Architecture reviews fail when a line merely says “connects to,” because authentication, retry behavior, tenancy, and loss semantics stay invisible. Use this protocol for every edge in the map.

1. Name the producer, consumer, protocol, direction, and accountable owner.
2. State whether the edge is push, pull, or query, and where buffering occurs.
3. Record tenant identity and authentication independently at collection and query boundaries.
4. Inject one invalid credential and one unavailable consumer; observe rejection, retry, drop, or backpressure.
5. Preserve the positive control: another authorized tenant and healthy edge still work.
6. Falsify the map if any observed hop, durable store, or operator action lacks a represented edge.

A memorable product list is not an architecture; the useful map follows evidence from behavior to accountable action.

• Applications and exporters create or translate evidence; collectors protect and route it.
• Prometheus, Mimir, Loki, Tempo, and Pyroscope retain and query different signal shapes.
• Grafana correlates signals, rulers detect conditions, and Alertmanager controls notification delivery.
• Every edge needs an owner, protocol, tenancy rule, and falsifiable failure observation.

An incomplete review creates false confidence, so complete these checks before accepting the component map.

• [ ] Every producer and consumer has one accountable owner.
• [ ] Every arrow names protocol, direction, tenant identity, and failure behavior.
• [ ] Application-owned business semantics are not delegated to infrastructure.
• [ ] The metric-to-trace-to-log journey has positive and negative evidence.
• [ ] Object storage retention and deletion remain owned by each backend.

Product responsibilities change, so these current claims were checked against official primary documentation.

• Grafana Alloy: how collection, processing, and backend routing work
• OpenTelemetry Collector processors
• Prometheus security model and component endpoint assumptions