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地址或其他类似信息,这比能够根据不同的日志“类型”进行筛选(标记)更为重要。

所以,我认为这里的要点是,一些人会想要标记,一些人会想要MDC,一些人会两者都要,而一些人则不关心这两个方面。

标记直接影响API,因为它们会传递给error()、warn()等调用。鉴于c.t.l已经提供了变元调用和将Throwable作为第一个参数的特殊情况,我不太确定如何为添加标记修改API(尤其是当每个日志器实现都有自己的不同类时)?

也许可以创建新的API,例如“errorm”、“warnm”、“infom”等,将第一个参数视为标记?您如何在不破坏现有实现的情况下将此添加到底层的write!调用中?
如您所说,可能会需要一个新的API,例如“{log}m”,我很高兴。
至于write!方法,我会添加另一个方法或参数个数,并调用它,这样不支持标记或类似内容的实现就不需要做出任何更改。
我正在开发一个针对log4j2的Clojure库,它支持标记、MDC和结构化日志记录(通过MapMessage等):https://github.com/seancorfield/logging4j2 -- 欢迎在此早期阶段提供反馈。

1 个回答

0

我们将其移植至具有标记的结构化日志记录,如这里所写:https://stackoverflow.com/a/60101309/8162407

通过一个clojure.tools.logging的轻量级封装。真的非常满意。点赞。

这里还有没有人对tools.logging有需求,如果有,是什么需求?
我认为有一个问题,那就是c.t.l是否可以支持所有(Java)日志库的通用上下文或标记?

就我个人而言,我不确定人们有多频繁地更改日志实现,因此我认为这没有价值。如果你已经选择了日志实现,你可以使用Java互操作性以任何方式与MDC或标记一起使用...
如何将与tools.logging结合使用标记?我知道MDC可以通过宏轻松完成,但如何动态传达标记?
...