在 tools.logging 中添加对上下文日志记录的支持

Question

结构化日志记录优于纯文本。
上下文日志记录 + 结构化日志记录总体上是赢的。在我们公司，我们可以丢弃我们自定的日志解决方案，它除了支持上下文日志记录外，还劣于 tools.logging，并将成为库功能的一个强大补充。
为了添加对上下文日志记录的支持，我们可能需要一个额外的协议来实现这样的 API 的框架（如 SLF4J）。
不确定是否需要，但额外的日志函数也可能简化实现。
建议的使用方法

(log/info-c {:foo "bar"} my-error "some message")

Comments

我们在工作中使用 c.t.l 结合 log4j2，并通过 Java 互操作利用了 MDC 内容，并将其包装在一个宏中。但我还没有查看使其通用的方法是什么，但为了使所有日志实现标准化，这将很棒。

我们有一个宏 (with-log-context context-map .. body ..)，它会直接将 context-map 数据添加到 log4j2 的 MDC 中。

---

我宁愿使用标记(Markers)而不是 MDC，调用这里的所有方法。
https://www.slf4j.org/api/org/slf4j/Logger.html#error-org.slf4j.Marker-java.lang.String-java.lang.Throwable-

---

tools.logging 是否还需要其他功能？

---

是的，有一些代码路径可以调用接收 slf4j 的 Markers 的方法。MDC 对结构化日志记录是不够的。

---

https://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback

但是 MDC（Mapped Diagnostic Context）非常有用，正如那个回答所说——对我们来说，能够在整个请求的日志中标记用户ID或IP地址或其他类似的关注点，比能够在不同的日志“类型”（标记）上进行筛选重要得多。

所以，我认为这里的主要观点是，有些人会想要标记，有些人会想要MDC，有些人会两者都要，也有些人可能两者都不需要。

标记直接影响API，因为它们被传递进 error()、warn() 等调用中。鉴于 c.t.l 已经提供了可变参数的调用和将 Throwable 作为第一个参数的特殊情况，我不太确定添加标记的 API 应该是什么样子（特别是当它们对于每个记录器实现是不同类的情况下）？

也许会有一个类似 errorm、warnm、infom 等的新API，它将第一个参数视为标记？你将如何将这添加到底层写入操作中，而不破坏任何现有的实现（除 c.t.l 外）？

---

大概需要一个新的API，正如你所说的，像 `{log}m` 这样，我很高兴。
关于write!方法，我会增加另一个方法或参数，并调用它，这样不支持标记或其他类似功能的实现就不需要做出任何更改。

---

我正在开发一个针对log4j2的特定Clojure库，它支持标记、MDC以及通过MapMessage等实现的规范化日志记录：[https://github.com/seancorfield/logging4j2](https://github.com/seancorfield/logging4j2) -- 欢迎对这个早期阶段的反馈。

Answer 1

我们已将代码迁移到结构化日志记录，使用标记，就像这里写的：[https://stackoverflow.com/a/60101309/8162407](https://stackoverflow.com/a/60101309/8162407)

这是一个在clojure.tools.logging上的瘦包装，真的很高兴。投上赞。

Comments

这里是否仍然有关于tools.logging的需求，如果有，那么是什么？

---

我认为这有一个问题：c.t.l是否可以支持所有（Java）日志库的通用上下文或标记？

我个人不确定人们有多频繁地更改日志实现，因此我认为这并不值得做。如果已经选择了日志实现，则可以使用Java互操作性来按任何方式使用MDC或标记...

---

如何结合 tools.logging 使用标记？我知道 MDC 可以通过宏轻松完成，但如何动态地传递标记呢？