Skip to content
intermediate Phase 9 · Observability

EFK/Loki Stack

Set up centralized logging with EFK stack or Loki for log aggregation.

1h
0 problems
Topic Progress 0%

Why Centralize and Which Stack

Why Centralize and Which Stack

Node-local logs die with the node, so clusters ship them to a central store. Two families dominate:

  • EFK: Fluent Bit (or Fluentd) as a DaemonSet tails /var/log/containers/*.log, enriches lines with Kubernetes metadata from the API, and indexes them into Elasticsearch/OpenSearch, queried in Kibana.
  • Loki: Promtail/Grafana Agent does the same collection, but Loki indexes only labels (namespace, pod, stream) and stores log bodies in object storage — cheaper to run, queried with LogQL that mirrors PromQL.

Both agents run per node; neither reads logs through kubectl logs.

Configuring the Shipper

Configuring the Shipper

Fluent Bit tails node files and attaches Kubernetes context:

[INPUT]
    Name              tail
    Path              /var/log/containers/*.log
    Parser            docker
    Mem_Buf_Limit     5MB
[FILTER]
    Name              kubernetes
    Match             kube.*
    Kube_URL          https://kubernetes.default.svc:443
[OUTPUT]
    Name              es
    Match             kube.*
    Host              elasticsearch.logging
    Logstash_Prefix   k8s

Multiline handling matters most: without a multiline parser, every line of a Java stack trace becomes a separate log record. Match continuations by a timestamp or ^s+(at|...) pattern and flush after a timeout so partial traces still emit.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Lost lines under load. Tail inputs buffer in memory; without Mem_Buf_Limit and an offset checkpoint file, backpressure drops data or re-reads files after restart.

Index growth. Elasticsearch is disk-heavy: apply ILM/rollover with a retention window, shard by day, and keep mapping templates fixed — dynamic mapping on message fields explodes the cluster. Loki sidesteps this by indexing labels only.

Secrets in logs. Agents forward everything; redact at the source or with a filter before it leaves the node.

Interview angle: contrast indexing strategies (full-text index vs label index), place the agent (DaemonSet, never in-app shippers per pod), and explain how multiline reassembly works.

Quiz

1. Where does a log-shipping agent run in a cluster?

Question 1 options

2. What is Loki's main cost advantage over Elasticsearch?

Question 2 options

3. Why does a multiline parser matter for application logs?

Question 3 options

Flashcards

Question

EFK components

Answer

Elasticsearch (index), Fluent Bit/Fluentd (DaemonSet shipper), Kibana (query UI).

Question

Loki indexing model

Answer

Labels indexed centrally, log content stored as compressed chunks — LogQL queries filter by label then grep content.

Question

Log enrichment

Answer

The agent queries the API for pod metadata (namespace, labels, node) and attaches it to each line.

Question

offset checkpoint

Answer

Persistent record of tail positions so agent restarts resume without duplicating or skipping lines.

Revision Notes

Key Takeaways

  • 1. Centralize logs because node storage dies with the node; ship via DaemonSet agents
  • 2. EFK trades cost for full-text search; Loki trades search richness for label-only indexing
  • 3. Multiline parsing, retention policies, and redaction are what keep the pipeline trustworthy

Interview Tips

  • • Compare EFK vs Loki on indexing, query language, and cost without hand-waving
  • • Describe failure modes you have handled: backpressure drops, multiline splits, and mapping explosions

Cheat Sheet

DaemonSet tail /var/log/containers → enrich via API → ES (full-text index) or Loki (label index, object storage). Multiline-parse stacks, checkpoint offsets, apply retention/ILM, redact secrets.

Continue Learning