到底哪些系统组件应该进行日志记录?

日志难题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

干扰数据该如何处理?

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

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

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

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

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

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

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

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

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

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

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