Graylog

Centralized log management and analysis platform

Monitoring & Status ★ 8.1k stars Medium setup SSPL-1.0

Graylog is a centralized log management platform that collects, indexes, and analyzes machine data in real time. It offers powerful search, dashboards, and alerting for troubleshooting and security monitoring.

Key features

  • Centralized log collection
  • Fast full-text search
  • Dashboards and alerts
  • Stream-based routing

Pros & cons

Strengths

  • Powerful search and pipelines
  • Polished web UI

Trade-offs

  • Needs OpenSearch and MongoDB
  • Memory hungry

Graylog replaces

Last reviewed Aug 26, 2026 · 978 words

Graylog is not one container, it is three: the Graylog server, MongoDB for configuration, and OpenSearch for the log data itself. The listed minimum of 2 GB is where the trio starts; 4 GB is where it stops swapping under a normal home lab's worth of syslog and Docker output. Accept that up front and Graylog is the most complete free log platform you can self-host. Fight it and you will spend a weekend reading Java heap errors.

Three services, three different failure modes

MongoDB holds users, streams, dashboards and pipeline rules. It is small and rarely the problem. OpenSearch holds every log line and every index, and it is where all the memory goes. The Graylog server sits between them: it accepts inputs, runs your pipeline rules, and writes batches to OpenSearch. When search gets slow, look at OpenSearch. When the web UI will not start, look at MongoDB connectivity. When messages arrive but never appear, look at the Graylog journal on disk, which buffers everything the server has accepted but not yet indexed, and which fills up quietly when OpenSearch is unwell.

Three settings are non-negotiable before first boot. GRAYLOG_PASSWORD_SECRET must be at least 16 characters (I use 64 from pwgen -N 1 -s 64), and GRAYLOG_ROOT_PASSWORD_SHA2 is the SHA-256 of your admin password, produced by echo -n yourpassword | sha256sum. Skip either and the container exits. OpenSearch needs the host's vm.max_map_count raised to 262144 or it refuses to start; put that in /etc/sysctl.d/ so it survives a reboot. Then set GRAYLOG_HTTP_EXTERNAL_URI to the exact URL you will visit through your reverse proxy, or the UI loads and every API call behind it fails.

Budget 4 GB and give the two JVMs 1 GB each

Both Graylog and OpenSearch run on the JVM, and a JVM never hands heap back to the OS. Whatever you set is gone for the life of the process. On a 4 GB box, the split that works is OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g for OpenSearch and GRAYLOG_SERVER_JAVA_OPTS=-Xms1g -Xmx1g for Graylog, with MongoDB and the OS sharing the rest. Below that, OpenSearch garbage-collects in long pauses, indexing stalls, and the journal grows until it hits its own 5 GB default ceiling and starts discarding. A 2 GB machine will boot the stack; it will not keep up with a busy firewall log for long.

The licence deserves one sentence: Graylog Open is SSPL, which is not OSI-approved. For a home lab or an internal company instance that changes nothing. It only matters if you plan to sell Graylog as a hosted service.

Nothing arrives until you create an input

A fresh Graylog listens on nothing. Go to System, then Inputs, and launch two. Syslog UDP on 1514 (not 514, because the container runs unprivileged) catches routers, switches and NAS boxes; point their remote-syslog setting at it. GELF UDP on 12201 is Graylog's own structured format, and Docker's gelf log driver speaks it natively: --log-driver gelf --log-opt gelf-address=udp://graylog:12201 on a container, or the same under logging: in Compose, delivers every line with container name, image and host already parsed into fields. Publish both ports on the Graylog service in Compose or the datagrams go nowhere. For hosts where you would rather not touch Docker's log driver, Fluent Bit has a gelf output that does the same job from a 20 MB agent.

Streams and pipelines are why you pick it over Loki

Loki is cheaper to run and perfectly good for grep-with-labels. Graylog's edge is that it parses at ingest. A stream is a saved filter that messages are routed into as they arrive: all firewall logs, all authentication events, everything from the NAS. Pipelines are rules attached to streams that run before indexing: extract a field with a grok pattern, add a GeoIP lookup, drop the health-check line that fires every 10 seconds, rename a field so two vendors' logs line up. Alerts are event definitions on streams, so "more than 10 sshd failures from one source address in 5 minutes" becomes a webhook, and ntfy accepts that webhook with no glue code. Doing the same in Loki means LogQL at query time on every dashboard refresh. In Graylog it happens once, on the way in.

Retention is an index set, not a disk quota

Graylog does not watch free space. Retention lives under System, then Indices, where each index set rotates by size, time or message count and keeps a fixed number of indices. The defaults are sized for a company, not a closet, so change them on day one: rotate daily, keep 30, and you have 30 days of logs in a predictable number of files. Then watch the disk once, because OpenSearch has its own cliffs. At 85 percent used it stops allocating new shards, and at 95 percent it flips indices read-only and Graylog stops writing entirely. Recovering from that means deleting indices and clearing the read-only block by hand, which is a poor way to spend an evening.

What I'd do

Graylog on a 4 GB VM or a container host with 4 GB genuinely spare, OpenSearch on SSD, both heaps pinned at 1 GB. Syslog input on 1514 for the network gear, Docker's gelf driver for containers. One stream for auth events with a single alert on repeated failures, daily index rotation, 30 indices kept, and a calendar note to check disk usage in a month. If the box has 2 GB and cannot grow, run Loki with Grafana instead and accept grep-with-labels. Graylog at 2 GB is a machine that is always a little bit dying, and a log server you cannot trust is worse than none.

Compare Graylog

6 head-to-head comparisons.

Similar monitoring & status apps