October 21, 2021
10am-5pm CT

Step 5: Look Around -- Get the first data in

Ok, you’ve installed and configured Graylog and your software dependencies. Now it’s time to check out your set up and get that first data in.

In Step 5,post your experiences in checking your installation and configuring by getting the first data in.

  • Did you notice any issues related to your Graylog and software contingencies/dependencies after the you set up every thing and got the first data in?
  • Was the output what you expects?
  • Did you need to go back and reconfigure any software? Or did everything run smoothly?
  • What lessons did you learn from this step that you can share with the community? Any “gothchas?”

Thank you to the community members who have been playing the User Journey Game. Keep it going! Our currently top participant is shoothub with four entries. Remember, each submission is an entry in the User Journey raffle. The winner whose name is drawn will receive a $100 Amazon Gift Certificate.

Posting a valid++ response to this question is worth 1 point.

For EACH STEP (there are 12 in all) in Graylog User’s Journey in which you post a valid++ response, you get a chance to win a $100 Amazon Gift Certificate! One lucky winner will have up to 12 chances to win. Go to “From the Graylog Book” to find the steps.

++Validity of response is subject to the community manager’s approval.

My first data were syslog logs from network devices (switches, firewalls, iDRAC), because it wasn’t necessary to install and configure any agent. I’ve just one Syslog UDP input in graylog and setup correct setting on network device and wait for data to come in, so it was easy without problems. Problems started after we try to use port 514 for input in graylog. Because graylog runs as a normal user (best practice), it couldn’t listen on port lower than 1024. Graylog FAQ How can I start an input on a port below 1024? was very helpful, we configured iptables, but we have some troubles with some devices that didn’t send logs. So we finally changed port from 514 to 1514, reconfigured network devices, and everything started working like magic.

We needed discover problems in some network switches, because there were lot of disconnections from some ports, and we don’t know exactly at what time did it happen. So our expected output was to create dashboard with graph with number of connection and disconnection on ports and find which port is problematic. So we first needed to parse cisco logs using extractors to create required fields. This nice blog post from @jan helped us a lot:

After that we created required widgets and dashboard and created nice overview of cisco switches. We finally also found a problem dockstation device which created a lot of disconnections on one switch port.

Nothing is so smooth especially in beginning phase. But it’s OK, because every mistake, problem, or request is a great opportunity to study more and be more confident in logging topic. In your case, we needed to reconfigure our network devices to send syslog messages to different port from 514 to 1514. After that, next steps were smooth.

Every problem or mistake is resolvable, if you try hard. Don’t give up, and keep goining. Sometimes you use trial and error method, but it’s completely fine. Don’t forgot to read graylog docs carefully, so if you use third-party sources, howtos, videos, use it only for ideas.

In our cisco switches logging, we discovered, that source field was extracted from messages, because our cisco switches don’t send hostname in syslog message. We fixed it using simple pipeline rule, which replace source field by graylog internal field gl2_remote_ip, which contains source IP of sending device.

rule "Set Source IP"
set_field("source", to_string($message.gl2_remote_ip));
1 Like

Thanks, shoothub, for the post!