December 2021 - syslog-ng - lists.balabit.hu

UDP drops with syslog-ng 3.24.1-1
by brian hoffman 05 Oct '22

05 Oct '22

We've been centrally logging with syslog-ng for about 5 years now. Over that time, the number of sources has grown significantly, and at some point we crossed a line where drops were happening (a quick survey of 3 million syslog packets yielded 420 unique currently sending hosts). After much research and experimentation, we've been able to get to the point where throughout the day there are 0 drops for the most part. This was achieved by installing the latest syslog-ng (not the RedHat packaged one) and creating a source for each CPU. Occasionally, though, we still have periods of drops so I'm trying to eliminate these last few. Here are some relevant configuration items:2 RedHat 7.8 VMs (load balanced via an F5) with 16GB memory and 4 CPUs each running syslog-ng-3.24.1-1.el7.x86_64.net.core.rmem_default = 212992net.core.rmem_max = 268435456 log_fifo_size(268435456); source s_network {network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp1"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp2"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp3"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp4"));network(ip("0.0.0.0") port(514) transport("tcp") max_connections(200) keep_alive(yes) so_rcvbuf(67108864));}; We are limited to UDP, unfortunately, because we do not have control over the devices/networks/etc. that are sending to us, but we have changed as many of the internal senders and destinations to TCP as we can. With a script I created to view the packets, including drops, as well as the individual RECVQs, the issue can be illustrated. Here's what things look like normally:Thu May 7 10:48:15 EDT 2020, 27003 IP pkts rcvd,26980 IP pkts sent,24951 UDP pkts rcvd, 28075 UDP pkts sent,0 UDP pkt rcv err RECVQ-1=2176RECVQ-2=0RECVQ-3=0RECVQ-4=0Thu May 7 10:48:16 EDT 2020, 28453 IP pkts rcvd,28426 IP pkts sent,26185 UDP pkts rcvd, 29180 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=0RECVQ-2=0RECVQ-3=4352RECVQ-4=0Thu May 7 10:48:17 EDT 2020, 28294 IP pkts rcvd,28276 IP pkts sent,26277 UDP pkts rcvd, 28709 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=2176RECVQ-2=0RECVQ-3=0RECVQ-4=0 The RECVQs are sparsely used, and there are no errors. Around 9pm every night, the packet counts go up significantly (probably due to backup related logs):Wed May 6 21:00:08 EDT 2020, 66382 IP pkts rcvd,66366 IP pkts sent,39405 UDP pkts rcvd, 67592 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=1595008RECVQ-2=106217088RECVQ-3=53694976RECVQ-4=31858816Wed May 6 21:00:09 EDT 2020, 69317 IP pkts rcvd,69338 IP pkts sent,44446 UDP pkts rcvd, 75958 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=13056RECVQ-2=126397312RECVQ-3=75568128RECVQ-4=41626880Wed May 6 21:00:10 EDT 2020, 71205 IP pkts rcvd,71227 IP pkts sent,43657 UDP pkts rcvd, 74603 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=920448RECVQ-2=146122752RECVQ-3=100951168RECVQ-4=52622208Wed May 6 21:00:12 EDT 2020, 69578 IP pkts rcvd,69454 IP pkts sent,124465 UDP pkts rcvd, 163367 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=13140864RECVQ-2=44494848RECVQ-3=125579136RECVQ-4=0 Still, though, it's handling it with no errors. But then at some point a threshold is reached and errors start piling up:Wed May 6 21:00:20 EDT 2020, 63177 IP pkts rcvd,63291 IP pkts sent,0 UDP pkts rcvd, 0 UDP pkts sent,38011 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=200357376RECVQ-3=292948352RECVQ-4=28890752Wed May 6 21:00:21 EDT 2020, 69501 IP pkts rcvd,69464 IP pkts sent,0 UDP pkts rcvd, 1 UDP pkts sent,42158 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=223551360RECVQ-3=314995584RECVQ-4=41735680Wed May 6 21:00:23 EDT 2020, 69962 IP pkts rcvd,69978 IP pkts sent,0 UDP pkts rcvd, 2 UDP pkts sent,43775 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=244732544RECVQ-3=338239616RECVQ-4=53858176Wed May 6 21:00:24 EDT 2020, 68266 IP pkts rcvd,68216 IP pkts sent,0 UDP pkts rcvd, 0 UDP pkts sent,43118 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=265258752RECVQ-3=360643712RECVQ-4=65362688 The common denominator I've found is that one of the RECVQs hits 536,871,424. This number seems to be almost exactly double (512 difference) the rmem.max/log_fifo_size (268,435,456). Even though there seems to be capacity in the other RECVQs, just one of those hitting that magic number seems to be enough to throw things out of whack. During this time, the CPU usage for syslog-ng also drops: top - 21:00:11 up 2 days, 8:40, 2 users, load average: 1.09, 1.41, 1.32 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 123.6 10.9 3080:46 syslog-ng top - 21:00:14 up 2 days, 8:40, 2 users, load average: 1.00, 1.39, 1.31 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 24.6 10.9 3080:46 syslog-ng top - 21:00:17 up 2 days, 8:40, 2 users, load average: 1.00, 1.39, 1.31 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 7.6 10.9 3080:47 syslog-ng As best I can tell, based on the reading I've done, the message counts we're getting should be doable, but it's still not clear exactly how to size some of these options as they relate to UDP (like log_fetch_limit, which we do not have set). Anything else I should try?

