通过监控日志、指标等提高性能和安全性

在本系列的上一篇文章中——DevSecOps 中数据收集的一切指南——我们讨论了数据收集的重要性。在本文中，我们将探讨监控在可观察性中的作用，尤其是当它与安全性、性能和可靠性相关时。

监控对于检测生产中发生的问题和异常值至关重要，并允许 DevSecOps 团队在问题造成严重损害之前识别和解决问题。监控性能下降或可疑活动可能会产生警报和自动响应，以隔离潜在的问题或攻击。

在本文中，我们将详细介绍监控，提供几个用例和最佳实践，并讨论监控如何通过可观察性具体提高安全性、性能和可靠性。

监控在可观察性中的作用是什么？

在可观察系统中，我们从日志、指标和分布式跟踪中收集数据。虽然对于非常小的系统，您可以手动浏览和搜索日志，将指标可视化为图表，并通过显示流量如何流经系统的图表进行跟踪，以便识别问题——在规模上，这还不够。您需要监控，这是一个自动化过程，可以密切关注这些数据并适当地提醒您。 （有关监控和可观察性之间差异的更详细处理，您可以查看此资源。）

在企业中，您需要自动化的方式来过滤、聚合、丰富和分析所有这些数据。企业还需要自动化的方法来在检测到异常情况时采取行动。自动响应可以通知负责团队甚至直接采取补救措施。

在医学等其他领域，监测患者的生命体征是一项关键活动，可以挽救生命。监控软件系统非常相似，我们甚至在执行健康检查和讨论不同组件的健康时使用相同的方法。

理论够多了，让我们看一些具体的监控示例。

监控可观察性的用例

以下是一些利用监控的典型用例：

• Web 应用程序是许多大型分布式系统的主要部分，也是数字优先业务成功的关键。监控 Kubernetes 容器化应用程序或仅监控 Web 服务器日志是否出现过多的错误代码（例如4xx或5xx ）可以帮助团队在性能和可靠性问题成为重大问题之前解决它们。
• 在基础架构级别，监控服务器的 CPU、内存和存储非常重要。与大多数企业一样，您可能会使用自动缩放，以便您的系统可以分配更多容量。平台日志在资源发生变化时捕获，例如资源被供应、取消供应或重新配置时。但是，监控这些资源指标和日志可以帮助您确保在配额和限制范围内工作，并且在资源规划和预算方面可以帮助您的组织。
• 数据存储是大多数大型系统的核心。如果您的数据丢失、损坏或不可用，那么您的情况就很严重了。要跟踪您的数据，您需要监控数据库连接、查询持续时间指标、磁盘空间、备份和错误率。您还应该了解您的数据存储，并在观察到超出预期范围的值时设置警报，例如查询速度慢、错误率高或磁盘空间不足。您还可以为数据库设置日志记录以捕获连接、查询以及对字段或表的更改。监视数据库日志不仅可以帮助您检测可以提高性能和可靠性的地方，还可以帮助您检测是否正在执行恶意（或无意）操作的安全性。

请注意，监控比设置一个简单的条件（例如“两分钟内超过五个INSERT查询到orders数据库”）并在满足该条件时触发警报要复杂得多。季节性可能在起作用，使用模式会在一天、一周或一年的特定时间导致峰值。检测意外行为的有效监控会考虑上下文，并可以根据过去的数据识别趋势。

这种类型的监控，尤其是在使用大规模结合可观察性、监控和安全性的工具实施时，可能会非常有效，例如在 Sumo Logic 和 Infor 的案例研究中，Infor 能够节省 5,000 小时的时间事件。

监控如何特别有助于提高性能和可靠性？

监视通过及早发现问题以避免降级来提高系统的性能和可靠性。性能问题通常会变成可用性和可靠性问题。在存在超时的情况下尤其如此。例如，假设应用程序在 60 秒后超时。由于最近的性能问题，许多请求的处理时间突然超过 60 秒。所有这些请求现在都将失败，并且应用程序现在不可靠。

