// service / cluster architecture
Graylog clusters built to lose a node and keep working
High availability is not "run two of everything". It is knowing exactly what happens to every message when a specific component fails — and designing so the answer is acceptable.
- graylog:
- >= 2 nodes behind load balancer
- search:
- >= 3 nodes, replicas >= 1
- mongodb:
- 3-member replica set
- journal:
- sized to absorb backend outages
- lb.health:
- /api/system/lbstatus
- validation:
- documented failover drills
A Graylog cluster has three independent layers, and each one fails differently. Graylog nodes are largely stateless apart from their on-disk message journal. The search layer holds your indexed data and needs replicas to survive a node loss. MongoDB holds configuration and needs a quorum. We design each layer for your failure budget and then prove it by failing nodes on purpose.
The ingestion path matters as much as the servers behind it. UDP syslog cannot be retried by the sender, some cloud load balancers cannot forward UDP at all, and a collector without a buffer will drop data while a node restarts. We choose protocols, load balancing and buffering together.
// scope
Cluster design covers
Load-balanced ingestion
TCP/UDP load balancing appropriate to your provider, health checks against Graylog's load-balancer status endpoint, TLS termination or passthrough.
Graylog node tier
Two or more Graylog nodes with shared configuration, correctly sized journals and a clear processing capacity per node.
Search tier
Data Node or OpenSearch clusters with dedicated roles where it pays off, replica counts and shard sizing matched to retention.
MongoDB replica set
Three-member replica sets with authentication and TLS, placed across failure domains.
Failure domains
Spreading nodes across hosts, racks or availability zones — and understanding the latency and cost trade-offs of doing so.
Failure testing
Controlled node, disk and network failures before go-live, with documented behaviour for each scenario.
// deliverables
What you receive
- Cluster architecture with failure-mode analysis per layer
- Deployed cluster, reproducible from code
- Load balancer and collector configuration tuned for failover
- Failover test report: what was failed, what was observed
- Capacity model showing when the next node is needed
// faq
Common questions
How many nodes does a Graylog cluster need?
For real high availability: at least two Graylog nodes, three search nodes (so the search cluster can keep a quorum) and a three-member MongoDB replica set. These roles can share hosts in smaller clusters. Larger environments separate them for predictable performance.
Does HA mean zero message loss?
Not automatically. Loss depends on the protocol (UDP has no delivery guarantees), collector buffering, journal sizing and load balancer behaviour. We design the full path and tell you where the remaining risk is.
Can the cluster span multiple data centers?
It can, but search and MongoDB clusters are sensitive to latency between members. Stretching across regions is usually the wrong trade-off; zones within one region or a separate DR environment are often better. We model the options with you.
// related services
Independent service provider — not affiliated with Graylog, Inc. Software licensing is subject to the applicable vendor license. Licensing notes.
You have logs. We build and operate the infrastructure that makes them useful.
Tell us about your environment. An engineer will reply with a first architecture outline.