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