请分享您的想法参与 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 中。
工具新日志记录工具.logging是否还需要添加其他功能?
是的,需要一些代码路径来访问接收slf4j的Marker的方法。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应该是什么样子(尤其是当它们是每个日志实现不同类的时)?

可能errorm、warnm、infom等,将第一个参数作为标记处理?你将如何在不破坏任何现有实现(除c.t.l外)的情况下将其添加到底层写操作!中?
如您所说,可能需要一个像{log}m这样的新API,我很乐意接受。
关于write!方法,我会增加另一个方法或参数,然后调用它,这样不支持标记或其他类似功能的实现就不需要做出任何更改。
我正在开发一个针对log4j2的Clojure库,该库支持标记和MDC,并通过MapMessage等工具进行结构化日志记录:[https://github.com/seancorfield/logging4j2](https://github.com/seancorfield/logging4j2) -- 在这个早期阶段,我很乐意接受反馈。

1 条回答

0个投票

我们将日志记录端口到了以标记为结构化的日志记录,正如这里所写:[https://stackoverflow.com/a/60101309/8162407](https://stackoverflow.com/a/60101309/8162407)

在clojure.tools.logging上使用了一个薄包装器。真的很高兴。赞一个。

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

就我个人而言,我不太确定人们改变日志实现有多频繁,所以我认为这不是很重要。如果你已经选定了日志实现,你可以用Java互操作以任何方式使用MDC或标记...
by
如何结合tools.logging使用标记?我知道MDC可以通过宏轻松完成,但如何动态传达Marker呢?
...