Load Balancer Integration
When running multiple Graylog servers a common deployment scenario is to route the message traffic through an IP load balancer. By doing this we can achieve both a highly available setup, as well as increasing message processing throughput, by simply adding more servers that operate in parallel.
Load Balancer State
However, load balancers usually need some way of determining whether a backend service is reachable and healthy or not. For this purpose Graylog exposes a load balancer state that is reachable via its REST API.
There are two ways the load balancer state can change:
- due to a life cycle change (e.g. the server is starting to accept messages, or shutting down)
- due to manual intervention via the REST API
/api/
(e. g. https://graylog.example.com/api/
).To query the current load balancer status of a Graylog instance, all you need to do is to issue a HTTP call to its REST API:
GET /api/system/lbstatus
The status knows three different states, ALIVE
,
and THROTTLED
DEAD
, which is also the
response of their source. Additionally, the same information is reflected in the HTTP status codes: If the state is text/plain
ALIVE
the return code will be 200 OK
. For
it will be THROTTLED
429 (too many requests)
. And for
it will be DEAD
503 Service unavailable
. This is done to make it easier to configure a wide range of load balancer types and vendors to be able to react to the status.
The resource is accessible without authentication to make it easier for load balancers to access it.
To programmatically change the load balancer status, an additional endpoint is exposed:
PUT /api/system/lbstatus/override/alive
PUT /api/system/lbstatus/override/dead
PUT /api/system/lbstatus/override/throttled
Only authenticated and authorized users are able to change the status; in the currently released Graylog version this means only admin users can change it.
Web Interface
It is possible to use the Graylog web interface behind a load balancer for high availability purposes.