Loki Config Generator

Build production-ready Grafana Loki configurations with storage backends, ingester tuning, compaction, and ruler alerting.

Loki Configuration

loki-config.yaml
1auth_enabled: false
2
3common:
4 path_prefix: /loki
5 storage:
6 filesystem:
7 chunks_directory: /loki/chunks
8 rules_directory: /loki/rules
9 replication_factor: 1
10
11server:
12 http_listen_port: 3100
13 grpc_listen_port: 9096
14 log_level: info
15
16limits_config:
17 ingestion_rate_mb: 16
18 ingestion_burst_size_mb: 32
19 max_entries_limit_per_query: 10000
20 retention_period: 744h
21
22schema_config:
23 configs:
24 - from: "2024-01-01"
25 store: tsdb
26 object_store: filesystem
27 schema: v13
28 index:
29 prefix: index_
30 period: 24h
31
32storage_config:
33 filesystem:
34 directory: /loki/chunks
35
36 tsdb_shipper:
37 active_index_directory: /loki/index
38 cache_location: /loki/cache
39 shared_store: s3
40
41compactor:
42 working_directory: /loki/compactor
43 shared_store: s3
44
45distributor:
46 ring:
47 kvstore:
48 store: inmemory
49 replication_factor: 1
50
51ingester:
52 lifecycler:
53 ring:
54 kvstore:
55 store: inmemory
56 replication_factor: 1
57 max_transfer_retries: 10
58 chunk_idle_period: 5m
59 max_chunk_age: 2h
60 chunk_target_size: 1572864
61 chunk_retain_period: 30s
62
63querier:
64 max_concurrent: 10
65
66query_range:
67 split_queries_by_interval: 30m
68 cache_results: true
69
70results_cache:
71 cache:
72 embedded_cache:
73 enabled: true
74 max_size_mb: 100
Syntax
Security
Best Practices

Overview

The Loki Config Generator produces production-ready config.yaml files for Grafana Loki, a horizontally-scalable, highly-available log aggregation system. Unlike full-text search engines like Elasticsearch, Loki indexes only labels — making it cost-effective and operationally simple for massive log volumes.

Loki's architecture mirrors Prometheus for metrics: it uses label-based indexing, LogQL for queries, and supports multiple storage backends including filesystem, S3, Azure Blob Storage, and Google Cloud Storage. This generator covers every Loki component — distributor, ingester, querier, query-frontend, compactor, ruler, and storage — producing valid YAML ready for deployment.

How It Works

1. Auth & Server: Configure multi-tenancy with auth_enabled and set server ports for HTTP (3100) and gRPC (9096) communication between Loki components.

2. Distributor: Receives incoming log streams via HTTP/gRPC, validates them, and distributes chunks across ingesters using consistent hashing ring with configurable replication factor.

3. Ingester: Receives log streams from distributors, buffers them in memory, and flushes compressed chunks to long-term storage. Configure chunk lifecycle with chunk_idle_period, max_chunk_age, and chunk_target_size.

4. Storage: Select the chunk and index storage backend — filesystem for single-node, S3/Azure/GCS for cloud deployments. Index stores are configured separately via boltdb-shipper or TSDB.

5. Querier & Query Frontend: Execute LogQL queries against ingesters and storage. The query frontend splits queries by time interval and retries failed requests for resilience.

6. Compactor: Merges and deduplicates index and chunk files in object storage to reduce storage costs and improve query performance.

7. Ruler: Evaluates recording and alerting rules against Loki, enabling log-based alerting via Alertmanager integration.

Best Practices

  • Always configure a replication_factor of at least 3 for production ingester rings to ensure log durability.
  • Use TSDB as the index store for new deployments — it offers better performance and compaction than boltdb-shipper.
  • Set retention_period on limits_config to control storage costs and comply with data retention policies.
  • Configure chunk_target_size (1.5MB default) and chunk_idle_period to balance memory usage and flush frequency.
  • Deploy the compactor with a shared_store matching your storage backend to keep index files optimized.
  • Use split_queries_by_interval in query frontend to parallelize large time-range queries across multiple queriers.

Common Mistakes

  • Running auth_enabled: true without configuring X-Scope-OrgID headers on push endpoints, causing all writes to fail.
  • Setting replication_factor higher than the number of ingester instances, resulting in stuck flushes and data loss.
  • Using filesystem storage in multi-instance deployments — filesystem is single-node only, use S3/Azure/GCS for distributed setups.
  • Forgetting to configure the schema_config with a valid from date, which causes Loki to reject all incoming data.
  • Not setting max_transfer_retries on ingesters during rolling updates, leading to unflushed chunks being lost.

Security Recommendations

  • Enable auth_enabled in production and enforce X-Scope-OrgID headers to isolate tenants.
  • Store S3 access keys, Azure account keys, and GCS service accounts in environment variables or secret managers — never in config files.
  • Use TLS for gRPC communication between Loki components (distributor ↔ ingester, querier ↔ store-gateway).
  • Restrict the ruler's alertmanager_url to an internal network and use mutual TLS.
  • Apply network policies to limit which services can reach the Loki HTTP and gRPC ports.

Production Tips

  • Use the microservices deployment mode (separate distributor, ingester, querier, etc.) for clusters above 50GB/day log ingestion.
  • Configure ingester lifecycler with a ring kvstore using consul or etcd for production — avoid the in-memory ring.
  • Deploy a read-write path split: ingesters + distributors on the write path, queriers + store-gateways on the read path.
  • Monitor Loki with its own /metrics endpoint — track ingester flush rates, querier latency, and compactor run durations.
  • Use LogQL metric queries (rate, count_over_time) for alerting instead of grep-like filters to reduce query load.
  • Set max_entries_limit_per_query (default 10000) conservatively to prevent OOM on queriers with high-cardinality label sets.

Frequently Asked Questions

What is Grafana Loki and how does it differ from Elasticsearch?
Loki is a log aggregation system that indexes only labels (metadata), not full log content. This makes it significantly cheaper to operate than Elasticsearch, which indexes every field. Loki uses LogQL for queries and integrates natively with Grafana dashboards.
What storage backends does Loki support?
Loki supports filesystem (single-node only), Amazon S3, Google Cloud Storage (GCS), and Azure Blob Storage for chunks. For index storage, it supports boltdb-shipper and TSDB. S3 is the most common choice for production deployments.
What is the difference between boltdb-shipper and TSDB?
TSDB is the newer, recommended index store offering better write performance, faster compaction, and lower memory usage. boltdb-shipper is legacy but still supported. New deployments should use TSDB.
How does Loki handle multi-tenancy?
Loki supports multi-tenancy via auth_enabled. When enabled, every request must include an X-Scope-OrgID header identifying the tenant. Data is fully isolated between tenants — no tenant can see another tenant's logs.
What is LogQL?
LogQL is Loki's query language inspired by PromQL. It supports log stream selectors (label matching), line filter patterns (regex, JSON), and metric queries (rate, count_over_time, unwrap) for creating dashboards and alerts.
How do I deploy Loki in production?
Use the microservices deployment mode with separate distributor, ingester, querier, query-frontend, and compactor processes. Deploy on Kubernetes using the official Helm chart or use Docker Compose for smaller setups. Always use S3 or GCS for storage and TSDB for the index.
What is the Loki ruler and when should I use it?
The ruler evaluates LogQL recording and alerting rules at regular intervals. Use it to create log-based alerts (e.g., error rate exceeding threshold) that fire to Alertmanager, or recording rules to pre-compute expensive queries for dashboards.

Related Generators