Part 3 · 1 chapters · ~8 min

Observability as a Discipline

Shared conventions across services: OpenTelemetry everywhere, propagation through queues, RED and USE metrics with common names, structured logs with trace ids, cardinality limits, redaction, service templates that emit it all by default, and alert ownership.

Conventions every service follows

code

// propagate trace context through a queue message (producer)
import { context, propagation } from '@opentelemetry/api';
const headers: Record<string, string> = {}; propagation.inject(context.active(), headers);
await queue.add('submit-payout', { payoutId }, { headers });
// consumer: continue the same trace
const ctx = propagation.extract(context.active(), job.opts.headers);
await context.with(ctx, () => tracer.startActiveSpan('submit-payout', span => run(job).finally(() => span.end())));

Cardinality: never use user ids, emails or raw URLs as metric labels; one label with a million values creates a million time series and a large bill. Put them in traces and logs instead. Templates: the paved-road service template (Platform course) ships with all of this configured, so conventions are the default.

OBSERVABILITY CONVENTIONS

what every service emits, the same way

swipe the figure sideways, or tap expand for full screen

1/4

traces

One SDK and one propagation format across languages, so a trace crosses Node, Go and Java services and queue hops intact.

one propagation standardtraceparent everywhere