2 4

laszlo_budai's GPG key expired
by Szmytka, Piotr 03 Jan '22

03 Jan '22

Hi, It seems the GPG key used to sign Debian 10 packages has expired. The deb repository is therefore unusable. Can this be fixed please? $ curl -s http://download.opensuse.org/repositories/home:/laszlo_budai:/syslog-ng/Deb… | gpg - gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa2048 2017-08-25 [SC] [expired: 2021-12-31] F20F51628D04901AD01175013B92A8D27CFDAEDD uid home:laszlo_budai:syslog-ng OBS Project <home:laszlo_budai:syslog-ng@build.opensuse.org> Thanks! --- PIOTR SZMYTKA Senior Systems Engineer, Cloud Engineering piotr.szmytka(a)vimn.com<mailto:piotr.szmytka@vimn.com> VIMN Poland sp. z o.o. ul. Mokotowska 19, 00-560 Warsaw, POLAND [signature_1140942668]

2 1

Insider 2021-12: Humio; Log Management; Panther;
by Peter Czanik (pczanik) 16 Dec '21

16 Dec '21

Dear syslog-ng users, This is the 97th issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news. NEWS Sending logs to Panther using syslog-ng --------------------------------------- Panther is an open-source log management system, which is also available as a service for a time-limited trial. It is still in beta phase, but it looks promising. You can see the “beta” sign on its opening page: https://app.panther.support/ I tested the time-limited cloud service version, but you can also install it locally, either from Dockerhub, or you can build the containers locally from the source. Even if it is still in beta phase, Panther comes with detailed documentation. There is a notable exception: while syslog-ng is shown on some of the figures, documenting it is still to be done. This blog helps you to get started with sending logs to Panther, using syslog-ng. You can use either legacy syslog with TLS encryption (still a bit problematic) or the http() destination to send logs to the Panther HTTP API. https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-panther-us… Reducing the complexity of log management ----------------------------------------- It is easy to over-complicate log management. Almost all departments in a company need to log messages for their daily activities. However, installing several different log management and analysis systems in parallel is a nightmare both from a security and an operations perspective and wastes many resources. You cannot always reduce the number of log analysis systems, but you can reduce the complexity of log management. Let me show you, how. https://www.syslog-ng.com/community/b/blog/posts/reducing-the-complexity-of… Sending logs to Humio using the elasticsearch-http() destination of syslog-ng ------------- One of the most popular syslog-ng destinations is Elasticsearch. Humio, a log management provider, supports a broad range of ingest options and interfaces, including an Elasticsearch-compatible API. Last week, Humio announced Humio Community Edition, which provides the full Humio experience for free, with some limitations on daily ingestion and retention time. I tested the Community Edition, and it works perfectly well with syslog-ng. If you come from the Humio side, you might wonder what syslog-ng is. It is an application for high performance central log collection. Traditionally, syslog messages were collected centrally and saved to text files. Nowadays, syslog-ng acts more like a log management layer: collects log messages from hosts, saves them for long term storage, but also forwards them to multiple destinations, like SIEMs and other log analysis solutions. This way, it is enough to collect log messages only once, and syslog-ng delivers the right log messages to the right destinations in the right format, after some initial processing. Humio is available as a cloud service or self-hosted, where you can send all your logs for storage and analysis. It has an easy-to-use interface to query log messages which can be extended with further analytics possibilities from the Humio marketplace. >From this blog, you can learn how to get started with Humio and syslog-ng. While Humio provides many other APIs for log ingestion, I focus on the elasticsearch-http() destination of syslog-ng, demonstrating that there is no vendor lock-in: the same driver works equally well for Elastic’s Elasticsearch, AWS’s OpenSearch and for Humio. https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-humio-usin… WEBINARS * You can browse recordings of past webinars at https://www.syslog-ng.com/events/ Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/ Peter Czanik (CzP) <peter.czanik(a)oneidentity.com> Balabit (a OneIdentity company) / syslog-ng upstream https://syslog-ng.com/community/ https://twitter.com/PCzanik

