[syslog-ng] sending log messages to graylog
Szemere, László
laszlo.szemere at oneidentity.com
Tue Nov 6 15:47:33 UTC 2018
Dear Rodney,
I kindly ask you to add more effort into summarising your problem. (Most
of the time I figure out something by myself just by trying to put it into
proper words.)
Sandor asked you at least 5 questions in his previous email. You sent 2
one line answer in the last 10 minutes. Only answering the version number.
As Sandor pointed out, syslog-ng actually writes the /var/log/messages
file. If you want to forward "it's content" towards your graylog server,
than you have to actually "divert" it earlier.
In a different way: With a VERY big simplification, your log messages
takes the following route:
SOURCE -> FILTER -> DESTINATION
You have to investigate your "log" statements. Decide which one of your
logs you want to forward towards graylog, instead of the current
destination(xxx), and modify it.
(Note: Duplicating the logs, and store them on both location is also
possible, but you have to clearly express your use case.)
Best regards,
Laci
On Tue, Nov 6, 2018 at 4:19 PM, Rodney Bizzell <hardworker30 at gmail.com>
wrote:
> I am using syslog-ng version 3.5
>
> On Tue, Nov 6, 2018, 10:09 AM Sandor Geller <sandor.geller at ericsson.com
> wrote:
>
>> Hello,
>>
>> syslog-ng is configured to write that file:
>>
>> source s_sys {
>> system();
>> internal();
>> udp(ip(0.0.0.0) port(514));
>> };
>>
>> destination d_mesg { file("/var/log/messages"); };
>>
>> filter f_default { level(info..emerg) and
>> not (facility(mail)
>> or facility(authpriv)
>> or facility(cron)); };
>>
>> log { source(s_sys); filter(f_default); destination(d_mesg); };
>>
>> This should get read as:
>>
>> whatever is read from system(), internal() or udp port 514 AND f_default
>> matches on it will get written to /var/log/messages
>> You're using the same source/filter pair in
>>
>> log { source(s_sys); filter(f_default); destination(d_graylog); };
>>
>> so d_graylog should get the same messages as d_mesg. From this point the
>> configuration and your observation don't match.
>>
>> Is there anything else on your machine writing to /var/log/messages? Did
>> you remove the duplicate udp() source to make sure that the s_sys and s_net
>> sources don't collide?
>>
>> What level of troubleshooting / testing was done? Packet capture, syslog
>> trace, ... ? Which syslog-ng version was used (there was no @version in the
>> config), what warnings/ errors did it emit during startup and later?
>>
>> Regards,
>> Sandor
>>
>> On 11/06/2018 03:52 PM, Rodney Bizzell wrote:
>>
>> /var/log/messages
>>
>> On Tue, Nov 6, 2018, 9:50 AM Sandor Geller <sandor.geller at ericsson.com
>> wrote:
>>
>>> Hello,
>>>
>>> On 11/06/2018 01:57 PM, Rodney Bizzell wrote:
>>>
>>> If you look to the bottom of the config I have made changes to
>>> source(sys) pointing it to my graylog server. I am reading through the
>>> documentation I am thinking that should send the logs to graylog server I
>>> am just asking I apologize if I am making assumptions. The documentation
>>> isn't always clear, so I am just asking if I want to send /var/logs to my
>>> graylog server do I need to add a new source for var log?
>>>
>>>
>>> There is no such thing as /var/logs, please be much more precise. It
>>> doesn't make any sense to read back contents of files written by syslog-ng
>>> itself, such potential logging loops should get avoided anyway. If you've
>>> got additional stuff under /var/log (some apps could log there directly)
>>> then you can add these files as sources to process them by syslog-ng. Your
>>> current configuration doesn't contain such source definitions.
>>>
>>> options {
>>>
>>> flush_lines (0);
>>>
>>> time_reopen (10);
>>>
>>> log_fifo_size (250000);
>>>
>>> chain_hostnames (off);
>>>
>>> use_dns (no);
>>>
>>> use_fqdn (no);
>>>
>>> create_dirs (no);
>>>
>>> keep_hostname (yes);
>>>
>>> };
>>>
>>>
>>> source s_sys {
>>>
>>> system();
>>>
>>> internal();
>>>
>>> udp(ip(0.0.0.0) port(514));
>>>
>>> };
>>>
>>>
>>> source s_net {
>>>
>>> udp(ip(0.0.0.0) port(514));
>>>
>>> tcp(ip(0.0.0.0) port(514) max-connections(256));
>>>
>>> };
>>>
>>> Note: you're using the same udp() source twice (the first occurence is
>>> in the s_sys source) so one of them won't receive messages
>>>
>>> destination d_cons { file("/dev/console"); };
>>>
>>> destination d_mesg { file("/var/log/messages"); };
>>>
>>> destination d_auth { file("/var/log/secure"); };
>>>
>>> destination d_mail { file("/var/log/maillog" flush_lines(10)); };
>>>
>>> destination d_spol { file("/var/log/spooler"); };
>>>
>>> destination d_boot { file("/var/log/boot.log"); };
>>>
>>> destination d_cron { file("/var/log/cron"); };
>>>
>>> destination d_kern { file("/var/log/kern"); };
>>>
>>> destination d_mlal { usertty("*"); };
>>>
>>>
>>>
>>> destination d_graylog {
>>>
>>> tcp("graylog.server”
>>>
>>> port (12201)
>>>
>>> );
>>>
>>> };
>>>
>>>
>>>
>>> filter f_kernel { facility(kern); };
>>>
>>> filter f_default { level(info..emerg) and
>>>
>>> not (facility(mail)
>>>
>>> or facility(authpriv)
>>>
>>> or facility(cron)); };
>>>
>>> filter f_auth { facility(authpriv); };
>>>
>>> filter f_mail { facility(mail); };
>>>
>>> filter f_emergency { level(emerg); };
>>>
>>> filter f_news { facility(uucp) or
>>>
>>> (facility(news)
>>>
>>> and level(crit..emerg)); };
>>>
>>> filter f_boot { facility(local7); };
>>>
>>> filter f_cron { facility(cron); };
>>>
>>>
>>> log { source(s_sys); filter(f_kernel); destination(d_cons); };
>>>
>>> log { source(s_sys); filter(f_kernel); destination(d_kern); };
>>>
>>> log { source(s_sys); filter(f_default); destination(d_mesg); };
>>>
>>> log { source(s_sys); filter(f_auth); destination(d_auth); };
>>>
>>> log { source(s_sys); filter(f_mail); destination(d_mail); };
>>>
>>> log { source(s_sys); filter(f_emergency); destination(d_mlal); };
>>>
>>> log { source(s_sys); filter(f_news); destination(d_spol); };
>>>
>>> log { source(s_sys); filter(f_boot); destination(d_boot); };
>>>
>>> log { source(s_sys); filter(f_cron); destination(d_cron); };
>>>
>>>
>>>
>>>
>>> log { source(s_net); destination(d_graylog); };
>>>
>>> log { source(s_sys); filter(f_default); destination(d_graylog);};
>>>
>>> log { source(s_sys); filter(f_kernel); destination(d_graylog); };
>>>
>>> log { source(s_sys); filter(f_default); destination(d_graylog); };
>>>
>>> Note: the last line is a duplicate of the entry two lines earlier so
>>> will duplicate the data sent to d_graylog so it should get deleted. Also
>>> note that the intersection of the f_kernel and f_default filters isn't
>>> empty so some kernel messages would be sent twice to d_graylog.
>>>
>>> Regards,
>>> Sandor
>>>
>>> ____________________________________________________________
>>> __________________
>>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>>> Documentation: http://www.balabit.com/support/documentation/?
>>> product=syslog-ng
>>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>>
>>>
>>
>> ______________________________________________________________________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>
>>
>> ____________________________________________________________
>> __________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation: http://www.balabit.com/support/documentation/?
>> product=syslog-ng
>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>
>>
> ____________________________________________________________
> __________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation: http://www.balabit.com/support/documentation/?
> product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20181106/bb683d63/attachment-0001.html>
More information about the syslog-ng
mailing list