Re:Tracing: Structured Logging, but better in every way
by jameshart on Wednesday September 20, 2023 @06:25PM
(#37590987)
But events that another system relies upon are now an API. Be careful not to lock together things that are only superficially similar, as it affects your ability to change them independently.
Re:Tracing: Structured Logging, but better in every way
by thangalin on Wednesday September 20, 2023 @06:36PM
(#37591052)
Architecturally, the decoupling works as follows:
Event -> Bus -> UI Subscriber -> Dialog (table)
Event -> Bus -> Log Subscriber -> Console (text)
Event -> Bus -> D-Bus Subscriber -> Relay -> D-Bus -> Publish (TCP/IP)
With D-Bus, published messages are versioned, allowing for API changes without breaking third-party consumers. The D-Bus Subscriber provides a layer of isolation between the application and the published messages so that the two can vary independently.
They are events. For my text editor, KeenWrite, events can be logged either to the console when run from the command-line or displayed in a dialog when running in GUI mode. By changing "logger.log()" statements to "event.publish()" statements, a number of practical benefits are realized, including:
* Decoupled logging implementation from the system (swap one line of code to change loggers).
* Publish events on a message bus (e.g., D-Bus) allows extending system functionality without modifying the existing code base.
* Standard logging format, which can be machine parsed, to help trace in-field production problems.
* Ability to assign unique identifiers to each event, allowing for publication of problem/solution documentation based on those IDs (possibly even seeding LLMs these days).
https://dave.autonoma.ca/blog/2022/01/08/logging-code-smell/