Grafana Loki vs Graylog vs OpenSearch: Best Self-Hosted Log Management 2026

If you run more than a handful of self-hosted services, tracking down errors across scattered log files becomes a nightmare. SSH into five different containers, grep through rotating files, and still miss the critical stack trace that explains why your reverse proxy dropped traffic at 3 AM.

Centralized log management solves this. Instead of hunting through individual log files, every service ships its logs to a single system where you can search, filter, correlate, and alert on them in real time.

Commercial solutions like Splunk, Datadog, and Papertrail charge per gigabyte of ingested logs — which gets expensive fast when you’re logging dozens of containers. Open-source alternatives give you the same capabilities without per-volume pricing, and your logs never leave your infrastructure.

In this guide, we’ll compare the three leading open-source log management platforms, walk through full docker deployments for each, and help you pick the right tool for your setup.

Why Self-Host Your Log Management

There are four compelling reasons to run your own log management stack:

Cost control. Splunk charges $2,300 per month for just 50 GB of daily ingestion. Datadog starts at $0.10 per GB beyond the free tier. If you run 20+ services generating 10 GB of logs per day, you’re looking at $3,000+ per month with commercial providers. Self-hosted solutions cost only the price of the disk you store them on.

Data sovereignty. Logs contain IP addresses, user identifiers, request parameters, and error traces. Sending this data to a third-party cloud provider means trusting them with sensitive operational information. Self-hosting keeps everything on infrastructure you control.

No ingestion limits. Commercial log services penalize verbosity. You end up reducing log levels, dropping debug information, and losing the data you actually need when something breaks. With self-hosted logging, you can log everything and decide retention based on disk space, not budget.

Deep integration with existing infrastructure. Self-hosted log platforms integrate natively with your eprometheusnitoring stack — Prometheus metrics, Grafana dashboards, and alerting pipelines — without requiring expensive add-on licenses.

The Three Contenders

Grafana Loki

Loki takes a fundamentally different approach from traditional log aggregators. Instead of indexing the full text of every log line, Loki only indexes metadata — labels like job, container, and level. This makes Loki dramatically more storage-efficient and faster to scale.

Think of Loki as “Prometheus for logs.” If you already use Prometheus for metrics and Grafana for dashboards, Loki plugs right in with the same label-based query language (LogQL).

Best for: Teams already using Grafana, resource-constrained environments, high-volume log ingestion where storage cost matters.

Graylog

Graylog is the most feature-complete open-source log management platform. It provides full-text search, field extraction, dashboards, alerting, and access control out of the box. Behind the scenes, it uses OpenSearch/Elasticsearch for storage and MongoDB for configuration.

Graylog feels most like a commercial SIEM product. It includes pipeline processing for log enrichment, stream-based routing, and a powerful extraction system that pulls structured fields from unstructured log lines automatically.

Best for: Security teams, compliance requirements, organizations that need full-text search with rich dashboards.

OpenSearch

OpenSearch is Amazon’s open-source fork of Elasticsearch and Kibana, created after Elastic changed its license. It’s the most capable full-text search engine in the open-source ecosystem, with a massive plugin ecosystem and the most sophisticated query language (OpenSearch Query DSL).

OpenSearch gives you the most raw power — distributed search, aggregations, anomaly detection, and machine learning-based log anomaly identification. But it also has the steepest learning curve and highest resource requirements.

Best for: Large-scale deployments, complex search and aggregation needs, teams with Elasticsearch experience.

Quick Comparison

Deployment Guide: Grafana Loki

Loki’s architecture is refreshingly simple. You need three components: Promtail (log shipper on each server), Loki (log aggregation engine), and Grafana (visualization and querying).

Step 1: Create the Docker Compose File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# docker-compose-loki.yml
version: "3.8"

services:
  loki:
    image: grafana/loki:3.4.1
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml:ro
      - loki-data:/loki
    command: -config.file=/etc/loki/local-config.yaml
    restart: unless-stopped

  grafana:
    image: grafana/grafana:11.5.2
    container_name: grafana-logs
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=change_me_strong_password
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - loki
    restart: unless-stopped

  promtail:
    image: grafana/promtail:3.4.1
    container_name: promtail
    volumes:
      - /var/log:/var/log:ro
      - ./promtail-config.yaml:/etc/promtail/config.yaml:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
    command: -config.file=/etc/promtail/config.yaml
    restart: unless-stopped

