A simpler ELK stack alternative

ELK is the most common way a small team acquires a part-time job it never wanted.

Elasticsearch, Logstash, and Kibana have answered “how do I search my logs” for over a decade. The stack is powerful, well documented, and assumed by a mountain of tooling. It is also four services you now operate.

What running ELK involves

The minimum deployment:

• Elasticsearch — storage and search. A JVM application that wants a lot of memory and real tuning.
• Logstash — ingest and transformation. Another JVM application, historically the heaviest piece.
• Kibana — the web UI. A Node application.
• Beats — Filebeat on every host, to collect the logs in the first place.

Four moving parts, two JVMs, and five failure modes you have never met:

Heap sizing. Elasticsearch wants about half your RAM as heap, capped near 32GB for compressed pointers. Get it wrong and GC pauses stall ingest.

Shard management. Too many shards exhausts cluster state. Too few limits parallelism. Index lifecycle management helps, and it is one more thing to configure.

Mapping explosions. One high-cardinality field — a request ID will do it — blows up the index mapping and takes the cluster down. This is a common way ELK dies.

Disk watermarks. At 85% disk, Elasticsearch stops allocating shards. At 95% it marks indices read-only. Ingest stops, and often nothing tells you.

Version coupling. Elasticsearch, Logstash, Kibana, and Beats all want compatible versions. Every upgrade is a coordinated event.

None of that is unfair. Elasticsearch is a distributed search engine, and distributed search engines are complicated. The question is whether you need one to read your logs.

Central Logging’s answer

One binary. No JVM. No cluster. No separate UI service. No ingest pipeline.

./centrallogging

That gives you an HTTPS server with an auto-issued TLS certificate, a web UI, an ingest API, alerting, cron monitoring, and uptime checks. Logs land in SQLite files on local disk.

SQL instead of the Elasticsearch DSL

People notice this difference first. To aggregate in Elasticsearch you either filter with KQL and build a Kibana visualization, or you hand-write a JSON aggregation body.

Here is the same question in SQL:

SELECT
    json_extract(msg, '$.request_uri') AS uri,
    COUNT(*)                           AS hits,
    ROUND(AVG(json_extract(msg, '$.request_time')), 3) AS avg_seconds
FROM logs
WHERE json_valid(msg)
GROUP BY uri
HAVING hits > 10
ORDER BY avg_seconds DESC
LIMIT 25;

No DSL. No visualization builder. Know SQL and you already know this tool. Full-text search handles the cases where SQL is ceremony.

Storage you can reason about

Central Logging writes to SQLite databases with WAL enabled and batched writes. Four consequences:

• Backup is cp. Or rsync, or a filesystem snapshot. No repository to register.
• No shards, no watermarks, no cluster state. The failure modes above do not exist here.
• No mapping explosion. JSON is stored as text and read with json_extract. A high-cardinality field costs you disk, not cluster health.
• Open format. Any SQLite client reads the files. Getting your data out is not a project.

Migrating from ELK

Filebeat → point its HTTP output at the ingest endpoint, or replace it with the CL Agent for system logs.

Logstash → most Logstash pipelines exist to parse unstructured text into fields. You have two options. Log JSON at the source and skip parsing (see the Nginx and Python guides). Or parse at ingest with a per-source JavaScript transform.

Grok patterns do not port. A large grok investment means real migration time. Spend it making the source emit JSON instead. That is less work than it sounds, and it deletes the parsing step for good.

rsyslog forwarding → see the rsyslog guide for omhttp with disk-backed queueing.

Run both stacks in parallel until you trust the new one.

What ELK does that this does not

• Horizontal scale. Elasticsearch shards across a cluster and swallows volumes this cannot approach.
• Kibana dashboards. A powerful visualization layer with no equivalent here.
• Machine learning and anomaly detection. Missing.
• Mature RBAC and multi-tenancy. Missing.
• Non-log workloads. Elasticsearch also powers product search, APM, and security analytics.
• A large ecosystem. Hundreds of Beats modules and Logstash plugins.

Weigh that fifth point heavily. Already running Elasticsearch for something else? Then logs cost you almost nothing extra, and this page does not apply to you.

What you get instead

• One process to install, monitor, update, and back up.
• SQL as the query language.
• Alerting to Slack and Telegram, built in.
• Cron, website, and host monitoring in the same binary.
• Prometheus scraping with charts.
• Predictable memory and no GC tuning.
• One fixed cost instead of an open-ended ops commitment.

Who should choose which

Stay with ELK if you log more than 10GB/day. Or if you already run Elasticsearch for something else. Or if you need Kibana dashboards, clustering, or RBAC. Or if you have years of grok and Beats config.

Switch if you deployed ELK only to read logs. Or if the cluster has demanded more attention than your application. Or if you are a small team with no platform engineer. Or if the memory footprint dwarfs the problem.

Try it

The free download is the full product. No credit card, no time limit.

Run it beside your cluster. Tee a real log stream into it. See what you miss.

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