Graylog2 Logging and Alerting with RabbitMQ and NEsper

Graylog2 logging and alerting splits into fixed stages: .NET services publish GELF messages to a RabbitMQ queue, Graylog2 consumes that queue and indexes for search, and Nesper evaluates the same event stream for patterns worth waking someone. Graylog’s GELF UDP input listens on port 12201, while the GELF AMQP input, per documentation accessed October 2026, takes a broker hostname, virtual host, prefetch count, queue, exchange and routing key. Nesper for .NET is feature-equivalent to the same-version Esper engine. Failures land in the publisher or in the alert rule.

Why Graylog2 logging and alerting puts a broker in the middle

Graylog2 logging and alerting needs a broker because plain syslog caps a message at 1024 bytes. Graylog documentation puts it as “Limited to length of 1024 bytes. Inadequate space for payloads like backtraces.” (GELF Format page, accessed October 2026). GELF payload spec 1.1, dated November 2013, substitutes typed fields, compression and chunking.

Transport	Port in Graylog examples	Delivery	Failure mode
GELF UDP	12201	Fire and forget	Lossy; chunks must land within 5 seconds
GELF TCP	12201	Ordered, null byte delimited	No compression
GELF HTTP	12202	POST per message, 202 Accepted	65536-byte max chunk
GELF AMQP	5672 in the Log4Rabbit sample	Queued and acknowledged	You own the broker config

The .NET end of that table is where wiring gets fiddly; Log4Net to RabbitMQ logging covers the appender. Log4Rabbit, a RabbitMQ appender for log4net created on June 22, 2012, defaults to port 5672, exchange “logs” and a 5-second flush interval (GitHub README, accessed October 2026).

Which RabbitMQ queue type should hold the Graylog2 AMQP input

The Graylog2 AMQP input should consume a quorum queue: RabbitMQ defaults it to 3 members and drops a message after 20 redeliveries. That limit has been the default since RabbitMQ 4.0 (rabbitmq.com, accessed October 2026).

1. Declare the queue with x-queue-type set to quorum at creation time; a policy cannot set it later.
2. Enable publisher confirms. A confirm arrives only after replication to a quorum of members, the only proof your app did not drop logs.
3. Use manual acknowledgements with per-consumer prefetch; quorum queues reject global QoS.
4. Set dead-letter-strategy to at-least-once with a dead-letter exchange, and switch to streams past about 5 million messages of backlog.

Classic queue mirroring was removed in RabbitMQ 4.0, so any runbook saying “mirrored” describes software that no longer ships.

What Nesper adds to Graylog2 alerting

Nesper for .NET is feature-equivalent to the same-version Esper engine, so EPL written for Esper runs unchanged on the CLR (EsperTech, documentation page dated February 2024).

EsperTech puts it plainly: “Nesper and Esper share the same grammar.” (NEsper for .NET page, dated December 2023). That lets a team count failures inside a sliding window or fire on the first error of a burst, work that field-level stream rules do not do alone. The engine is GPL-licensed, which matters when rules ship inside closed-source code.

Its regular build tests against ADO.NET and ODBC drivers including MySQL and Microsoft SQL Server 2005 (EsperTech, December 2023), so stored history in a rule is a supported path. Exception-shaped errors feed this stage well, and .NET exception handling is the upstream half of that job.

Where Graylog2 logging and alerting breaks first

Backlog breaks this pipeline first: RabbitMQ documentation points to streams rather than quorum queues past about 5 million messages in one queue (rabbitmq.com, accessed October 2026).

• Chunk windows: all chunks must arrive within 5 seconds, a message cannot exceed 128 chunks, datagrams cap at 65536 bytes, and some Graylog components stop at 8192 bytes (Graylog GELF documentation, October 2026).
• Confirm coverage: without publisher confirms, a quiet dashboard proves the queue is idle, not that your app logged.
• Stuck consumers: quorum queues return unacknowledged messages after a timeout; RabbitMQ shows consumer_timeout = 1800000 milliseconds in rabbitmq.conf.
• Version drift: Graylog 1.0.0 shipped February 19, 2015, and Graylog2 0.20.2 in May 2014 reintroduced AMQP support, so pin docs to your version.

When the audit trail matters more than live search, logging updates to a database stays the plainer route and the easier one to explain to an auditor.

Graylog2 logging and alerting FAQ

Do I need RabbitMQ between a .NET service and Graylog2?

Only when you want buffering, replay or a second consumer. Graylog takes GELF over UDP, TCP or HTTP directly, and its HTTP input answers 202 Accepted as soon as a message is queued for processing (Graylog documentation, accessed October 2026). A broker earns its place when producers burst or when Graylog restarts.

Should the Graylog2 AMQP input queue be a quorum queue?

For anything you would miss, yes. A quorum queue replicates to 3 members by default, and since RabbitMQ 4.0 a message redelivered more than 20 times is dropped or dead-lettered (rabbitmq.com, accessed October 2026). Classic mirrored queues were removed in RabbitMQ 4.0, so a runbook saying “mirrored” is out of date.

Is Nesper still a reasonable alerting engine for .NET?

It fits rules that count events over time instead of matching one message. Nesper for .NET is feature-equivalent to the same-version Esper engine and shares its grammar, so EPL written for Java runs on the CLR (EsperTech, pages dated December 2023 and February 2024). The GPL license matters if those rules ship inside closed-source code.

What transport should a .NET app use to reach Graylog2?

AMQP if you can run a broker, UDP if you cannot. GELF over UDP can be chunked, but every chunk has to arrive within 5 seconds and a message cannot exceed 128 chunks (Graylog documentation, accessed October 2026). GELF over TCP needs a null byte between messages and carries no compression.