volumes:
  loki-data:
  grafana-data:

Step 2: Configure Loki

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# loki-config.yaml
auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

compactor:
  working_directory: /loki/compactor
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150

limits_config:
  retention_period: 744h  # 31 days
  ingestion_rate_mb: 16
  ingestion_burst_size_mb: 32

Step 3: Configure Promtail

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# promtail-config.yaml
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          host: server-01
          __path__: /var/log/*.log

  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: 'container'
      - source_labels: ['__meta_docker_container_log_stream']
        target_label: 'logstream'

Step 4: Launch the Stack

1

docker compose -f docker-compose-loki.yml up -d

Once Grafana starts, navigate to http://your-server:3000, add Loki as a data source at http://loki:3100, and start querying with LogQL:

1

{job="docker", container="nginx"} |= "error" | json | level="crit"

This query finds all critical errors from the Nginx container. Loki’s label-first approach means it only scans logs from the Nginx container (identified by the label), then filters for “error” text within those results — far more efficient than full-text scanning.

Deployment Guide: Graylog

Graylog requires three services: MongoDB (configuration storage), OpenSearch (log storage), and Graylog itself (processing and UI).

Step 1: Generate Password Hashes

Graylog needs hashed passwords for its root user and secret key:

1
2
3
4
5

# Generate a password secret (256-bit hex string)
openssl rand -hex 32

# Hash your root password
echo -n "your_secure_password" | shasum -a 256

Step 2: Create the Docker Compose File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# docker-compose-graylog.yml
version: "3.8"

services:
  mongodb:
    image: mongo:7.0
    container_name: graylog-mongo
    volumes:
      - mongo-data:/data/db
    restart: unless-stopped

  opensearch:
    image: opensearchproject/opensearch:2.19.1
    container_name: graylog-opensearch
    environment:
      - discovery.type=single-node
      - OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g
      - DISABLE_INSTALL_DEMO_CONFIG=true
      - DISABLE_SECURITY_PLUGIN=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data:/usr/share/opensearch/data
    restart: unless-stopped

  graylog:
    image: graylog/graylog:6.2
    container_name: graylog
    environment:
      - GRAYLOG_PASSWORD_SECRET=your_256bit_hex_secret_from_above
      - GRAYLOG_ROOT_PASSWORD_SHA2=your_hashed_password_from_above
      - GRAYLOG_HTTP_EXTERNAL_URI=http://your-server:9000/
      - GRAYLOG_ELASTICSEARCH_HOSTS=http://opensearch:9200
    ports:
      - "9000:9000"     # Web UI
      - "1514:1514"     # Syslog TCP
      - "1514:1514/udp" # Syslog UDP
      - "12201:12201"   # GELF TCP
      - "12201:12201/udp" # GELF UDP
    volumes:
      - graylog-data:/usr/share/graylog/data
    depends_on:
      - mongodb
      - opensearch
    restart: unless-stopped

volumes:
  mongo-data:
  opensearch-data:
  graylog-data:

Step 3: Configure Syslog Input

After starting Graylog, log in at http://your-server:9000 (user: admin, password: the one you set). Navigate to System > Inputs and launch a Syslog UDP input on port 1514.

Then configure your services to ship logs:

1
2
3
4
5
6
7
8

# Example: Add to any service's docker-compose
  your-service:
    image: nginx:latest
    logging:
      driver: gelf
      options:
        gelf-address: "udp://your-server:12201"
        tag: "nginx"

Step 4: Set Up Extractors and Pipelines

Graylog’s extractors pull structured data from log lines. For a typical Nginx access log:

1. Go to System > Inputs > Manage Extractors on your Syslog input
2. Select GROK Pattern extractor
3. Use the pattern: %{COMBINEDAPACHELOG}
4. This automatically extracts client_ip, method, path, status_code, response_size, and more from each log line

Graylog pipelines let you enrich and route logs:

1
2
3
4
5
6
7
8

// Graylog Pipeline Rule: Tag high-severity errors
rule "flag_critical_errors"
when
  to_long($message.response_code) >= 500
then
  set_field("severity", "critical");
  set_field("alert", true);
end

Deployment Guide: OpenSearch

OpenSearch is the most powerful option but requires the most resources. We’ll deploy OpenSearch with Dashboards and Data Prepper for log ingestion.

Step 1: Tune System Limits

OpenSearch requires increased memory mapping limits:

1
2

sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

Step 2: Create the Docker Compose File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# docker-compose-opensearch.yml
version: "3.8"

services:
  opensearch:
    image: opensearchproject/opensearch:2.19.1
    container_name: opensearch
    environment:
      - discovery.type=single-node
      - OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g
      - DISABLE_INSTALL_DEMO_CONFIG=true
      - DISABLE_SECURITY_PLUGIN=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    ports:
      - "9200:9200"
      - "9600:9600"  # Performance Analyzer
    volumes:
      - opensearch-data:/usr/share/opensearch/data
    restart: unless-stopped

  dashboards:
    image: opensearchproject/opensearch-dashboards:2.19.1
    container_name: opensearch-dashboards
    ports:
      - "5601:5601"
    environment:
      - OPENSEARCH_HOSTS=http://opensearch:9200
      - DISABLE_SECURITY_DASHBOARDS_PLUGIN=true
    depends_on:
      - opensearch
    restart: unless-stopped

  data-prepper:
    image: opensearchproject/data-prepper:2.9.0
    container_name: data-prepper
    ports:
      - "21890:21890"
      - "2021:2021"
      - "4900:4900"
    volumes:
      - ./data-prepper-config.yaml:/usr/share/data-prepper/pipelines.yaml:ro
      - ./data-prepper-pipelines.yaml:/usr/share/data-prepper/pipelines/pipelines.yaml:ro
    depends_on:
      - opensearch
    restart: unless-stopped

volumes:
  opensearch-data:

Step 3: Configure Data Prepper Pipelines

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# data-prepper-pipelines.yaml
entry-pipeline:
  delay: "100"
  source:
    http:
      path: "/log-ingest"
      ssl: false
  sink:
    - opensearch:
        hosts: ["http://opensearch:9200"]
        index: "logs-%{yyyy.MM.dd}"
        template_type: "index_template"
        trace_analytics_raw: false

Step 4: Ship Logs with Vector

Vector is an excellent log shipper that works with any backend. Install it on your host:

1
2
3

# Install Vector (Debian/Ubuntu)
curl -1sLf 'https://repositories.timber.io/public/vector/cfg/setup/bash.deb.sh' | sudo -E bash
sudo apt install vector

Configure Vector to ship to OpenSearch:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# /etc/vector/vector.yaml
sources:
  docker_logs:
    type: docker_logs
    exclude_containers:
      - vector

  journal_logs:
    type: journald
    journal_directory: /var/log/journal

transforms:
  parse_nginx:
    type: remap
    inputs:
      - docker_logs
    source: |
      if .container_name == "nginx" {
        parsed, err = parse_apache_log(.message, "combined")
        if err == null {
          .status_code = parsed.status
          .method = parsed.method
          .path = parsed.path
          .client_ip = parsed.host
        }
      }

sinks:
  opensearch:
    type: opensearch
    inputs:
      - parse_nginx
      - journal_logs
    endpoint: "http://your-server:9200"
    bulk:
      index: "logs-%{+yyyy.MM.dd}"
    auth:
      strategy: "basic"
      user: "admin"
      password: "admin"

Start Vector:

1

sudo systemctl enable --now vector

Performance and Storage Comparison

We tested all three platforms ingesting logs from 15 Docker containers (~5 GB/day) on a 4-core, 8 GB RAM server with 100 GB SSD storage.

The numbers tell a clear story. Loki uses 6–8x less disk space because it doesn’t build full-text indexes. Graylog and OpenSearch trade storage for faster full-text search. For most self-hosted setups, Loki’s efficiency wins — but if you need complex full-text queries across millions of log lines, OpenSearch is unmatched.

Which Should You Choose?

Choose Grafana Loki if:

• You already use Grafana for monitoring dashboards
• Storage cost or disk space is a concern
• You prefer label-based querying (similar to Prometheus)
• You run on modest hardware (Raspberry Pi, low-end VPS)
• You want the simplest setup and lowest maintenance overhead

Choose Graylog if:

• You need a complete log management platform out of the box
• Security and compliance are priorities (built-in RBAC, audit logging)
• You want automatic field extraction without writing parsers
• Your team prefers a dedicated log UI over Grafana
• You need stream-based log routing and processing pipelines

Choose OpenSearch if:

• You need the most powerful search and aggregation capabilities
• You have complex analytical queries across log data
• You’re already familiar with the Elasticsearch ecosystem
• You need machine learning-based anomaly detection
• Your deployment scale justifies the resource requirements

Making Them Work Together

There’s no rule saying you must pick just one. A common pattern in production is:

• Loki for day-to-day operational logging — shipping container and system logs for quick debugging
• OpenSearch for security-relevant logs — authentication events, access logs, and audit trails that need full-text search and long-term retention
• Vector as a universal log router — it can read from any source and send different log types to different backends based on content

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Vector routing: send auth logs to OpenSearch, everything else to Loki
transforms:
  route_logs:
    type: route
    inputs:
      - all_logs
    route:
      auth: '.source == "auth" || .source == "sshd"'
      default: 'true'

sinks:
  loki_default:
    type: loki
    inputs:
      - route_logs.default
    endpoint: "http://loki:3100"
    encoding:
      codec: json

  opensearch_auth:
    type: opensearch
    inputs:
      - route_logs.auth
    endpoint: "http://opensearch:9200"
    bulk:
      index: "auth-%{+yyyy.MM.dd}"

This hybrid approach gives you Loki’s storage efficiency for high-volume routine logs while keeping security-critical data in OpenSearch’s powerful full-text search engine.

Retention and Cleanup

Regardless of which platform you choose, configure retention policies early:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# Loki: Set in limits_config (see config above)
# limits_config.retention_period: 744h

# OpenSearch: Use Index State Management
# Create a policy in OpenSearch Dashboards:
# {
#   "policy": {
#     "description": "Delete logs after 30 days",
#     "default_state": "hot",
#     "states": [
#       {
#         "name": "hot",
#         "actions": [],
#         "transitions": [
#           {
#             "state_name": "delete",
#             "conditions": { "min_index_age": "30d" }
#           }
#         ]
#       },
#       {
#         "name": "delete",
#         "actions": [
#           { "delete": {} }
#         ]
#       }
#     ]
#   }
# }

# Graylog: Set in System > Indices > Index Set Configuration
# Max number of indices: 30
# Rotation period: P1D (daily)

Final Thoughts

The self-hosted log management landscape in 2026 offers genuinely excellent options at every scale. Loki has become the default choice for Grafana-centric monitoring stacks thanks to its minimal resource footprint. Graylog remains the most complete turnkey solution with its built-in processing pipelines and dashboards. OpenSearch delivers unmatched search power for teams that need deep analytical capabilities.

All three are free, open-source, and keep your data under your control. The best choice depends on your existing infrastructure, team expertise, and the volume and type of logs you need to manage. Start with Loki if you’re unsure — it’s the easiest to deploy, cheapest to run, and scales gracefully as your needs grow.

Frequently Asked Questions (FAQ)

Which one should I choose in 2026?

The best choice depends on your specific requirements:

• For beginners: Start with the simplest option that covers your core use case
• For production: Choose the solution with the most active community and documentation
• For teams: Look for collaboration features and user management
• For privacy: Prefer fully open-source, self-hosted options with no telemetry

Refer to the comparison table above for detailed feature breakdowns.

Can I migrate between these tools?

Most tools support data import/export. Always:

1. Backup your current data
2. Test the migration on a staging environment
3. Check official migration guides in the documentation

Are there free versions available?

All tools in this guide offer free, open-source editions. Some also provide paid plans with additional features, priority support, or managed hosting.

How do I get started?

1. Review the comparison table to identify your requirements
2. Visit the official documentation (links provided above)
3. Start with a Docker Compose setup for easy testing
4. Join the community forums for troubleshooting