Skip to content
Snippets Groups Projects
user avatar
Robert Fratto authored
Support for reading systemd journal entries has been added. 
promtail will look for a job in scrape_configs with a journal key 
to activate the journal target. 

If GOOS=linux and CGO_ENABLED=1, promtail will now require 
libsystemd headers to be available for building. If GOOS is not 
linux or CGO_ENABLED is not 1, journal support will be unavailable
and a log message will be printed warning the user that their config 
file has journal tailing configured without it being built into promtail. 

See docs/promtail-examples.md for a concrete example of 
using journal support. 

Other structural changes made: 

  1. Ability for checking if scrape.Config.ServiceDiscoveryConfig is 
     non-zero has been added. 

     This was chosen over making ServiceDiscoveryConfig a pointer
     as yaml.v2 cannot parse an inline struct into a pointer value. 

  2. Updated pipeline logger component name to journal_pipeline and
     file_pipeline for JournalTargetManager and FileTargetManager
     respectively.

  3. The positions file will now store positions as strings instead of 
     integers. Existing positions will be read in properly but written out 
     as strings the next time the positions file is saved. This is done to 
     be able to store the journal cursor, which is a string. The positions 
     API has been updated to support reading in the old integer values 
     and the new string values. 
9eb3098d
History

Loki Logo

CircleCI Go Report Card Slack

Loki: like Prometheus, but for logs.

Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream.

Compared to other log aggregation systems, Loki:

  • does not do full text indexing on logs. By storing compressed, unstructured logs and only indexing metadata, Loki is simpler to operate and cheaper to run.
  • indexes and groups log streams using the same labels you’re already using with Prometheus, enabling you to seamlessly switch between metrics and logs using the same labels that you’re already using with Prometheus.
  • is an especially good fit for storing Kubernetes Pod logs. Metadata such as Pod labels is automatically scraped and indexed.
  • has native support in Grafana (needs Grafana v6.0).

A Loki-based logging stack consists of 3 components:

  • promtail is the agent, responsible for gathering logs and sending them to Loki.
  • loki is the main server, responsible for storing logs and processing queries.
  • Grafana for querying and displaying the logs.

Loki is like Prometheus, but for logs: we prefer a multidimensional label-based approach to indexing, and want a single-binary, easy to operate system with no dependencies. Loki differs from Prometheus by focussing on logs instead of metrics, and delivering logs via push, instead of pull.

Getting started

The getting started docs have instructions on how to install Loki via Docker images, Helm charts, Jsonnet, or from source.

Once you have promtail, Loki, and Grafana running, continue with our usage docs on how to query your logs.

Documentation

  • API documentation for alternative ways of getting logs into Loki.
  • Operations for important aspects of running Loki.
  • Promtail is an agent which can tail your log files and push them to Loki.
  • Docker Logging Driver is a docker plugin to send logs directly to Loki from Docker containers.
  • Logcli on how to query your logs without Grafana.
  • Troubleshooting for help around frequent error messages.
  • Usage for how to set up a Loki datasource in Grafana and query your logs.

Getting Help

If you have any questions or feedback regarding Loki:

Your feedback is always welcome.

Further Reading

Contributing

Refer to CONTRIBUTING.md

License

Apache License 2.0, see LICENSE.