1. Describe your incident:
I have two streams, an SSH stream and a Webserver stream. The same output is assigned to both (verified in the UI and via GET /api/streams//outputs). Messages are routed into both streams correctly and are visible in stream search, and the streams field of the webserver messages contains the correct stream ID.
However, the output only receives messages from the SSH stream. Nothing from the webserver stream is ever forwarded. A tcpdump on the node processing the webserver messages confirms that Graylog sends nothing for them.
Metrics observation
For the webserver stream, GET /api/system/metrics/namespace/org.graylog2.plugin.streams.Stream. returns only the two StreamRule..executionTime timers (approx. 240–285 events/s). The incomingMessages meter and incomingMessages.1-sec-rate gauge are missing entirely, and the UI shows no throughput for this stream. For the SSH stream and another working stream, both incomingMessages and its 1-sec-rate are present next to the rule timers.
2. Describe your environment:
-
OS Information: Ubuntu 22.04.5
-
Package Version: Graylog 7.1.9, multi-node cluster (docker env.)
-
Service logs, configurations, and environment variables:
- GRAYLOG_SERVER_JAVA_OPTS=-Xms4g -Xmx4g
- Webserver stream got his logs from Beats (Filebeat) input
- SSH stream got his logs from Syslog
- Output is GELF + TCP + TLS
3. What steps have you already taken to try and solve the problem?
- The output target works: I tested it manually, and it is actively and successfully used by the SSH stream.
- A second test output shows the same behaviour: it receives messages from the SSH stream but nothing from the webserver stream.
- Stream configuration: I cloned the stream and deleted the original, then created a completely new stream with different rules. All of them behave identically.
- Routing mechanism: I switched from stream rules to a pipeline (
route_to_stream) with the same result. Changing the rules to something that never matches stops new messages from appearing in the stream, so the routing itself works. - No errors or warnings in
server.log, and the output buffer does not overflow. - No processing failures, and the messages are indexed and searchable.
4. How can the community help?
Messages routed into the webserver stream are handed to the outputs assigned to that stream, exactly like the SSH stream, and the stream shows its throughput.