Repository navigation
Add a opt-in mechanism to make the node output logs in JSON format #332
Description
Add a opt-in mechanism to make the node output logs in JSON format (GOLOG_LOG_FMT=json / cfg.Format) instead of the console encoder.
Points to weigh:
- Machine consumers of the debug command get whole-line JSON, no console-format parsing needed. journalctl / terminal readability suffers; operators would need jq or GOLOG_LOG_FMT=color to read logs comfortably.
- Middle ground worth exploring: per-sink encoders - JSON for the ringbuffer:// sink (what tools consume), console for stderr (what humans read). go-log configures one format globally, so this needs a custom zap core wiring in main.go.
Activity
saurav-shakya commentedon Oct 17, 2026
Hi @kaisoz @aojea, I'd like to work on what's left of this one.
It looks like the opt-in part is already done:
--log-format text|jsonlanded on main in #688 and it's in the reference docs. What's still open is the middle ground from the description. Right now--log-format jsonswitches stderr and the ring buffer behind/debug/logsat the same time, so you can't have readable terminal output and machine-friendly debug logs together.I've put together a small change that keeps
--log-formatfor stderr (and the--daemonizelog file) and always writes the ring buffer as JSON. That way anything readingagentmesh-node debug logsnever has to parse the console format. It hooks the ring in with go-log'sNewPipeReader(PipeFormat(JSONOutput)), so there's no custom zap core and no new dependency. The code is in #737.There are two things I'd like your opinion on:
/debug/logsbe JSON by default, or should the ring just follow--log-format? The first option changes whatdebug logsprints today when you're on the defaulttextformat.RecentLogs. If you'd rather keep it synchronous, I can switch to aSetPrimaryCoretee instead, but that means rebuilding go-log's output handling.Happy to rework it either way.