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

Best practices for using Markers in SLF4J/Logback

提问by Roland Tepp

We are using SLF4J+Logback combination at our project for a while now and are quite happy with it, but our logging strategy is fairly simple, using straightforward class based loggers and no fancy stuff like MDC or Markers.

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

What I want to know is if anybody in the community actually uses these features and how they are used to improve logging/filtering.

我想知道的是，社区中是否有人实际使用这些功能以及如何使用它们来改进日志记录/过滤。

I am specially interested in where, why and how would one use^[1]Markers for logging. They strike me as a pretty neat feature for adding semantic context into the logging - e.g. while a class may be handling multiple concerns, one may use task/concern specific markers to discriminate log statements.

我对在哪里、为什么以及如何使用^[1]标记进行记录特别感兴趣。在我看来，它们是将语义上下文添加到日志记录中的一个非常巧妙的功能——例如，当一个类可能处理多个问题时，一个人可能会使用任务/问题特定标记来区分日志语句。

What may be the best practices, conventions or strategies for creating and using markers in logging.

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

Update:I guess, what I am really after is not so much whyto use markers, but rather the howpart — is there some good practices of naming markers (e.g. using plain text with spaces or dash/underscore/punctuation delimited keyword style names), should there be some sort of pool of "standard names", naming stuff based on the business functions. The questions I can probably figure out for myself, but if I want to use these features systematically and introduce them to a team of developers, it makes sense to have some formalizeable set of guidelines around...

更新：我想，我真正想要的不是为什么要使用标记，而是如何使用标记- 是否有一些命名标记的好做法（例如使用带有空格或破折号/下划线/标点符号分隔的关键字样式名称的纯文本） )，是否应该有某种“标准名称”池，根据业务功能命名内容。我可能会自己解决这些问题，但是如果我想系统地使用这些功能并将它们介绍给一个开发团队，那么围绕......

---

---

^[1]- By asking how to usemarkers I am not really asking how to use API (it is really quite straight forward) - I am rather referring to the more general level of how would one set up logging around using markers consistently

^[1]- 通过询问如何使用标记，我并不是真的在问如何使用 API（这真的很简单） - 我更倾向于指的是如何设置使用标记一致地记录日志的更一般的级别

采纳答案by user359996

First, as @darioo said:

首先，正如@darioo 所说：

• MDC is used for associating multiple events with few "entities"
• [Markers] are used for "special" events that you want to have filtered from usual ones

• MDC 用于将多个事件与少数“实体”相关联
• [标记] 用于您希望从通常事件中过滤掉的“特殊”事件

So your assertion that You want to use MDC for this. Markers are for highlighting "special" events--filtering, if you will--rather than "slicing". For example, you might slice based on a particular user, but filter based on any unexpected exceptions. In this case, you would create a UserMDC dimension and an UnexpectedExceptionMarker.

所以你断言你想为此使用 MDC。标记用于突出显示“特殊”事件——过滤，如果你愿意——而不是“切片”。例如，您可能会根据特定用户进行切片，但会根据任何意外异常进行过滤。在这种情况下，您将创建一个用户MDC 维度和一个UnexpectedException标记。

---

---

But this apparently doesn't address the question you had in mind. You are "rather referring to the more general level of how would one set up logging around using markers consistently." So let's address that:

但这显然没有解决您想到的问题。您“而是指如何一致地使用标记设置日志记录的更一般级别。” 所以让我们解决这个问题：

MDC is for slicing and dicing, and Markers are for filtering. These activities are carried out during testing and in production. As such, you need to decide which dimensions you expect may be useful to slice the log data by, and which cases it might be useful to filter it against, when testing/production comes around. Each dimension gets an MDC dimension. Each case gets a Marker.It's as simple as that.

MDC 用于切片和切块，Markers 用于过滤。这些活动在测试和生产期间进行。因此，当测试/生产出现时，您需要决定您期望哪些维度可用于对日志数据进行切片，以及在哪些情况下对其进行过滤可能有用。每个维度都有一个 MDC 维度。每个案例都有一个标记。就这么简单。

The developers don't need to make any decisions here.A single person or team should decide, at design time, what sort of slicing, dicing and filtering needs to be supported. This should be informed by imagining what sort of analysis tasks one expects they may be asked to perform.

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

This same person or team should decide on the naming convention. It's entirely arbitrary. Choose something that's aesthetically pleasing, self-descriptive(most important), and specific enough to be unlikely to conflict with later additions. Hyphens vs.underscores is exceedingly nitpicky and alarmingly beside the point, but note it may be less confusing for ESL employees to read underscores (at least compared to CamelCase); at the same time, this reportedly annoys some developers due to the awkwardness of reaching the requisite keys.

同一个人或团队应该决定命名约定。这完全是任意的。选择美观、自我描述（最重要）和足够具体的东西，不太可能与以后的添加冲突。连字符与下划线非常挑剔且令人震惊，但请注意，ESL 员工阅读下划线可能不那么令人困惑（至少与 CamelCase 相比）；与此同时，据报道，由于难以获得必要的密钥，这让一些开发人员感到恼火。

