Grafana Loki: Log Aggregation Without the Index Bill

Loki takes a deliberately different approach from full-text indexing log platforms: it stores compressed log chunks and indexes only the labels that describe the stream. That makes it cheap to run and simple to operate, at the cost of relying on good label design and query patterns. This article covers the architecture, a working local deployment, and the LogQL queries that replace grep when you cannot SSH into the server.

How Loki Stores Logs

• Agent - a collector such as Grafana Alloy (or Promtail on older deployments) tails files or the systemd journal, attaches labels, and pushes streams over HTTP.
• Loki - ingests and stores log data in compressed chunks; the index holds only the label set, which is why it stays small.
• Grafana - queries and visualises; queries can also come from LogCLI or the HTTP API.

Because the whole log line is still searchable, labels exist to narrow the data scanned, not to make the search possible. Over-labelling is the standard first mistake: a label with unbounded values (a user ID, a request ID) creates a stream per value and destroys performance.

A Working Docker Deployment

git clone https://github.com/grafana/loki-fundamentals.git -b getting-started
cd loki-fundamentals
docker compose up -d

Verify each component:

http://localhost:12345/graph   # Alloy UI
http://localhost:3000          # Grafana
http://localhost:3100/metrics  # Loki metrics

Alloy is configured to tail all container logs, so data should already be arriving; Grafana's Logs Drilldown view is the fastest way to confirm it.

Promtail in Existing Fleets

# /etc/promtail/config.yml (short form)
server: { http_listen_port: 9080 }
clients:
  - url: http://loki.example.com:3100/loki/api/v1/push
scrape_configs:
  - job_name: syslog
    static_configs:
      - targets: [localhost]
        labels:
          job: syslog
          host: edge-router-01
          __path__: /var/log/*.log

Promtail discovers targets, attaches labels and pushes batches; it exposes /ready and /metrics, which is all you need for health monitoring of the pipeline itself.

LogQL Essentials

{job="syslog", host="edge-router-01"} |= "BGP"
{job="syslog"} |~ "LINK-3-UPDOWN" | json
sum(rate({job="syslog"} |= "authentication failed" [5m])) by (host)

The final form is the one that turns logs into alerting: a log-derived metric, evaluated by Loki's ruler, which can then route to Alertmanager. That gives you "alert me when authentication failures spike on any host" without shipping a separate metric pipeline.

Where Loki Fits

Use Loki for application and device logs where label-based filtering is enough and volume is high; keep full-text-indexed platforms for the rare case where you must search arbitrary strings across years of data. Network devices fit naturally: forward syslog as described in rsyslog central log server setup, tune device-side levels with IOS logging levels, and pair it with flow data for traffic questions - NetFlow v9 on IOS. For pure device health polling, Zabbix SNMP monitoring remains the lighter-weight option.

原文链接：https://grafana.com/docs/loki/latest/get-started/