Exercise 2: ELK vs. Loki's Core Difference — Possible Solution
====================================================================

THE CORE ARCHITECTURAL DIFFERENCE
------------------------------
Per this chapter, "rather than indexing the full text of every log
line the way Elasticsearch does, Loki indexes only a small set of
labels (like which service or server a log came from), storing the
actual log text compressed and unindexed." ELK (via Elasticsearch)
indexes the complete content of every log line, making any text within
it directly searchable; Loki indexes only metadata/labels about each
log line, while the actual message content sits compressed but not
individually indexed.

THE REAL TRADEOFF THIS REPRESENTS
------------------------------
Per this chapter, this is "a real, deliberate resource-usage tradeoff
- cheaper to run at scale, at the cost of full-text search being
somewhat less immediate than in an ELK-style setup." Indexing every
word of every log line (ELK's approach) costs more in storage and
compute resources but makes arbitrary text searches fast and direct.
Indexing only labels (Loki's approach) is cheaper to operate at scale,
but searching for specific text content within the logs themselves is
correspondingly less immediate than with a full-text index.

WHY NEITHER APPROACH IS SIMPLY "BETTER"
------------------------------
Per this chapter's own comparison table, this is presented as a
genuine tradeoff (full-text search speed vs. resource cost) rather
than one tool being a strictly superior version of the other - which
one fits better depends on how much log volume needs to be handled and
how important instant full-text search is for that specific use case.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the indexing difference (full text vs. labels
only) as the core architectural distinction, and correctly explains
the resource-cost-vs-search-immediacy tradeoff that difference actually
represents.