A lightweight Graylog alternative

You wanted to search your logs. You got a distributed system to operate.

That is why people look for a Graylog alternative. Graylog is a capable open-source platform, and teams that need stream routing, role-based access control, and enterprise integrations get their money’s worth from the complexity. Most teams do not need any of that.

The dependency problem

A Graylog deployment runs three services at minimum:

• Graylog — a JVM application.
• OpenSearch or Elasticsearch — the search and storage backend, also a JVM application.
• MongoDB — configuration and metadata.

Each one has its own memory tuning, its own upgrade path, and its own failure modes. OpenSearch will eat as much heap as you give it. An unhealthy cluster stops ingestion cold — yellow shards, a full disk watermark, a mapping explosion from one high-cardinality field.

That is a sysadmin job. A large org with a platform team can absorb it and gets real capability back. A three-person team gets a second job.

Central Logging is one executable. No database to install. No JVM. No cluster. No Docker. No config file to write before it runs.

./centrallogging

That starts an HTTPS server with an auto-issued TLS certificate, a web UI, and an ingest API. Deploy has the details, and there are not many.

Side by side

Storage: SQLite instead of a search cluster

Storing logs in SQLite sounds like a limitation. It is mostly a simplification.

Central Logging writes to SQLite databases with WAL enabled, batched on ingest. That buys you four things:

• Backups are file copies. No snapshot API, no repository config, no cluster coordination.
• No shards. Nothing to rebalance, no yellow cluster status, no watermark that quietly stops writes.
• An open format. Any SQLite client opens your data. Leaving needs no export step.
• SQL queries. Aggregation, joins, and window functions included.

The ceiling is real. This design targets teams under about 10GB/day and does not shard across machines. Ingesting terabytes? Run OpenSearch. That is the job it was built for, and this is not a substitute.

Query syntax

Graylog uses Lucene syntax. Lucene matches well and aggregates poorly, so analytical questions turn into a pipeline or an aggregation widget.

Central Logging gives you SQL:

SELECT
    json_extract(msg, '$.host')     AS host,
    json_extract(msg, '$.severity') AS severity,
    COUNT(*)                        AS events
FROM logs
WHERE json_valid(msg)
  AND json_extract(msg, '$.severity') IN ('err', 'crit', 'alert', 'emerg')
GROUP BY host, severity
ORDER BY events DESC;

And full-text search when SQL is more than you need:

+description:water -light beer
description:/wat.*/

Saved queries, CSV export, field extraction, multi-source search, and log tailing are all built in.

Ingest: your shippers mostly stay put

Graylog takes logs over GELF or syslog inputs. Central Logging takes them over HTTP.

Forwarding with rsyslog? Change one output action. The rsyslog guide covers omhttp with disk-backed queueing, so a restart loses nothing.

Running Graylog Sidecar with Filebeat? Swap in the CL Agent for system logs, or point Filebeat’s HTTP output at the ingest endpoint.

Applications emitting GELF? They already produce structured JSON, and the ingest API takes it as-is:

curl -X POST https://logs.example.com/api/v1/ingest_logs/YOUR-SOURCE-TOKEN \
    --data-binary @mylogs.json

Things Graylog does that this does not

A fair comparison lists these:

• Clustering and high availability. Graylog scales horizontally. Central Logging is one process on one server. Backups and a standby are your mitigation, and that is a real downgrade in resilience.
• Role-based access control and multi-tenancy. Need per-team log isolation with granular permissions? Graylog has it. This does not.
• Processing pipelines. Graylog pipeline rules are a full routing and enrichment language. Central Logging has per-source JavaScript transforms. Those parse and filter. They do not route.
• Extractors and content packs. A large library of prebuilt parsers.
• Archiving to cold storage. Enterprise Graylog tiers old data out.
• Enterprise support. A company answers the phone.

What you get in exchange

• One thing to install, update, and back up. -update replaces the binary in place.
• Monitoring included. Cron monitoring, website monitoring, host monitoring, and Prometheus scraping live in the same binary. Graylog users run those separately.
• No JVM tuning. No heap sizing, no GC pauses, no Xmx arguments.
• Predictable memory. It does not grow to fill the machine.
• One fixed cost.

Who should choose which

Stay with Graylog if you need HA, RBAC, multi-tenancy, or high ingest volume. Or if your team already knows OpenSearch. Or if a support contract is a requirement.

Switch if you picked Graylog to self-host rather than for its enterprise features. Or if your team spends more time maintaining the logging stack than using it. Or if you are under 10GB/day and want cron and uptime monitoring without adding more services.

Try it

The free download is the complete product.

Install it next to your Graylog instance. Fork a copy of your log stream at it. Compare the queries you run every week. Then decide.

14-day refund if you buy and it does not fit. See Deploy to get started.