Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage backend examples #2357

Merged
merged 4 commits into from
Jul 16, 2020
Merged

Storage backend examples #2357

merged 4 commits into from
Jul 16, 2020

Conversation

owen-d
Copy link
Member

@owen-d owen-d commented Jul 15, 2020

Writes a new default storage doc which includes some digestible example configurations.

docs/storage.md Outdated Show resolved Hide resolved
docs/storage.md Outdated

### File System

The file system is the simplest backend for chunks, although it's also susceptible to data loss as it's unreplicated. This is common for single binary deployments though, as well as for those trying out loki or doing local development on the project. Without significant expertise and knowledge of Loki's operational patterns, the file system backend is not suggested for production use unless you can tolerate log loss.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a bit harsh I think the single binary on PVC is production ready. I understand the point, but millions of Prometheus users are out there using a single binary in production for monitoring thousands of servers. If you could rephrase this so that it doesn't diminish the use case for filesystem that would be great.

I'd like Loki single binary on filesystem to be also perceived as a starting point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.


## Period Configs

Loki aims to be backwards compatible and over the course of it's development has had many internal changes that facilitate better and more efficient storage/querying. Loki allows incrementally upgrading to these new storage _schemas_ and can query across them transparently. This makes upgrading a breeze. For instance, this is what it looks like when migrating from the v10 -> v11 schemas starting 2020-07-01:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's awesome !

# Storage

Loki uses a two pronged strategy regarding storage, which is responsible for both it's limitations and it's advantages. The main idea is that logs are large and traditional indexing strategies are prohibitively expensive and complex to run at scale. This often brings along ancillary procedure costs in the form of schema design, index management/rotation, backup/restore protocols, etc. Instead, Loki stores all the its log content unindexed in object storage. It then uses the Prometheus label paradigm along with a small but specialized index store to allow lookup, matching, and filtering based on the these labels. When a set of unique key/value label pairs are combined with their logs, we call this a _log stream_, which is generally analagous to a log file on disk. It may have labels like `{app="api", env="production", filename="/var/logs/app.log"}`, which together uniqely identify it. The object storage is responsible for storing the compressed logs cheaply while the index takes care of storing these labels in a way that enables fast, effective querying.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a small reference to our goal toward not requiring an index store ? WDYT ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to leave this point out for now.

Copy link
Contributor

@cyriltovena cyriltovena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few nits, but overall great stuff, thanks for this.

LGTM

@codecov-commenter
Copy link

Codecov Report

Merging #2357 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #2357   +/-   ##
=======================================
  Coverage   61.63%   61.63%           
=======================================
  Files         160      160           
  Lines       13534    13534           
=======================================
  Hits         8342     8342           
+ Misses       4567     4566    -1     
- Partials      625      626    +1     
Impacted Files Coverage Δ
pkg/promtail/targets/file/tailer.go 76.13% <0.00%> (-2.28%) ⬇️
pkg/querier/queryrange/downstreamer.go 97.93% <0.00%> (+2.06%) ⬆️

@owen-d owen-d merged commit 72880d1 into grafana:master Jul 16, 2020
@owen-d owen-d deleted the docs/storage branch July 29, 2020 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants