Understanding the relationship between mulog + tools.logging

[respatialized]

Hi! I've really enjoyed using mulog recently - it has made thinking through some tricky data engineering problems much easier with the help of abundant empirical data on latency and throughput.

I have some library code that also has an application component, and I have many print statements that are long overdue for proper replacements with actual logging capabilities. The app is an optional part of the library; the library code can be used without running the app. Based on this discussion about babashka, it seems like you suggest that my library code should delegate logging to the tools.logging interface, and then the app, should the users choose to load it, should use a concrete implementation. I had wanted to use mulog at runtime for this, but I can't find any examples of using mulog as the concrete runtime logger (I saw tools.logging in the dependencies for this example project, but didn't see it actually loaded in the namespaces of that application code).

Is this actually something I should try to do? It seems like mulog is at a higher level of abstraction than tools.logging - it logs structured data and metadata, whereas tools.logging seems to exist to generalize across the various string or line-based logging tools - the one area of compatibility would be something like mulog's slf4j backend. It also seems like tools.logging represents an earlier paradigm of logging, where you'd want to turn logging off in production for "debug" levels and the like, whereas mulog is designed from scratch to be low-latency enough to be always on, so you can collect the appropriate telemetry.

I'm struggling to think through the distinction here. I want to give users of my library control over how and where their logs go (which seems to imply programming against the tools.logging interface), but I want for my own development work to use all the power of mulog as I refine this library.

Does it make sense to create a tools.logging publisher for mulog? Does it make sense to create a clojure.tools.logging.impl/LoggerFactory implementation that uses mulog? Clearly this is a one-or-the-other question, lest I create an infinite loop between logging interfaces. It seems like either way there's going to be a loss of granularity as data passed between mulog's structured data format and tools.logging's message-based format.

Sorry if this question is kind of vague; I just don't really know where to go next as I'm considering major changes to my library's code.

[BrunoBonacci]

Hi,
Thank you for considering mulog for your project.

I’ve already expressed some of my thoughts on this subject in issue #17 and issue #25 and in the FAQ: https://cljdoc.org/d/com.brunobonacci/mulog/0.9.0/doc/f-a-q-#q-can-i-use-μlog-as-the-sole-logging-library-and-send-my-traditional-logging-to-it I suggest you read these resources as well.

The reason I suggested babashka to use clojure.tools.logging instead of mulog is for two reasons: technical and practical.
From the technical side, mulog is a fully asynchronous logger. When you call a mulog function (log or trace) the function will capture current values and insert them in a buffer.
At a later time the buffer will be send to the publisher.
This means that for short lived program (like babashka scripts) you might need to add extra wait in order to allow for the buffers to be processed, otherwise you won’t see any logs.

The second reason is that from a practical standpoint a babashka script is most likely to have a human interaction and in case of failure you rather have a human readable message of what is going on.

Mulog is designed to work in large cloud environments with thousands of virtual machines and hundreds of millions or billions log events. For such environments it is unpractical to have a human sifting through millions and millions of logs to find anything of interest. To work effectively with such amount of events you need tools, and tools work best with raw data.

Over the years, I have been reducing my use of traditional logs to zero. I find don’t find them useful outside of the development. Mulog replaced entirely the use of logs and metrics (and traces) as I can collect data points with one instrument and look at the data with many different tools.

To know what’s best for you, you need to answer a question: what is the primary consumption mode of your logs?
If you consume/read logs during the development maybe clojure.tools.logging is probably a good choice.
While if you mostly look at logs when the application is deployed in a cloud or virtualised environment and you look and many instances of the same app or many different apps, then mulog is a far better approach.

The way you can make the best use of mulog is to consider your app as a black-box. If you have a black box of which you don’t know anything about it, and you have no information about its inner state and its inner workings, what metrics would you want to have to know how it is performing?

Most generally, you want to know if there are errors and what type of errors are occurring. You also want to know if it's currently processing requests or messages, so that you can understand whether it is working. Also, you might be interested to know how long each message or request takes to be processed so that you can get insights on whether it is running slower than expected. Finally, if it is slower, you want to know why and where. One single u/trace can offer all that and much more.

I hope this response resonates with you. If you have further questions I’m happy to respond.

Best,
Bruno