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

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

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

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

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

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

---

[1] -通过询问如何使用标记，我并不是在问如何使用API（这其实很简单）-我指的是更一般的级别，即如何始终如一地使用标记设置日志记录首先，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。这样，您可以轻松地grep一个用户的会话以查看他们所做的一切

第二，标记

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

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

经验法则：

• MDC用于将多个事件与几个“实体”关联起来
• 标记用于“特殊”事件，您希望从常规事件中筛选出这些事件

---

首先，正如@darioo所说：
• MDC用于将多个事件与几个“实体”关联起来
• [标记]用于您希望从常规事件中筛选的“特殊”事件
因此，您希望使用MDC进行此操作的断言。标记用于突出显示“特殊”事件——过滤，如果愿意的话——而不是“切片”。例如，您可以基于特定用户进行切片，但可以基于任何意外的异常进行筛选。在本例中，您将创建一个用户MDC维度和一个意外异常标记

---

但这显然没有解决你心中的问题。您所指的是“如何一致地使用标记设置日志记录的更一般级别”。因此，让我们讨论一下：
MDC用于切片和切割，标记用于过滤这些活动在测试和生产过程中进行。因此，当测试/生产开始时，您需要确定哪些维度可能有助于对日志数据进行切片，哪些情况可能有助于对其进行过滤每个维度获得一个MDC维度。每个案例都有一个标记。就这么简单
开发人员无需在此做出任何决定。在设计时，应由一个人或团队决定需要支持哪种切片、切割和过滤。这应该通过想象一个人期望他们执行什么样的分析任务来实现
同一个人或团队应决定命名约定这完全是武断的。选择一些在美学上令人愉悦、自我描述（最重要）且足够具体的东西，以免与以后添加的内容发生冲突。连字符vs.下划线是非常挑剔的，令人担忧地离题，但请注意，ESL员工阅读下划线可能不会那么容易混淆（至少与CamelCase相比）；同时，据报道，这让一些开发人员感到恼火，因为他们在获取必要的密钥时感到尴尬
就决定政策而言，这只意味着定义在哪些情况下需要使用给定的标记或MDC维度。保持紧密（集中、慎重），但如果开发人员觉得维度和标记集不足以完成手头的任务，则允许他们提供反馈。根据需要修改/添加尺寸和/或属性
了解此政策几乎必然是特定于项目的。并非每个项目都需要相同类型的日志分析。想象一些噩梦场景。然后想象一下，您希望如何分析该场景中的日志。您可能不想编写复杂的脚本来尝试跟踪哪个消息属于哪个上下文，哪个状态是哪个时间，对吗？将任何必要的信息编码为尺寸和标记，并在出现问题时为自己省去一些麻烦。
标记可用于着色或着色