Syslog on UDP `

(Plotniku) #1


Just installed graylog 2.3. working with elastic search 5.5.2.
Web interface works, also i managed to have a graylog cluster working with two nodes.
issue - started the Syslog UDP input on port 1025 (as it does not allow to start on 514 on the web interface due to permissions). netstat shows that linux listens for logs on ::1025 and UDP6. strange. i have also tried to configured input on specific IP address - an IPv4 address, no luck, still shows that linux is listening on IPv6.
i send a bunch of logs to graylog, however, nothing is being shown in the web page.

Sergiu Plotnicu

(Jochen) #2

That’s expected on a dual-stack system. Do you have any specific problems with that?

What are you sending exactly?

(Plotniku) #3


I send syslog from Cisco firewall also from a network switch


(Jochen) #4

Try using a Raw/Plaintext UDP input instead of a Syslog UDP input.

Also make sure that all devices are configured correctly and send their syslog messages to port 1025/udp of your Graylog node(s).

Does it work when sending a hand-crafted syslog message to Graylog?

# echo "<0>1 $(date --iso-8601=seconds -u) - - - - test message" | nc -u -w0 1025"


I don’t want to hijack this topic, but I have exactly the same problem as described by the original poster. I just did a fresh install of graylog-server-2.3.1-1, with elasticsearch-5.5.2, and mongodb-org-server(all on the same machine). On my old syslog machine I have the exact same setup and config except it’s one graylog version lower. With this new machine I started out with a new clean config.

I’m receiving logs on my syslog machine where graylog is installed, in my syslog config I have it set that the logs coming in also get forwarded to localhost 51400/udp. I then created a syslog upd input on port 51400/udp. I see graylog processing incoming messages:

2e867593 / syslogmachine In 17 / Out 17 msg/s.
The journal contains 17 unprocessed messages in 1 segment. 16 messages appended, 16 messages read in the last second.

There is also a java process listening on 51400/udp. When I do a tcpdump I also see syslog messages going to 514/udp on localhost

I tried doing as you advised in the previous post, do use Raw/Plaintext UDP as input, but that makes no difference. I don’t have any errors in the graylog server logs that would point to a problem. Any ideas, because I ran out of them?

(Jochen) #6

Are you able to send a manually crafted valid syslog message to the Graylog Syslog UDP input as described in my previous post?

Also make sure to check the logs of your Graylog and Elasticsearch nodes.


I was able to do that but I didn’t see anything come up in the graylog server.log, neither was there anything strange in the elasticsearch logs. I thought since everything seems to be working right I could still try to start from zero with my elasticsearch db. So I stop both graylog-server and elasticsearch, removed all the elasticsearch db files. Then I started up elasticsearch again and graylog-server. The elastic search indices got recreated and now Im able to see my forwarded logs in graylog. I can also see test messages appearing by using the command as you said.

However my setup is a bit different, I have my clients logging to syslogmachine(on udp/514), then on the syslog machine I have my logs fowarded to localhost on 514/udp, and my input running on 51400/udp. Since the input fails to start when I try and run it on 514/udp Because to services can’t run on the same port. But anyhow my problem is solved :slight_smile: seems there must of been something wrong in the or corrupted in the elasticsearch indices? Don’t know enough about elasticsearch to know what the problem now was. Since my elasticsearch logs didn’t show any errors and the cluster was green according to graylog and when checking the elastich search cluster status via curl.

Although one more question, is there preferred method for input for syslog using syslog UDP or Raw/Plaintext UDP?

(system) #8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.