业内经常讲可观测性有三大支柱：指标、日志、链路追踪，本文作者认为，还有第四大支柱：那就是配置类数据。配置类数据的变更也会影响系统的稳定性，也值得被监控，方便我们快速排查问题。
原文链接：https://www.cloudquery.io/blog/fourth-lost-pillar-of-observability-config-data-monitoring
原文作者：Yevgeny Pats
很多关于日志、指标和跟踪的内容已经被广泛讨论，因为它们确实是可观测性、应用程序和系统监控的关键组成部分。然而，经常被忽视的是配置数据及其可观测性。在这篇博客中，我们将探讨什么是配置数据，它与日志、指标和跟踪有何不同，并讨论需要什么样的架构来存储这种类型的数据以及在哪些场景中它具有价值。
日志、指标和链路追踪的快速回顾
对于那些对可观测性的三大支柱还不太了解的人来说，让我们快速回顾一下：
![]()
- 日志：系统内发生事件的详细记录。它们提供了关于特定事件的信息，包括时间戳、错误消息和其他相关细节。日志有助于调试和故障分析。
- 指标：定期收集的数值测量。它们有助于监控系统健康状况、性能和随时间的行为。示例包括 CPU 使用率、请求速率、错误率和响应时间。
- 跟踪：记录请求在分布式系统中通过不同服务的流程。跟踪提供请求流程的可见性，有助于识别瓶颈并理解依赖关系。
这些技术的后端通常是某种时间序列数据库，数据类型通常是低基数数据（可以是高基数，但通常会变得昂贵且不建议这样做）。另一个关键方面是，要获取这些指标，通常需要对系统进行插桩，即，您需要访问应用程序或基础设施，以便部署 agent 或添加 Prometheus Exporter。
配置数据：第四支柱
基础设施不仅限于 AWS EC2 实例，还包括 IAM 用户、安全工具配置、SaaS 应用程序等。这些配置数据在几个重要方面与传统的可观测性数据不同：
- 无法直接监控：这些系统无法直接进行监控，但它们通过 API 暴露其配置。
- 高基数和关系型：数据通常具有高基数，并且高度关系型。它也不像服务器上的磁盘 I/O 指标那样频繁变化，而是更侧重于配置状态。
- 较低频率，更高细节：我们在这里想要做的权衡是较少的采集频率，但具有更高的基数和细节。
为什么配置数据很重要
配置数据监控填补了您可观测性策略中的关键空白：
- 安全态势监控：跟踪 IAM 权限、安全组规则、加密设置以及其他影响您安全态势的配置项。
- 合规性跟踪：监控配置以符合内部政策或外部合规要求（SOC2、HIPAA、PCI-DSS 等）。
- 成本优化：识别导致不必要的成本的配置错误，例如过大实例或未使用的资源。
- 变更管理：检测并跟踪环境中的配置变更，提供谁在何时变更了什么的可见性。
- 漂移检测：识别资源何时偏离其预期或期望的配置。
配置数据监控架构
让我们来看看我们在 CQ（指的是 CLoudQuery，作者所在公司） 处理配置数据时做出的一些关键架构决策：
![]()
数据摄取
首先，数据提取的挑战是不同的问题。我们无法对这些系统进行监控，因此需要创建提取器（或 ETL 脚本），主要挑战是维护这些连接器。任何希望解决这一需求的系统都必须维护高质量的数据源连接器。
收集频率通常为每日一次，但根据配置的重要性，有时可能需要将其配置为更高的频率。
译者注：如果频率这么低，从监控的角度感觉是不够用的。真的发生了故障，黄花菜都凉了。
存储
由于从 API 获取的数据具有高度相关性，我们使用了一个 SQL 数据库，可以在其中创建复杂的连接。NoSQL 数据库或时间序列数据库并不适合这种用例。
在这里，频率和基数之间的权衡可能是按日分区。一些提取器可能会运行得更频繁，但快照操作通常仍然会按日运行；否则，数据量会爆炸。
生成洞察
这与可观测性平台解决“空白页面综合征”（即“我有数据，现在我要监控什么？”）的方式有些类似。我们提供了大量的开箱即用的洞察，但我们也认识到每个组织的需求略有不同，并且在云治理方面没有一刀切的规则。因此，客户可以访问原始查询并对其进行修改，也可以添加新的自定义数据源。
关系和物化视图
将配置数据存储在关系数据库中的一个显著优势是能够建模和查询不同配置项之间的关系。例如：
- 哪个 IAM 角色可以访问哪些 S3 桶？
- 哪些安全组与哪些实例相关联？
- 您的 Kubernetes RBAC 设置与云 IAM 权限有何关系？
Materialized views 可以用于预先计算常见的关系查询，从而提高经常性请求的性能。
与传统可观测性集成
当配置数据作为第四支柱时，其真正的力量在于与传统可观测性数据集成后展现出来：
![]()
- 根本原因分析：当发生故障时，将指标、日志和跟踪与配置更改相关联可以迅速识别根本原因。
- 上下文增强：通过配置上下文增强指标和日志（例如，“此错误峰值发生在对负载均衡器进行配置更改之后”）。
- 主动监控：在这些配置变化影响您的指标之前，检测可能导致未来性能问题或中断的配置变化。
挑战与考虑
实施配置数据监控自身也伴随着一系列挑战：
- API 速率限制：许多服务对他们的 API 设定了速率限制，这可能会限制你收集配置数据的频率。
- 认证和授权：管理众多系统的凭据和权限需要仔细考虑安全问题。
- 数据体积管理：即使采集频率较低，配置数据的高基数也可能导致显著的存储需求。
- Schema 迁移：API 随时间发生变化，需要适应您的数据提取和存储机制。
总结
日志、指标和跟踪仍然是可观测性的关键组成部分，而配置数据代表了第四根支柱，提供了对您系统独特见解。通过实施全面的配置数据监控，组织可以增强其安全态势、确保合规性、优化成本，并更深入地了解其基础设施。
随着系统变得越来越复杂和分布式，配置数据监控的价值将只会增加。那些认识到这一第四支柱并将其纳入其可观测性策略中的组织，将更好地处于理解、排查故障和优化其日益复杂基础设施的有利位置。
译者注：原文作者这个观点值得借鉴，但是对于故障定位等场景真的那么有用吗？也未可知。具体实施时，建议先从 ROI 高的方面着手，从那些你觉得最重要的配置数据开始。Google SRE 统计生产环境 70% 故障是变更导致的，译者建议您先把变更事件收集起来，对于排障还是蛮有用的。我们在 Flashcat 里专门做了一个「事件墙」的产品，就是用来收集变更事件的。如果生产环境发生故障，从故障时间点往前看一个小时，该时间段内的变更事件，很可能就是故障的罪魁祸首。
