<div dir="ltr"><div dir="ltr">On Mon, May 6, 2019 at 10:09 AM Thomas Güttler <<a href="mailto:guettliml@thomas-guettler.de">guettliml@thomas-guettler.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 03.05.19 um 13:29 schrieb Jérémy ROSEN:<br>
> if you want the whole power of structured logs, you need to use the journald API<br></blockquote><div><br></div><div>On the other hand, JSON parsing might be a useful addition to journald, as apparently "@cee: {<jsondict>}" is a quite common syslog format.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I am not sure in what language your program is written, but if you are using C, it's pretty trivial to do<br>
> (and i'm pretty sure most bindings are trivial to use too)<br>
<br>
<br>
Yes, this would work.<br>
<br>
<br>
Solution 1:<br>
  My service (written Python) uses the journald API.<br>
  Disadvantage: My script can't be run under a different environment (without journald)<br>
<br></blockquote><div><br></div><div>I would suggest implementing support for multiple logging backends – don't call journald APIs directly and don't print out JSON directly, but have abstract functions such as log_info(text, **kvpairs) or something such. That's what many programs already do for file/syslog/journal backends. (Possibly just use the `logging` module in python?)</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>