在 SLF4J/Logback 使用标记的最佳实践

我们在我们的项目中使用 SLF4J + Logback 组合已经有一段时间了,我们对此非常满意,但是我们的日志记录策略相当简单,使用简单的基于类的日志记录器,没有像 MDC 或 Markers 这样的花哨的东西。

我想知道的是,社区中是否有人真正使用这些特性,以及如何使用它们来改进日志记录/过滤。

我特别感兴趣的是在哪里,为什么和如何使用 [1]标记进行日志记录。在我看来,它们是在日志中添加语义上下文的一个非常简洁的特性——例如,当一个类可能处理多个关注点时,可以使用特定于任务/关注点的标记来区分日志语句。

在日志记录中创建和使用标记的最佳实践、约定或策略是什么。

更新: 我想,我真正想要的不是使用标记的 为什么,而是使用 怎么做部分 & mash; 是否有一些命名标记的好方法(例如使用带空格的纯文本或破折号/下划线/标点符分隔的关键字样式名称) ,是否应该有一些类型的“标准名称”,根据业务功能命名东西。这些问题我可以自己想出来,但是如果我想系统地使用这些特性,并将它们介绍给一个开发团队,那么围绕这些特性建立一套形式化的指导方针是有意义的..。


[1] -通过询问如何使用 使用标记,我并不是真的在询问如何使用 API (它实际上非常直接)-我指的是如何使用标记建立日志记录的更一般的层次

73671 次浏览

首先是 MDC。

在您有一个与某些行为相关联的“实体”的环境中,MDC 非常有用。一个典型的例子: 用户与 Web 应用程序交互。因此,让我们假设有许多用户在使用您的 Web 应用程序。使用 MDC,您可以轻松地跟踪它们,而不会遇到太多麻烦。简单的例子:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

在这里,您在两个地方使用 MDC: 用户名和会话 ID。通过这种方式,您可以轻松地抓取一个用户的会话,以查看他们所做的一切。

第二,记号笔。

标记通常用于“特殊”情况,例如向管理员发送一封电子邮件,以查看一些严重的关键错误。并非所有的错误总是属于同一类; 有些错误必须以适当的方式处理。

或者,当一个用户退出你的服务时,它通常会转到一个 INFO 日志,但是你也可以为这样的实例使用一个标记,如果你想让这样的事件在一个单独的日志文件中进行,这样你就可以更容易地监视它,以便收集用户退出的统计数据。

经验法则:

  • MDC 用于将多个事件与少量“实体”关联
  • 标记用于“特殊”事件,您希望从通常的事件中筛选这些事件

首先,正如@darioo 所言:

  • MDC 用于将多个事件与少量“实体”关联
  • [标记]用于“特殊”事件,您希望从常规事件中过滤掉这些事件

因此,您要使用 MDC 进行此操作的断言。标记用于突出显示“特殊”事件——如果你愿意的话,可以过滤——而不是“切片”。例如,可以根据特定用户进行切片,但是可以根据任何意外异常进行筛选。在这种情况下,您将创建一个 用户 MDC 维度和一个 意外例外标记。


但这显然不能回答你想要的问题。您“宁愿指的是如何使用一致的标记来设置日志记录的更一般的级别。”所以让我们解决这个问题:

MDC 是 切片和切丁,标记是 过滤这些活动在测试和生产过程中进行.因此,您需要决定在测试/生产时,您期望哪些维度可能有助于对日志数据进行切片,以及哪些情况下可能有助于对其进行过滤。就这么简单。

开发人员不需要在这里做任何决定。一个人或一个团队应该决定,在设计时间,需要支持什么样的切片、切块和过滤。这应该通过想象一个人期望他们可能被要求执行什么类型的分析任务来获得信息。

应由同一人或同一团队决定变数命名原则。这完全是随意的.选择一些美观的东西,自我描述(最重要的) ,并具体到不太可能与后来的添加冲突。连字符 对。下划线过于吹毛求疵,而且离题太远,但是请注意,对 ESL 的员工来说,阅读下划线可能不会那么令人困惑(至少与 CamelCase 相比) ; 同时,据报道,这会让一些开发人员感到恼火,因为他们很难找到所需的键。

至于决定一个政策,这只是意味着 定义在哪些情况下需要使用给定的标记或 MDC 维度。保持这种紧密(集中的,深思熟虑的) ,但是如果开发人员觉得维度和标记的集合不足以完成手头的任务,那么允许他们提供反馈。适当修改/添加尺寸和/或属性。

了解 这项政策几乎必然是针对具体项目的。不是每个项目都需要相同类型的日志分析。想象一下噩梦的场景。然后想象一下您希望如何能够分析该场景中的日志。您可能不希望编写一个复杂的脚本来尝试跟踪哪个消息属于哪个上下文,以及在哪个时间哪个状态,对吗?编码任何这样的信息是必要的尺寸和标记,并节省自己的一些麻烦,如果有些事情出错了。

标记可用于 颜色或标记 单身日志语句。你怎么处理这些颜色,也就是标记,完全取决于你。然而,对于标记的使用,有两种模式似乎很常见(第一种比第二种更常见)。

  1. 触发 : 某些附加物可以被指示在某个标记出现的情况下采取行动。例如,无论日志级别如何,只要用 NOTIFY_ADMIN标记标记日志事件,就可以将 SMTPAppender配置为发送电子邮件。请参阅日志回溯文档中的 基于标记的触发。还可以将日志级别和标记组合起来用于触发。

  2. 过滤 : 例如,您可以用颜色“ DB”标记所有与持久性相关的日志(在各种和多个类文件中)。然后您可以筛选“ DB”: 除了用 DB 标记的日志语句外,禁用日志记录。有关更多信息,请参见 logback 文档中的 过滤器一章(搜索 MarkerFilter)。

作为补充,如果您正在使用 logstash 并且启用了 json 日志记录,那么 Marker 还有另一个潜在用途——用于将日志变量与特定的日志消息关联起来。这比将其包含在消息体中更一致,更容易解析。非常有用,如果它适合您的用例的话。

点击这里查看详情:

Https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event

MDC 的优点是它们在线程中得到通知: 让我们以一个方法为例,该方法在最后发送一个日志。在整个方法和子方法的调用过程中,您可以用在程序中收集的信息填充 MDC。 当日志在最后启动时,它包含 MDC 和我们可以放在那里的所有信息 使用适当的模式,我们可以从 MDC 检索信息。

另一方面,标记直接与日志关联。