在SLF4J / Logback中使用标记的最佳实践 [英] Best practices for using Markers in SLF4J/Logback

问题描述

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

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.

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

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

我特别感兴趣的是，在哪里，为什么以及如何使用 ^[1] 标记进行记录。他们将我作为一个非常简洁的功能，将语义上下文添加到日志中 - 例如虽然一个类可能正在处理多个问题，但可以使用任务/关注点特定标记来区分日志语句。

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.

创建和创建的最佳实践，约定或策略可能是什么？在记录中使用标记。

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 why to use markers, but rather the how part — 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] - 询问如何使用标记我不是真的在问如何使用API（它真的非常直接） - 我更倾向于指出如何使用标记一致地设置日志记录的更一般级别

^[1] - By asking how to use markers 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

推荐答案

首先，正如@darioo所说：

First, as @darioo said:

• MDC用于将多个事件与少数实体相关联


• [标记]用于您希望从常规过滤的特殊事件

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

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 User MDC dimension and an UnexpectedException Marker.

但这显然没有解决你想到的问题。您更倾向于指出如何使用标记始终如一地设置日志记录的更一般级别。因此，让我们解决一下：

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用于切片和切割，而标记用于过滤。 这些活动在测试和生产过程中执行。因此，您需要确定哪些维度可能对切割日志数据有用，以及在测试/生产出现时对哪些维度进行过滤可能有用。 每个维度都有一个MDC维度。每个案例都有一个标记。就这么简单。

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.

开发人员不需要在此做出任何决定。单个人或团队应决定在设计时，需要支持哪种切片，切块和过滤。应该通过想象可能要求他们执行哪种分析任务来了解这一点。

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.

同一个人或团队应该决定命名约定。 完全随意。选择一些美学上令人愉悦的东西，自我描述性（最重要的），并且具体到足以与以后的添加不一致。连字符 vs。下划线非常挑剔且令人震惊，但请注意，ESL员工阅读下划线可能不那么令人困惑（至少与CamelCase相比）;与此同时，由于获得必要密钥的尴尬，据报道这会使一些开发人员感到恼火。

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.

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

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.

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

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.

这篇关于在SLF4J / Logback中使用标记的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！