Practice log aggregation vocabulary: Elasticsearch/OpenSearch, Grafana Loki, log shipping, log agents, pipeline overload, and filtering debug logs before shipping.
0 / 5 completed
1 / 5
The observability stack uses ___ to store and search structured logs from all services.
Elasticsearch (and its fork OpenSearch) is the most common log storage backend in the ELK/EFK stack. It indexes JSON log entries as documents, enabling fast full-text and field-level search, aggregations, and dashboards via Kibana or OpenSearch Dashboards.
2 / 5
For cost-effective log storage the team adopts Grafana ___, which indexes only labels rather than full-text content.
Grafana Loki stores log streams compressed and indexes only metadata labels (like pod name, namespace, service). Queries combine label filtering with full-text search using LogQL. It is significantly cheaper to operate than Elasticsearch for high-volume log storage.
3 / 5
The platform team configures ___ to move logs from each container to the central aggregator.
Log shipping is the transfer of log data from its origin to a centralised aggregation system. Tools like Fluentd, Fluent Bit, Logstash, Vector, or Filebeat act as log shippers — reading logs from files or stdout and forwarding them to Elasticsearch, Loki, or other backends.
4 / 5
A Fluent Bit ___ runs on every node in the Kubernetes cluster to collect pod logs.
A log agent (such as Fluent Bit or Filebeat deployed as a DaemonSet) runs on every node in a cluster and collects logs from all pods on that node. Node-level agents are more resource-efficient than per-pod sidecars for most use cases.
5 / 5
During a traffic spike the log ___ drops messages when overloaded. What is the risk?
The log pipeline (shippers, message queues, and indexers) can become a bottleneck under high load. When it drops messages, you lose log coverage precisely when you need it most — during incidents. Mitigation includes back-pressure handling, increased buffer capacity, and rate limiting at the source.