I was told the other day the biggest limitation of syslog-ng is its name. Everyone assumes it is about "syslog", while it has been able to do much more than sys

I was told the other day the biggest limitation of syslog-ng is its name. Everyone assumes it is about "syslog", while it has been able to do much more than syslog for a long time. It is a drop-in replacement of syslogd, and it is true that syslog is a pretty important use-case, but here's a list of features I consider "extra". I plan to write a more detailed blog post later. High level capabilities: - curating and fixing up the incoming message stream, so you can use it easier in your SIEM or other downstream log consumer - application classification, e.g. detect what app is sending a specific message, use this logic to determine sourcetype in Splunk for instance - native code, small footprint (CPU, memory), scale over 100k/sec easily, some use-cases even 600-800k/sec - powerful config language, allowing all of the above. Not coding, but configuration (e.g not javascript, typescript, ruby or Java snippets) - but if the config language is not enough, easily extendable using Python (or Java) Features: - generic key-value pairs, actually each message is a set of key-value pairs - JSON support, we parse & produce and translate JSON documents - HTTP destination (integration with Splunk for instance, but any HTTP API is doable, see our Twitter/Discord integrations) - stream based correlation (e.g transform an event spanning multiple messages into 1 aggregated event) - Kafka for enterprise queueing - MQTT for IoT and sensor data - Elastic/MongoDB/SQL integration for databases - Riemann integration for monitoring I am afraid this is becoming long and some details could be added for each of the above. I make an attempt to cover these areas in my subsequent blog posts. So consider subscribing if any of these is interesting.