Run this before Loki takes production logs, and again after any change to the schema, the storage backend, the limits, the retention settings or the tenancy model. Those five are where the irreversible mistakes live; everything else can be adjusted while the cluster runs.
The items are ordered as configuration, then labels, then limits, then retention, then tenancy and recovery. That order is deliberate: the label discipline decides whether the cluster survives at all, the limits decide who gets rejected when it does not, and retention decides what you still have afterwards.
Reading the running configuration
Most items ask the process what it loaded rather than reading the file, because
Loki starts happily on a file with a broken section. The configuration endpoint
serves YAML, so the commands below parse it with yq; where a section is
missing from the output, the key was never loaded and the component is running
on its built-in default. Substitute your own component addresses, bucket names
and storage profile — the names below are the shapes this course uses
throughout, not an estate that exists.
Where a target runs several components in one process, the same endpoint answers for all of them. Where they are separate, ask each one, because the whole point of several of these items is that the separate files can disagree.
The two irreversible settings
Two items on this list can destroy data on their own. The schema list is append-only: removing a historical period makes everything written under it unreadable. Retention deletes on the compactor’s next sweep, with no confirmation and no undo beyond bucket versioning. Both deserve a second reviewer on the pull request, and both are the reason the versioning item is here even though it looks like storage housekeeping.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Largest log producer: ______ Date: ___________