Sure, as a system administrator it's pretty clear how best to handle this. If there's CEE JSON data coming over the wire, use mmjsonparse. If it's unstructured traditional syslog(3) data, use mmnormalize to try to extract relevant fields based on rules I setup. Write the traditional "message" field to /var/log/messages and send the structured data to ElasticSearch. But I'm a system administrator who cares about structured logging, so I would have a custom rsyslog setup to handle this seamlessly.
The question is really from the application developer's point of view. How do you log structured data in a way that doesn't change the format of /var/log/messages for most users, but provides additional information for those system administrators who choose to handle the structured data? Imagine going to the developers of OpenSSH and requesting that they start logging structured data. If they simply changed all their syslog(3) calls to output CEE JSON instead instead of plain strings, it's going to break just about every brute-force login detection system out there. That's unacceptable. What is the *right* thing for them to do? ~Matt --- Matt Ezell HPC Systems Administrator Oak Ridge National Laboratory On 4/14/15, 11:49 PM, "singh.janmejay" <[email protected]> wrote: >Have you looked at mmjsonparse? It solves the problem of >de-serializing structured-messages handed-over to rsyslog in >JSON-serialized form. > >For dual-mode: structured and unstructured, 2 common approaches exist. >- Passing structured messages as JSON and optionally handling the >differently on Rsyslog side >- Parsing semi/un-structured messages to generate structured form > > >On Wed, Apr 15, 2015 at 9:01 AM, Ezell, Matthew A. <[email protected]> >wrote: >> Hello- >> >> What is the current "best practice" for a portable application to get >> structured data to rsyslog? >> >> Most modern syslog daemons seem to support some type of JSON format, but >> applications still tend to use the old syslog(3) function for logging. >>If >> an application emits CEE JSON directly to syslog(3), and no special >> configuration is made to enable JSON parsing, the "typical" output file >> (/var/log/messages or distribution-specific equivalent) gets JSON >>printed >> to the log. That may be undesirable in the common case. >> >> Ideally, there would be a syslog()-like library call that an application >> could make to provide a "normal" syslog message as well as structured >> data. /var/log/messages would just get the "normal" syslog message, but >> System Administrators who care about structured logging could log the >> structured data to an alternate file, forward it to a central syslog >> daemon, or log it to a document store (mongodb, ElasticSearch, etc). >>That >> library would (again, ideally) be pervasive (available *by default* on >> most systems, like syslog.h today) or dead-simple to ship with an >> application (meaning a license that allows redistribution and a minimal >> number of files to pull into the application repository). >> >> I've read up on CEE and LumberJack, but both projects seem to be >> dead/crufty at this point. There's libumberlog and liblogging, but it's >> not clear that either of them fit the use case of being able to detect >>if >> the host "wants" structured logging and responding appropriately. >> >> >> I've also seen systemd's journal sd_journal_send(), which seems like a >> nice interface, but systemd is strictly linux-only. On linux, it looks >> like regular syslog would just get the message part (to log into >> /var/log/messages), but journalctl and rsyslog's imjournal could get at >> the structured data. That's really what I want, but without the >>annoyance >> of systemd being new and linux-only. I'd prefer not to pepper an >> application with #ifdef's to figure out if it should use the journald >> functions or something else. >> >> >> I'd like to see structured logging become the norm - is it possible to >> make it easy for application developers to add structured logging >> capabilities without introducing JSON to /var/log/messages for "simple" >> use cases? >> >> Thanks for any advice you can provide, >> ~Matt >> >> --- >> Matt Ezell >> HPC Systems Administrator >> Oak Ridge National Laboratory >> >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a >>myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST >>if you DON'T LIKE THAT. > > > >-- >Regards, >Janmejay >http://codehunk.wordpress.com >_______________________________________________ >rsyslog mailing list >http://lists.adiscon.net/mailman/listinfo/rsyslog >http://www.rsyslog.com/professional-services/ >What's up with rsyslog? Follow https://twitter.com/rgerhards >NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
