<div dir="ltr"><div>Hi everybody,</div><div><br></div><div>After a few months of simmering, I think it's time to formally propose varnishlog-json (<a href="https://github.com/varnish/varnishlog-json">https://github.com/varnish/varnishlog-json</a>) for inclusion in the main repository.</div><div><br></div><div>A tiny bit of context first, feel free to skip if you've already heard me ramble about this.</div><div>Currently we have two main loggers: varnishncsa and varnishlog, both with their caveats. The former requires the user to know exactly what they are looking for so they can define a format line, on top of using ncsa which is a terrible format. One can emulate JSON (completely random example) but the format line quickly becomes insane and unreadable. And I'll skip over the issues of which record value is picked (first one? last one? it depends!). The latter presents less a synthetic report of a transaction and more a sequence of events which is absolutely brilliant for debugging, but isn't super useful outside of that.</div><div><br></div><div>So after years of ranting, I finally built a tool that would provide a compact report of a transaction, opinionated and hopefully both immediately useful but whose output can be used by other tools (so they don't have to link against libvarnish).</div><div><br></div><div>I think the README of the project is fairly clear about the important point, but to save you a click, here are the takeaways:</div><div>- uses VUT</div><div>- tries to present requests/responses as they are when entering/leaving varnish</div><div>- JSON output using libcjson (<a href="https://github.com/tspspi/libcjson">https://github.com/tspspi/libcjson</a>) we link against it, but we could embed it as when given how small it is</div><div>- supports all the bells and whistles you expect from a libVUT tool, including filtering, grouping and daemonizing</div><div>- reports VCL_Log records so users can inject extra information for future processing</div><div><br></div><div>I've been using it for a while in a bunch of projects in go and JS, saving me from writing bindings, and I think we can start thinking about making it a prime citizen given the gap it fills. I know there are V/CBOR works in the pipeline, which could possibly change the internal implementation details, but I reckon it doesn't prevent us from including the current code until we have better internals to hook into.</div><div>Internally, I'm going to start pushing to make this part of Enterprise, but I'd like to try and upstream it first to get some broader feedback from the community.</div><div><br></div><div>I'll be at the bugwash today so we can hopefully discuss it.</div><div><br></div><div>Cheers!</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div></div></div>