解决此问题的常见最佳做法是监控高优先级服务和应用程序关键路径中任何组件的四个黄金信号：延迟、流量、错误和饱和度。

潜伏

处理请求需要多长时间？请注意，成功请求的延迟可能与失败请求的延迟不同。延迟的任何显着增加都可能表明系统性能下降。另一方面，任何显着的减少都可能表明某些处理被跳过。无论哪种方式，监控都会引起对可能问题的关注。

交通

监控流量可以让您了解每个组件的总体负载。可以针对不同的组件以不同的方式测量流量。例如：

• REST API：请求数
• 后端服务：队列的深度
• 数据处理组件：已处理数据的总字节数。

流量的增加可能是由于业务的有机增长，这是一件好事。但是，它也可能表明上游系统中产生的流量比以前异常多的问题。

错误

任何组件错误率的增加都会直接影响系统的可靠性和实用性。此外，如果失败的选项自动退役，这会导致流量增加，进而可能导致性能问题。

饱和

在可用资源中，服务或应用程序使用了多少资源？这就是饱和度监测告诉你的。例如，如果磁盘已满，则将日志写入该磁盘的服务将在每个后续请求中失败。在更高的层次上，如果 Kubernetes 集群的节点上没有可用空间，那么新的 pod 将处于待处理状态并且不会被调度，这可能会导致延迟问题。

正如您所注意到的，这四个黄金信号是相互关联的。问题通常出现在多个信号中。

监控如何具体有助于提高安全性？

虽然任何系统健康问题都会直接或间接影响安全性，但监控可以帮助检测和缓解一些直接威胁。

• 任何异常，例如 CPU 使用率过高或请求量过大，都可能是攻击者试图造成分段错误、进行非法加密挖矿或对系统发起 DDoS 攻击。
• 到达异常端口的异常数量的数据包可能是端口敲击攻击。
• 具有有效用户名和无效密码的大量 401 错误（身份验证错误）可能是字典攻击。
• 大量 403 错误（禁止访问）可能是攻击者使用受感染帐户进行的权限升级。
• 导致 400 错误增加的公共 API 有效负载可能是攻击者试图恶意破坏面向公众的 Web 应用程序。
• 在工作时间以外下载大量数据或任何敏感数据可能是受感染员工或流氓内部人员的渗漏攻击。

提高性能和安全性的监控最佳实践

一个系统由多个组件组成，但它不仅仅是各个部分的总和。在基本层面上，您应该监控系统的每个组件（至少在关键路径上）以获取四个黄金信号。这在实践中意味着什么？

• 观察关键指标
• 建立正常操作的指标范围
• 当组件偏离可接受范围时设置警报

您还应该密切注意外部依赖性。例如，如果您在云端运行或与第三方服务提供商集成，那么您应该监控您所依赖的公共端点并设置警报以检测问题。如果第三方出现故障或其性能下降，这可能会导致您的系统发生级联故障。

不可能拥有 100% 可靠的组件。但是，监视可以通过检测组件（内部和外部）的问题并更换它们或优雅地降低服务质量，帮助您从不可靠的组件创建可靠的系统。例如，如果您在多区域配置中运行系统并且一个区域出现问题，则监控可以检测到这一点并触发将所有流量重新路由（手动或自动）到其他区域。

出于安全考虑，这四个信号也可能是妥协的辅助指标。尤其是这种情况，例如，如果您发现端点设备或云工作负载 CPU 出现峰值，或者登录尝试失败的次数增加。但是，由于您要与恶意对手打交道，因此安全监控必须非常慎重。您必须定义每个组件和整个系统的攻击服务，并确保您收集的信息足以检测问题。例如，要检测数据泄露，您可以监控不同应用程序和服务向内部网络之外发送的 IP 地址和数据量。如果您没有这些数据，您将对这种攻击方法视而不见。

实施监控策略

设置数据收集后，您可以按照以下步骤实施稳健有效的监控策略。

1. 识别关键资产。

