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. <ezel...@ornl.gov> 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.
