This week we’re in Step 7 (of 12) Click here to play. One participant will win a $100 Amazon Gift Certificate . Jump in! There’s still time to play. For each step you respond to, you’ll get another change to win. Our top contenders are @shoothub and @gsmith currently vying for the most chances to win.
Tell how you configured your source. What language did you use to build your template or rules?
What more would you like to learn about source configuration? Be specific.
Thank you to the community members who have been playing the User Journey Game. Keep it going! 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 chance to win.
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. TO play, respond to this post with your response to this week’s questions.
Linux devices:
You usually use rsyslog as it’s most used syslog daemon on linux systems. If you can, always use RFC 5424 syslog format, as it contains correct timezone definition, so time is correctly detected by graylog.
I’m a big fan of Ansible. So every time I want to deploy new or updated template for rsyslog, filebeat or nxlog to linux systems I use Ansible playbook.
Windows devices
For Windows you have more options, I’ve always used sidecar, because is much more easier to configure templates centrally, than manually on every host.
Always setup correct time and date synchronization using NTP on source device
Always setup correct timezone, use either local timezone, or UTC
Check your firewall to allow connection from device to graylog server, specific port and protocol
Think and configure graylog input and index before sending logs from devices
For testing purposes I would suggest to create dummy index and input with low retention to test new type of devices.
Don’t try to send new messages to production indexes (inputs), if you you are on POC and testing phase. You can end up with unnecessary fields which is not possible to remove.
Thanks for sending this along. Do you want to include it with your interview article? I think this would be awesome, too, as a stand-alone entry in the community. What are your thoughts?