作为数据收集的一部分，您已经对所有资产进行了全面盘点。现在，您的任务是确定必须密切监控以预防和减轻灾难的关键资产。说起来容易，“只需监控一切”，但监控需要考虑成本。为您的暂存和开发环境或实验服务监控和发出警报会给您的工程师带来很多不必要的压力。凌晨 3 点频繁针对无关紧要的问题发出警报会导致警报疲劳，从而削弱您的团队在问题真正重要时解决问题的动力。

2. 为每项关键资产指定所有者。

一旦确定了关键资产，您就需要为每一项资产指定一个明确的所有者。所有者可以是个人或团队。对于一个人，一定要确定后备方案。当人们加入和离开组织或转移到其他角色和团队时，保持资产所有权也很重要。

3. 为关键资产定义警报。

最终，您的监控策略将取决于您如何为不健康或可能受损的资产定义警报。您需要了解每项资产的正常情况。

如果您正在监控指标，那么定义“正常”意味着将一个属性（例如 CPU 利用率）与一个值范围（例如“50%-80%”）相关联。正常频带可以随着业务而动态变化并且可以在不同时间和不同位置发生变化。在某些情况下，您可能只有天花板或地板。通过定义正常范围，您可以创建警报以在资产所有者的资产运行超出正常范围时通知他们。

如果您正在监控日志，那么通常会根据某些日志查询的结果（例如“过去五分钟内所有 API 服务中记录的 404 错误的数量”）满足或不满足条件（例如“是”少于 10”）。日志管理和分析工具可以提供帮助。

4. 为每个警报定义运行手册。

当出现严重警报时，您会怎么做？你不想做的是试图当场弄清楚你的战略，而客户正在推特上谈论你公司不可靠的产品，而管理层正在恐慌。

运行手册是您提前准备和测试的易于跟进步骤的秘诀，可帮助您收集更多信息（例如，要查看哪些仪表板以及要运行哪些命令行脚本来诊断根本原因）并缓解操作（例如，部署应用程序的先前版本）。您的运行手册应该可以帮助您快速将问题确定为特定问题，并确定处理该问题的最佳人选。

5. 建立一个随叫随到的流程。

您有所有者、警报和操作手册。通常，警报不够具体，无法直接映射到所有者。最佳做法是将随叫随到的工程师分配到不同的业务领域。这位值班工程师将收到警报，遵循运行手册，查看仪表板，并尝试了解根本原因。如果他们无法理解或解决问题，他们会将问题上报给所有者。请记住，这个过程可能很复杂；通常，问题是由于一连串的故障而发生的，需要多个利益相关者协作才能解决问题。

6. 走向自我修复。

运行手册很棒，但维护复杂的运行手册和培训值班工程师遵循它们需要付出很多努力。最后，您的补救过程仍然取决于缓慢且容易出错的人。如果您的 runbook 不是最新的，遵循它可能会加剧危机。

理论上，可以通过编程方式执行 Runbook。如果 runbook 说，“当警报 X 触发时，进程 Y 应该重新启动”，那么脚本或程序可以收到警报 X 的通知并重新启动进程 Y。同一程序可以在重启后监视进程 Y，确保一切正常，并最终生成事件报告——所有这一切都无需唤醒值班工程师。如果自愈操作失败，则可以联系值班工程师。

7. 建立事后分析流程。

自我修复很棒，但是，一盎司的预防胜过一磅的治疗，所以最好首先预防问题。每一个事件都是一个学习的机会，并有可能预防一整类问题。例如，如果由于错误代码进入生产环境而发生多起事件，那么事件事后分析的教训可能是改进暂存阶段的测试。如果值班工程师对警报的响应太慢或运行手册已过时，则这可能表明团队应该投资于一些自我修复实践。

结论

监控是一般可观察性的重要组成部分，尤其是安全性的可观察性。大规模地让人类“只是时不时地看看”各种仪表板和图表来检测问题是不切实际的。您需要一整套事件响应实践，包括识别所有者、设置警报、编写操作手册、自动化操作手册以及设置随叫随到流程和事后分析流程。

祝你有美好的一天！