Mirror of forum.nim-lang.org

13173 :: namespaced_logging - Thread-safe, namespace aware logging library.

• jdb (orginal) [2025-07-06T10:25:35+02:00] view original

  Hi All,

  I like the ability to filter down logs by scope/namespace a.l.a. logback and a while back I built an implementation of that concept for myself in Nim. I'm now building a new API server in Nim (using and loving mummy) and my little logging library that I threw together wasn't really production ready. I'm also trying to go all-in on structured logging in production. Over the long weekend I finally got around to refactoring my little library to be more production-ready and to support structured logging natively.

  In addition to namespaces, namespaced_logging is intended to be a high-performance, thread-safe logging framework similar to std/logging with support for namespace-scoped logging similar to log4j or logback for Nim. It has four main motivating features:

  • Safe and straightforward to use in multi-threaded applications.
  • Native support for structured logging.
  • Support for a simple, implicit usage pattern reminiscent of the std/logging interface.
  • Support for hierarchical, namespaced logging.

  it relies on the Nim GC and is intended to be fully GC-safe. There should be no need for manual memory management.

  Currently it requires --threads:on and will not compile with --threads:off as it uses channels for thread-safe IO. I may add support for --threads:off but don't have any pressing need at the moment.

  The README should be fairly comprehensive.

  I'm interested in feedback. I've spent a fair amount of time thinking through the multi-threading behavior, reference semantics, etc., but would very much appreciate additional eyes. Let me know where I've screwed up.

  I expect to keep the v2 contracts stable, but I will be working this into our production setup in the next few days/weeks and may have changes as I use it for real.

  If this is useful, please feel free to use it. I haven't decided on a license yet, but will probably just default to MIT.

---

• Araq (orginal) [2025-07-06T10:30:44+02:00] view original

  What is "structured logging"?

---

• jdb (orginal) [2025-07-06T10:43:26+02:00] view original

  To oversimplify, logging something like JSON instead of just a string. In the case of this library it means a few things specificially:

  1. The log methods (info, trace, etc.) all have a version that accepts a JsonNode (as well as the traditional string).
  2. Internally there is a LogMessage data type that both the string and JsonNode message types get mapped into.
  3. There is a formatJsonStructuredLog proc available that just JSON stringifies the LogMessage object. The default formatSimpleText just takes the string message that was passed in or looks for the message field if it was JSON.

  There's a ton of literature around the idea but not all of it is good. In my experience having some consistent JSON structure becomes useful when you push logs into something like Grafana Loki or something other log database.

  By default this library logs the messages as text, similar to std/logging.

---