upvote
I disagree. I work in a large environment, and rsyslog is where 90% of data goes to first. It can keep up with millions of messages per second, route them to higher order services for indexing (bigquery, splunk, elastic etc etc). Has rules engines, encryption, supports multiple protocols and obviously has TLS too. You can surely augment with otel and such where you can, but syslog is uhhhh, deployed in so many places that it would make an average app developer's head spin when all they're used to is application logging in a controlled structured place in their silo.
reply
Even SC4S, splunk's docker appliance for turnkey syslog uses rsyslogd.

Edit: being pedantic -- it's syslog-ng actually.

reply
And the number of k8s envs that log stdout through them into.... more rsyslog, it's truly everywhere. Plus all the sidecar containers deployed that shuffle app logs, lots of syslog there, its so lightweight and simple and reliable. I watch all the gyrations people go through to achieve the same result, and it's always changing, hurts my brain thinking how much time they waste
reply
The problem with modern stuff is it doesn't do the very basics. Sometimes I really do want UDP dumping out into a file on another part of the network. The modern setups forget how to do this.
reply
I saw one place that had the logs going into a database. On the same connection as the app-data. So, when the transaction failed, the logs also didn't get written. LMAO. I made them do syslog in their code, which for some of the devs was a mind-blowing. They were amazed at that we could just barf text quick&lightweight over UDP.
reply
Disagree. JSON logging is fine, but make it line based and just log to a syslog server. Then I can route it wherever I want (or to multiple places) including to a simple file on a disk that I can actually inspect, rather than having to use an API.
reply
Yeah, for a modern large scale distributed system both the client api and implementations are pretty bad.
reply