Design Log Aggregation

Hard45 min
1 / 30
understanding8 min read

Clarify Log Sources and Investigation Workloads

How Clarify Log Sources and Investigation Workloads (understanding) informs Log Aggregation architecture and interviewer depth.

Clarify Log Sources and Investigation Workloads

Fleet scale anchor: 50,000 hosts, 2M events/sec sustained ingest, 5× burst during incidents, ~500 bytes per event after gzip on the wire.

Before drawing boxes, map who emits logs and how engineers investigate during deploys and outages.

Source taxonomy

Source classExamplesInvestigation pattern
ApplicationJSON stdout, structured errorsFilter by service, trace_id, deployment_id
Kuberneteskubelet, CNI, ingressNode + pod labels; correlate with rollout timestamps
CI/CDbuild agents, deploy hooksTie git_sha to error spikes after merge
SecurityWAF, IDS, auth gatewaySub-minute freshness; immutable retention
Auditadmin API, IAM changesWORM storage; legal hold overrides TTL

Clarifying questions to ask the interviewer

  1. Is this multi-tenant SaaS or a single internal platform?
  2. Do we need full-text search on message bodies or mostly field filters?
  3. What searchable lag is acceptable for ERROR vs DEBUG classes?
  4. Are deploy markers (canary steps) first-class in the query language?
  5. Must we support GDPR erasure and legal hold on the same index?

DevOps coupling

Elastic/Splunk/Datadog interviews reward linking logs to release safety: annotate every line with git_sha, rollout_wave, and k8s_namespace so on-call can query "errors since canary step 2" without guessing time windows.

Out-of-scope for v1 (state explicitly)

  • Building a full APM trace store (integrate via trace_id only)
  • Long-term ML anomaly detection (batch export to data lake is fine)
  • Replacing metrics systems (emit counters from indexers, do not own TSDB)

How to open this one

The framing that lands for log aggregation is the ingest-index-query pipeline at scale: agents ship structured logs to a buffer (Kafka) that absorbs bursts, an indexer writes to tiered storage, and queries hit hot indexes while cold data sits cheap. Lead with backpressure — what happens when ingest outruns indexing — and the failure story that matters: a log flood from one noisy service threatens to drown the pipeline, so per-tenant rate limits and sampling protect everyone else. That shows you understand log systems fail by overload, not by being too small.

Key Highlights

  • Focus: Clarify Log Sources and Investigation Workloads
  • Anchor on ingest lag, query p95, and tiered retention cost.
  • Call out hot shards, parser drift, and partial query honesty.
Staff+ signal
State events/sec, bytes/event, retention days, and freshness SLO before drawing boxes.
Avoid
Treating log aggregation as grep-at-scale without tiering, dedup, or tenant isolation.

Section Rescue Kit

Buzzwords to use:

Write-ahead bus retentionSegment immutability

Safe statements:

  • "I will quantify ingest lag and query p95 before naming shard counts."
  • "If we must cut cost, DEBUG sampling moves first—not SECURITY freshness."
Design Log Aggregation - System Design | WinJob | WinJob