As far as deciding on a policy, this just means defining in which cases a given Marker or MDC dimension needs to be employed. Keep this tight (centralized, deliberate), but allow for feedback from developers if they feel the set of dimensions and markers are insufficient for the task at hand. Revise/add dimensions and/or attributes as appropriate.

就决定策略而言，这仅意味着定义在哪些情况下需要使用给定的标记或 MDC 维度。保持紧密（集中、深思熟虑），但如果开发人员觉得维度和标记集不足以完成手头的任务，则允许他们提供反馈。根据需要修改/添加维度和/或属性。

Understand this policy will almost necessarily be project-specific. Not every project needs the same sort of logging analysis. Picture some nightmare scenarios. Then imagine how you would like to be able to analyze the logs in that scenario. You probably don't want to have to write a complicated script to try and track which message belongs to which context, and which state is which at which time, right? Encode whatever such information is necessary as dimensions and Markers, and save yourself some of the hassle if something does go wrong.

了解此政策几乎必然是针对特定项目的。并非每个项目都需要相同类型的日志分析。想象一些噩梦般的场景。然后想象一下您希望如何分析该场景中的日志。您可能不想编写复杂的脚本来尝试跟踪哪个消息属于哪个上下文，哪个状态在哪个时间，对吧？将任何此类必要信息编码为尺寸和标记，并在出现问题时为自己省去一些麻烦。

回答by darioo

First, MDC.

首先，MDC。

MDC is really useful in an environment where you have one "entity" that is associated with some behaviour. A typical example: user interacting with a web application. So, let's say you have many users messing around with your web app. Using MDC, you can easily track them without too much hassle. Simplified example:

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

Here, you're using MDC in two places: for username and for session ID. This way, you can easily grep one user's session to see everything they've been doing.

在这里，您在两个地方使用 MDC：用于用户名和会话 ID。这样，您可以轻松地 grep 一个用户的会话以查看他们所做的一切。

Second, markers.

第二，标记。

Markers are usually used for "special" circumstances, such as sending an email to an administrator for some seriously critical errors. Not all errors always fall in the same category; some have to be dealt in an appropriate way.

标记通常用于“特殊”情况，例如针对某些严重的严重错误向管理员发送电子邮件。并非所有错误都属于同一类别；有些必须以适当的方式处理。

Or, when a user quits from your service, it usually goes to an INFO log, but you can also use a marker for such instances, if you want events such as this one to go in a separate log file, so you can monitor it more easily for statistical gathering of users quitting.

或者，当用户退出您的服务时，它通常会转到 INFO 日志，但您也可以对此类实例使用标记，如果您希望将此类事件放入单独的日志文件中，以便您可以对其进行监控更容易统计用户退出。

Rule of thumb:

经验法则：

• MDC is used for associating multiple events with few "entities"
• markers are used for "special" events that you want to have filtered from usual ones

• MDC 用于将多个事件与少数“实体”相关联
• 标记用于您希望从通常事件中过滤掉的“特殊”事件

回答by Ceki

Markers can be used to coloror mark a singlelog statement. What you do with these colors, i.e. markers, is entirely up to you. However, two patterns seem to be common (the first more common than the second) for marker usage.

标记可用于为单个日志语句着色或标记。您如何使用这些颜色（即标记）完全取决于您。但是，对于标记的使用，两种模式似乎很常见（第一种比第二种更常见）。

1. Triggering: Some appender could be instructed to take an action in the presence of a certain marker. For example, SMTPAppendercan be configured to send an email whenever a logging event is marked with the NOTIFY_ADMINmarker regardless of the log level. See marker-based triggeringin the logback documentation. You may also combine log levels and markers for triggering.

2. Filtering: You could for example color/mark all your persistence related logs (in various and multiple class files) with the color "DB". You could then filter for "DB": disable logging except for log statements marked with DB. See the chapter on filtersin the logback documentation for more information (search for MarkerFilter).

1. 触发：可以指示某些 appender 在存在某个标记的情况下采取行动。例如，无论日志级别如何，SMTPAppender都可以配置为每当使用NOTIFY_ADMIN标记标记日志记录事件时发送电子邮件。请参阅logback 文档中的基于标记的触发。您还可以组合日志级别和标记以进行触发。

2. 过滤：例如，您可以使用颜色“DB”为所有与持久性相关的日志（在各种和多个类文件中）着色/标记。然后，您可以过滤“DB”：除了标有 DB 的日志语句外，禁用日志记录。有关更多信息，请参阅logback 文档中有关过滤器的章节（搜索 MarkerFilter）。

回答by Mark D

Just as an addendum, if you are using logstash and have json logging enabled, there's another potential use of Marker - for logging variables to associate with a specific log message. This is more consistent and easier to parse than including it in the message body. Very useful, if it suits your use-case.

就像附录一样，如果您使用的是 logstash 并启用了 json 日志记录，那么标记还有另一个潜在用途 - 用于记录变量以与特定日志消息关联。这比将其包含在消息正文中更一致且更易于解析。非常有用，如果它适合您的用例。

See details here:

在此处查看详细信息：

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

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