alt Hacker NewsWas there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
Replies
Yeah looks like they missed the forest for the trees.
I see this kind of thing in our industry quite often; some Rube Goldberg machine being invented and kept on life support for years because of some reason like this, where someone clearly didn’t do the obvious thing and everyone now just assumes it’s the only solution and they’re married to it.
But I’m too grumpy, work me is leaking into weekend me. I had debates around crap like this all week and I now see it everywhere.
Also there is a --json (or -o json) flag for journalctl which will output line based json log entries. And it can simply be called with a Command as you pointed out.
It's generally less robust to run CLI tools and scrape the output. Usually it isn't intended to be machine readable, and you have to handle extra failure modes, like incompatible tool versions, missing tools, incorrect parsers, etc.
It's the lazy-but-bad solution.
This was the first thought that occurred to me too when I saw this post.
Ironically this is EXACTLY what the journald receiver for OpenTelemetry does, which, as they noted, is written in go.
Specifically because you're only supposed to use that OR the c bindings by design because they want the ability to change in the internal format when it's necessary.