1 0

syslog-ng no longer receiving kernel messages
by John Covici 13 Dec '21

13 Dec '21

Hi folks. I am having a problem that syslog-ng no longer gets any kernel messages. It seems to get other messages, but not kernel messages. Here is what happened. In an update from kernel 5.10.70 to 5.10.82, I enabled the kernel race condition sanitizer. I looked at its output and decided that it would not do me any good, so I took that out and recompiled the kernel. However after rebooting the system, syslog-ng only gives me a few messages from when the kernel sanitizer was active in my /var/log/messages and the same for /var/log/kernel. I am using systemd, so I have the jernal and it is OK, all messages are posted correctly there. Here is my /etc/syslog-ng/syslog-ng.conf . @version: 3.34 # $Header: /var/cvsroot/gentoo-x86/app-admin/syslog-ng/files/3.4/syslog-ng.conf.gentoo,v 1.2 2013/06/02 01:18:35 mr_bones_ Exp $ # # Syslog-ng default configuration file for Gentoo Linux # https://bugs.gentoo.org/show_bug.cgi?id=426814 @include "scl.conf" options { dir_perm(0755); perm(0644); chain_hostnames(no); threaded(yes); chain_hostnames(no); # The default action of syslog-ng is to log a STATS line # to the file every 10 minutes. That's pretty ugly after a while. # Change it to every 12 hours so you get a nice daily update of # how many messages syslog-ng missed (0). stats_freq(43200); # The default action of syslog-ng is to log a MARK line # to the file every 20 minutes. That's seems high for most # people so turn it down to once an hour. Set it to zero # if you don't want the functionality at all. mark_freq(0); keep_hostname(yes); }; source local { system() ; internal(); }; # *.emerg * filter f_9 { level(emerg); }; destination d_6 { usertty("*"); }; log { source(local); filter(f_9); destination(d_6); }; # kern.=debug /var/log/kernel filter f_1 { facility(kern) and level(debug..emerg); }; destination d_1 { file("/var/log/kernel" create_dirs(yes)); }; log { source(local); filter(f_1); destination(d_1); }; # kern.err /dev/console filter f_2 { facility(kern) and level(err..emerg); }; destination d_2 { file("/dev/console" create_dirs(yes)); }; log { source(local); filter(f_2); destination(d_2); }; # *.debug;mail.none;news.none;authpriv.none /var/log/messages filter f_3 { level(debug..emerg); }; filter f_4 { not facility(mail); }; filter f_5 { not facility(news); }; filter f_6 { not facility(authpriv); }; destination d_3 { file("/var/log/messages" create_dirs(yes)); }; log { source(local); filter(f_3); filter(f_4); filter(f_5); filter(f_6); destination(d_3); flags(final flow-control); }; # authpriv.* /var/log/secure filter f_7 { facility(authpriv) and level(debug..emerg); }; destination d_4 { file("/var/log/secure" create_dirs(yes)); }; log { source(local); filter(f_7); destination(d_4); }; # mail.* /var/log/maillog filter f_8 { facility(mail) and level(debug..emerg); }; destination d_5 { file("/var/log/maillog" create_dirs(yes)); }; log { source(local); filter(f_8); destination(d_5); }; # news.=crit /var/log/news/news.crit filter f_10 { facility(news) and level(crit..emerg); }; destination d_7 { file("/var/log/news/news.crit" create_dirs(yes)); }; log { source(local); filter(f_10); destination(d_7); }; # news.=err /var/log/news/news.err filter f_11 { facility(news) and level(err..emerg); }; destination d_8 { file("/var/log/news/news.err" create_dirs(yes)); }; log { source(local); filter(f_11); destination(d_8); }; # news.notice /var/log/news/news.notice filter f_12 { facility(news) and level(notice..emerg); }; destination d_9 { file("/var/log/news/news.notice" create_dirs(yes)); }; log { source(local); filter(f_12); destination(d_9); }; # local7.* /var/log/boot.log filter f_13 { facility(local7) and level(debug..emerg); }; destination d_10 { file("/var/log/boot.log" create_dirs(yes)); }; log { source(local); filter(f_13); destination(d_10); }; # local0.* /var/log/dhcpcd.log filter f_14 { facility(local0) and level(debug..emerg); }; So, what have I been doing wrong, or is it something else? Thanks in advance for any suggestions. destination d_11 { file("/var/log/dhcpcd.log" create_dirs(yes)); }; log { source(local); filter(f_14); destination(d_11); }; -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici(a)ccs.covici.com

2 4

[patch] new feature for file destination: persistent symlinks
by a.biardi＠tiscali.it 07 Dec '21

07 Dec '21

