Centralising logs — Elasticsearch, Logstash, Kibana and Graylog

The most expensive minutes of an incident are the ones an engineer spends opening an SSH session to a fifth server to look for what the first four did not have. Nothing was lost — the logs are simply written in forty different places, in different formats, in different time zones, and some of them have already rotated away.

Centralising logs solves that problem, and it is not the same problem as monitoring. Monitoring tells you that something broke; logs tell you why.

Four components and what each one is really for#

Elasticsearch — the store and the search engine. A distributed database built on an inverted index: it indexes text so that "find this string among two billion records" takes seconds rather than hours. Data is split into shards, each with a replica, and this is where the project's main cost is born — the index is larger than the log it describes.

Logstash — the processing pipeline. Three stages: input (where it comes from), filter (how it is broken apart) and output (where it goes). The filter stage is where a line of text becomes fields — with grok, or, where the format is fixed, with the considerably faster dissect.

Logstash runs on the JVM and is heavy. In practice it is therefore not deployed as an agent: a light shipper goes on the machines (Filebeat and its family, or plain syslog), and Logstash sits centrally, where parsing is done once.

Kibana — the reading layer. Queries, dashboards, field exploration. Kibana stores nothing itself; it is an interface onto Elasticsearch.

Graylog — a finished product on top of all of it. Graylog uses Elasticsearch or OpenSearch as its store and MongoDB for its own configuration, but it ships what you otherwise assemble by hand in a bare ELK: streams (routing the incoming flow), pipelines (rule-based processing), alerts, role-based access, and a search interface that is already built.

ELK or Graylog#

The difference is not quality. It is how much you assemble yourself:

• Graylog gets running faster when the job is the classic one — syslog from devices, application logs, search, alerts, access separated between teams. RBAC and streams are in the box.
• ELK goes further when a log stops being only a log — mixing with metrics, custom visualisation, machine learning, or when Elasticsearch is already in the estate for something else.

In our experience the choice is almost never settled by a feature list. It is settled by who will maintain the thing in month three.

What actually decides the project#

Choosing the tool is the least interesting decision. Three others are the expensive ones:

1. Retention and disk. This is the single number that either justifies the project or kills it. An indexed log is larger than the raw text, a replica doubles it, and "let's keep a year, just in case" is frequently more expensive than the incident it is insurance against. The answer is index lifecycle management: hot data on fast disk, warm on slower, cold in an archive or in object storage entirely.

2. Where the log is parsed — on write or on read. Parsing on write costs CPU but speeds up search and gives you structured fields. Parsing on read is the reverse. Choosing the wrong side shows up in month three, when going back means reindexing.

3. Time synchronisation. This sounds banal until you line up logs from two devices on one axis and discover that one of them runs two minutes behind. Correlation stands on time; NTP is part of the logging project, not a precondition of it.

Where a logging system stops#

Centralised logging is not yet a SIEM. It collects, stores and searches. A SIEM begins where correlation rules appear ("five failed authentications, then one success, from a different country"), along with threat intelligence and an incident workflow.

That layer is built separately — Wazuh, Graylog's security capabilities, or a dedicated SIEM — and stored separately: security logs carry a different retention period and frequently a tamper-resistance requirement that operational logs do not have.

That is why the two services are kept apart here: operations logging answers "what happened", and security logging and SIEM answers "who, and why".