Test your Grafana Loki knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
What is a common reason a team already using Prometheus and Grafana for metrics might choose Loki specifically for logs, over a more general-purpose logging platform?
In this round
What is a common reason a team already using Prometheus and Grafana for metrics might choose Loki specifically for logs, over a more general-purpose logging platform?
What does Loki typically use as its underlying storage backend for the actual compressed log data (chunks)?
What is Grafana Loki?
How should something like a request ID typically be handled in Loki, given the risks of using it as a label?
What does LogQL's support for "metric queries" (deriving numeric time series from log data, e.g. counting error log lines per minute) enable?
Why is Loki generally considered more cost-effective to operate at scale than a full-text-search-indexing log system like Elasticsearch?
What is Loki's core architectural difference from a system like Elasticsearch when it comes to indexing log data?
What is a common architectural pattern for scaling Loki's ingestion and query workloads independently, in larger production deployments?
What is a "log stream" in Loki's data model?
What does it mean when Loki's design philosophy is sometimes summarized as "like Prometheus, but for logs"?
What is Promtail, and what role does it play in a typical Loki deployment?
Why might a team choose to run Grafana, Loki, and Prometheus together as a unified observability stack rather than picking separate best-of-breed tools for metrics, logs, and dashboards from different vendors?