Hi all, I'm new here. I love syslog-ng: it's well written and documented and each time I need some new feature, I dig up the documentation and I find it's already implemented! Like many others, I use macros in file destinations (say, "/var/log/cron.${YEAR}${MONTH}"), but I also want to maintain a persistent symlink to the current logfile (that would be something like "/var/log/cron") in order to have "easier" access if I'm grepping for something manually. I couldn't find this feature in syslog-ng, so I wrote the code myself; in the configuration file, it looks like this: destination d_file_cron { file("/var/log/cron.${YEAR}${MONTH}" symlink_as("/var/log/cron")); }; It works for me on my Slackware boxes. I'm sharing the patch I put together, hoping that it may be useful to others and perhaps even considered for inclusion in mainstream. From a functional perspective, the "symlink_as" file inherits both "create-dirs" and file ownership from its file destination (permissions are not applicable to symlinks, at least on linux). Patch applies cleanly to latest production release (3.33). I tried to keep the original coding style for easier review (admittedly, the code could have gone into the function that opens the file destination, but I didn't want to change too much). Thanks for the good work and happy logging! Andrea.

3 4

Re: [syslog-ng] [patch] new feature for file destination: persistent symlinks
by a.biardi＠tiscali.it 06 Dec '21

06 Dec '21

On Mon, 6 Dec 2021 15:28:18 +0000, "Gabor Nagy (gnagy)" <Gabor.Nagy(a)oneidentity.com> wrote: > Dear Andrea! > > I'm forwarding my answer to make sure you get it anyway. > Looking forward to hearing from you! > > Best Regards, > Gábor > ________________________________ > From: Gabor Nagy (gnagy) <Gabor.Nagy(a)oneidentity.com> > Sent: Sunday, December 5, 2021 17:49 > To: Syslog-ng users' and developers' mailing list > <syslog-ng(a)lists.balabit.hu> Subject: Re: [syslog-ng] [patch] new > feature for file destination: persistent symlinks > > Hello Andrea! > > Thank you for your contribution! We always welcome feedback and > contribution from the community! > > I've quickly checked your patch, and it looks good. Maybe minor > things could be changed, but we will see this during a thorough > review. > > We integrate patches via pull requests on GitHub. [1] > How would you like to continue this contribution? > Would you like to open a pull request on GitHub? > > I see a corner case of the feature: if the filename template is not > time-based, like e.g. $PROGRAM or $HOST, it can happen that the > symlink is changed several times in a short time. This is not an > argument against the feature, it's just a behaviour that should be > considered and documented. As I see, the feature in general creates a > symlink with the name given in "symlink_as" option when a new file is > opened. In other words: the configured symlink always points to the > latest file that were opened. > > > Best Regards, > Gábor > > [1] https://github.com/syslog-ng/syslog-ng > > ________________________________ > From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> on behalf of > a.biardi(a)tiscali.it <a.biardi(a)tiscali.it> Sent: Saturday, December 4, > 2021 15:29 To: syslog-ng(a)lists.balabit.hu <syslog-ng(a)lists.balabit.hu> > Subject: [syslog-ng] [patch] new feature for file destination: > persistent symlinks > > CAUTION: This email originated from outside of the organization. Do > not follow guidance, click links, or open attachments unless you > recognize the sender and know the content is safe. > > > Hi all, > > I'm new here. I love syslog-ng: it's well written and documented and > each time I need some new feature, I dig up the documentation and I > find it's already implemented! > > Like many others, I use macros in file destinations (say, > "/var/log/cron.${YEAR}${MONTH}"), but I also want to maintain a > persistent symlink to the current logfile (that would be > something like "/var/log/cron") in order to have "easier" access if > I'm grepping for something manually. > > I couldn't find this feature in syslog-ng, so I wrote the code myself; > in the configuration file, it looks like this: > > destination d_file_cron { > file("/var/log/cron.${YEAR}${MONTH}" symlink_as("/var/log/cron")); > }; > > It works for me on my Slackware boxes. I'm sharing the patch I put > together, hoping that it may be useful to others and perhaps even > considered for inclusion in mainstream. > > From a functional perspective, the "symlink_as" file inherits both > "create-dirs" and file ownership from its file destination > (permissions are not applicable to symlinks, at least on linux). > > Patch applies cleanly to latest production release (3.33). I tried to > keep the original coding style for easier review (admittedly, the code > could have gone into the function that opens the file destination, but > I didn't want to change too much). > > Thanks for the good work and happy logging! > > Andrea. Hi Gábor, Sorry for the delay, daytime job keeps me busy :) Will submit a PR through github asap. I did not consider the case where the template contains something like $PROGRAM or $HOST. As you point out, the code wouldn't fail but you'd get an ever-changing symlink of dubious usefulness. Worth documenting. Cheers, Andrea.

1 0