3 ms·
> It's ironic considering that syslog is not standardized. I don't find any irony there, at all, since it's reflective of the history of Unix, and consistent w
by mmt 8y ago
> It's ironic considering that syslog is not standardized.
I don't find any irony there, at all, since it's reflective of the history of Unix, and consistent with the OC's "like a zillion ways to get telemetry out". More to the point, it's fairer to say that different syslogd implementations were parallel evolution, rather than re-invention.
Now, it seems you're talking about the network protocol, whereas "syslog" the system call seems not to be too different across platforms, certainly not to the point of incompatibility. I call this out, not for pedantry, but to illustrate that, from the app's perspective, it's all the same.
> Plug any two syslog implementations and they won't work together.
Unless, perhaps, one of them understands (or can understand, with plugins) more than one protocol?
Regardless, the solution requiring the least engineering effort is to make sure one has compatible wheels everywhere, not re-inventing the wheel.
> The two main competing protocols are defined in RFC 3164 and 5424
I'm not sure that it's fair to call them competing when 5424 explicitly obsoletes 3164 (and the earlier one is "informational", while the later one is a "proposed standard").
Of course, that says nothing about the reality of the competing implementations, but if there are only two, and the older one is the most popular (which I believe it is), then perhaps there's no real competition.
> Logstash, the L in ELK, only parses a subset of RFC3164 messages with very specific formatting.
That would be an example of a (partial) syslogd re-invention. I have no idea if that input plugin is worth using (e.g. for performance reasons) rather than using something like a pipe plugin for plain text from a local syslogd. I suspect for the vast majority of use cases, it's totally irrelevant.
- user5994461 8y agoA log message is meant to be processed and stored somehow. It's a problem if the message cannot be parsed and is dropped. The two RFC are incompatible, then every implementation is slightly different in the handling of miliseconds/microsecond/timezone, the presence of the hostname field, structured data support, etc... I am calling out your first post that syslog is lightweight, flexible and plain text. syslog suffers from serious issues.
- mmt 8y ago> It's a problem if the message cannot be parsed and is dropped. Agreed, but you now seem to be implying that this just happens because syslog, rather than misusing the tool. Earlier, you asserted "Plug any two syslog implementations and they won't work together" which I didn't bother to contradict, because it seemed like mere exaggeration. However, at this point, it seems like an extraordinary claim requiring extraordinary evidence. I have, of course, routinely, in my professional career, spanning decades, successfully used different implementations with each other, usually because (more than) one implementation is embedded and can't be changed to match what's on the servers. Exactly which syslogd implementations connected to each other over the network will fail to parse messages and drop them? > The two RFC are incompatible, then every implementation is slightly different I think you're reversing cuase and effect, especially given both the relatively late date of the earlier RFC in the timeline of Unix history, as well as its enduring popularity over the later RFC. > I am calling out your first post that syslog is lightweight, flexible and plain text. I don't believe you've addressed, in any way, the assertion that it's lightweight. Your challenge to its flexibility is, AFAICT, poor interoperability of only the network protocol, which you haven't backed up with evidence. Even then, that's a weak refutation of the flexibility of the mechanism overall. Your challenge to its being plain text is, again, primarily based only on network protocol, and, even then, based on a widely-unimplemented RFC. > syslog suffers from serious issues. This may be responding to an implied strawman, that syslog somehow perfect or ideal for all use cases, which, of course, I never said. In fact, being plain-text could be considered a "serious issue" for some telemetry.