Practices & Architecture

Metrics, traces, logs, and continuous profiling are the raw signals. This hub covers the practices and architectural decisions that turn those signals into something a team can actually run on: how to define reliability targets, how to structure alerting so the right person gets paged, how observability changes on Kubernetes or serverless platforms, how to keep the resulting bill under control, and how the same signals get reused for security monitoring.

None of this fits neatly under a single pillar — most of it draws on metrics, traces, and logs together — which is why it gets its own hub rather than being wedged into one of the other four.

Why this matters

• Signals alone don’t create reliability. Collecting metrics, traces, and logs is only useful if a team has agreed on what “healthy” looks like (SLIs/SLOs) and has an alerting and on-call process that surfaces real problems without drowning people in noise.
• Platforms change the rules. Observability on a fixed fleet of VMs looks very different from observability on Kubernetes (ephemeral pods, sidecars, high label cardinality) or serverless (no long-running process to attach an agent to, cold starts, per-invocation billing).
• Observability has a real cost curve. Metrics cardinality, log retention, and trace sampling rates are also cost levers — teams that don’t manage them deliberately tend to get an uncomfortable bill.
• The same data serves security, too. Logs and traces collected for reliability are frequently the same data security teams need for detection and audit, which is why SIEM and observability increasingly overlap.

What you’ll find here

Articles in this hub cover platform-specific guidance (Kubernetes, serverless), SRE fundamentals (SLIs, SLOs, error budgets), incident management and on-call alerting design, cost optimization strategies, and the basics of security observability and SIEM — all written assuming you already know what metrics, traces, and logs are, and focused on how to apply them.