【51CTO.com快译】要为日志记录机制找到合适的“度”殊非易事——日志太多则无关内容泛滥，日志太少则可能错过重要信息。这一问题在微服务架构下则变得更为棘手。

日志难题

根据用户们的反馈，其面对的两大常见难题为：哪些组件需要进行日志记录，如何对需要收集的数据进行优先级排序。

大家可能或多或少接触过某些复杂的系统，其中包含大量组件与分布式服务。对于每项组件，我们都需要考虑以下三个问题：

• 其是否进行日志记录?
• 如果没有，是否应当进行记录?
• 是否应该利用Loggly等日志管理服务对其日志进行集中管理?

当然，日志作为解决问题的重要参考，一般来说自然是越多越好。不过收集及存储日志数据都会带来成本，因此今天我们将探讨如何找到正确的日志记录平衡点。

宏观视角：DevOps眼中的日志记录思维

DevOps中的一大重要原则就是让开发与运维人员站在同一阵营。为了实现这一目标，双方需要以统一的角度了解堆栈中各组件的运行情况。

就目前而言，客户通常只保留那些关键性应用的日志信息，也只有这部分信息会由Loggly等日志管理解决方案进行操作。应用是支撑业务的基础，其负责为客户提供所需，而技术人员则需要通过统计结果了解应用代码中所存在的主要问题。

不过真正的难题在于，我们的应用始于何处又终于何处?

Web服务器?没错。应用所使用的数据库?差不多。不少用户并没有将数据库日志纳入集中管理范畴。那么操作系统、虚拟机管理程序、云基础设施组件又 是否应该得到重视?存储后端呢?说到这里，问题变得愈发复杂。负载均衡、路由器与交换机?很多朋友认为，越是接近底层的元素，越不需要进行日志数据的集中 化收集与管理。

这些日志来源被排除在外的理由主要有两点：

• 这些组件通常比较可靠。
• 其通常拥有自己的日志监控解决方案。

有鉴于此，大家往往不会将此类日志数据纳入集中日志管理方案。某些用户甚至将其视为“信噪”。他们更倾向于监控应用日志，并通过路由器Web前端或者AWS CloudWatch来了解路由器或AWS Linux实例的运行状态。

这类做法的问题在于其本质上在强调并且使用“日志孤岛”，这意味着我们无法以集中化的方式，确保包括开发与运维在内的每一位技术人员获取到综合性应 用运行状态。另外，假如这些底层组件对于业务极为重要，那么一旦遭遇极为罕见的组件缺陷或者是精心伪装的恶意软件入侵，后果会如何?虽说这种机率确实很 低，但其造成的后果难以承受。因此大家应当将其视为一种火灾保险式的预备手段——即使家中从未失火，我们也不妨买上一份。

日志数据在DevOps流程中的定位

由于日志数据属于涵盖每种组件及每个层的普遍性元素，因此以集中方式进行日志数据管理能够：

• 加快故障排查速度并及时通知相关度最高的人员。
• 立足于堆栈内各层监控问题。监控工具多种多样，但相当一部分会迫使用户以互不关联的方式审视独立组件。
• 实现代码持续部署。日志管理应当作为持续集成测试周期的组成部分。测试环境越全面，需要进行日志记录的组件就越多。

将这些分析结论有效传递给每位相关成员，能够切实推动DevOps思维的接纳度与普及。

干扰数据该如何处理?

日志来源的增加无疑会令日志数据中出现更多干扰信息，即使没那么严重，我们的日常工作强度也会因此增加。而且必须承认，某些日志数据在通常情况下几乎用不到。

在使用现代日志管理解决方案时，干扰数据的存在确实令人非常头痛。我们可以利用多种方式进行日志过滤，通过仪表板监控相关指标，保存所关注信息子集的搜索与过滤机制等等。

如果继续沿用之前提到的火灾比喻，那么“干扰数据太多”就有点像买来一套实际容量只有20%的灭火器。之所以这样选择，是因为它更轻便也更便宜，对应小规模起火也绰绰有余。

集中化日志记录是否矫枉过正?

答案是否定的。简而言之，我们不需要记录一切，但我们所记录的一切都应当以集中方式得到收集与管理。

性能问题?其实是润滑问题

一家企业客户曾经遭遇到性能问题——作为网络游戏运营商，其面对着高强度后端数据库与存储I/O资源需求。当问题出现后，玩家们在社交媒体上大加抱 怨并纷纷离去。而通过日志检查，技术人员们初步断定数据库正是造成问题的罪魁祸首。在进一步检查数据库相关存储机制时，大家发现这些RAID系统的日志并 未进行集中化管理，而且出现问题时其监控工具仍然显示一切正常。

但就在调查进行时，RAID监控系统又突然发出警报：大量磁盘出现故障，RAID已经无法对其加以恢复。面对这样的状况，技术人员根本弄不清楚这是随机事件还是蓄意攻击的结果。整个恢复周期持续了100多个小时，无疑也给企业造成了严重损失。

最终取证工程师对Linux操作系统的内核日志进行了查阅，并发现此类故障自数个月之前就开始发生，并一直在缓慢地不断增长。遗憾的是，存储系统本身的监控工具并没能正确发现并报告这些问题，因为其认为实际情况尚未达到断定磁盘或阵列遭受威胁的预设阈值。

内核日志也显示只有特定品牌及型号的磁盘受到了影响。制造商在检查后发现某些批次的特定型号磁盘存在质量问题，其磁盘主轴轴承润滑剂存在蒸发现象，而该客户正是少数受到影响的受害者。

讽刺的是，这一切都早已被记录在日志当中，但却由于缺少集中化日志管理机制而被人们忽略。

虽然没有明确的统计数据作为支持，但相信行业中因为缺少可靠日志数据分析系统而导致的负面影响绝对不在少数。因此，以看待保险产品的方式积极采用集中化日志管理方案应当成为企业运营中的常态与共识。

原文：Which Components of Your System Should You Log?

【51CTO.com独家译稿，合作站点转载请注明来源】