2024 状态 Clojure 调查问卷! 中分享您的想法。

欢迎!请参阅 关于 页面以获取更多关于此如何工作的信息。

+4
Java 互操作

结构化日志比纯文本更胜一筹。
上下文日志+结构化日志是一个净赢。在我的工作场所,我们可以摆脱我们的临时日志解决方案,该方案除了支持上下文日志记录外,在 tools.logging 的支持之下劣于,并且将极大地增强库的功能。
为了添加上下文日志记录支持,我们可能需要一个额外的协议,该协议实现了这样的 API 框架(如 SLF4J)。
不确定是否需要,但一个额外的日志函数可能也会简化实现。
建议的使用

(log/info-c {:foo "bar"} my-error "some message")
我们在工作中使用 c.t.l 与 log4j2,并通过 Java 互操作利用了 MDC 东西,并通过宏进行了封装。但我还没有研究要使它通用需要哪些,但最好对所有日志实现标准化。

我们有一个宏 (with-log-context context-map .. body ..),它会将 context-map 数据直接添加到 log4j2 的 MDC 中。
tools.logging 中还需要些什么吗?
是的,有一些代码路径可以到达使用 slf4j 的 Markers 的方法。MDC 对于结构化日志来说是不够的。
https://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback

但是 MDC 非常有用,正如那个回答所说——“切片和切块”——对我们来说,能够使用用户 ID 或 IP 地址或其他类似内容来标记整个请求的日志要比能够根据不同的日志“类型”进行过滤(markers)重要得多。

所以,我认为这里的要点是,有些人会想要 markers,有些人会想要 MDC,有些人会两者都要,有些人可能两者都不在乎。

Markers 会直接影响 API,因为它们会被传递到 error()、warn() 等调用中。考虑到 c.t.l 已经提供了可变参数调用,并将其作为第一个参数处理特殊情况的 Throwable,我不确定添加 Markers 的 API 该如何设计(特别是当它们为不同的 logger 实现而异时)?

也许我们可以使用 errorm、warnm、infom 等,这些将会把第一个参数视为 Marker?如何在不妨碍现有实现(outside c.t.l.)的情况下将其添加到底层的 write! 中呢?
可能需要一个新的 API,就像你说的,一个像 {log}m 这样的 API,我很乐意接受。
关于 write! 方法,我建议添加另一个方法或参数,并调用它,这样不支持 Markers 或其等效内容的实现无需进行任何更改。
我在开发一个针对log4j2的Clojure库,该库支持标记和MDC以及通过MapMessage等完成的结构化日志记录: https://github.com/seancorfield/logging4j2 -- 欢迎您在此早期阶段给予反馈。

1 个答案

0

我们已经将日志记录迁移到了带有标记的结构化记录,如下文所述:https://stackoverflow.com/a/60101309/8162407

在clojure.tools.logging上使用了薄包装,对此非常满意。点赞。

在这里是否还有对tools.logging的需求,如果有,那是什么?
我认为这涉及到ct.l是否能够泛型地在所有(Java)日志库中支持上下文或标记?

就个人而言,我不太清楚人们到底有多么频繁地更改日志实现,所以我认为这样做不值得。如果你已选择了日志实现,你可以通过Java互操作性随心所欲地使用MDC或标记...
如何结合 tools.logging 使用标记?我知道通过宏可以轻松实现 MDC,但如何动态传递标记呢?
...