可观测性
现代软件系统极其复杂。微服务、云基础设施和分布式系统让我们越来越难以理解应用程序内部到底发生了什么。一旦出现问题，团队需要能够快速定位问题发生的位置和原因。
这正是可观测性发挥作用的地方。可观测性已经从简单的系统监控演进为一套全面理解系统行为的体系化方法。然而，要落地有效的可观测性并不容易——这既需要理解技术概念，也需要应对组织层面的挑战。
什么是可观测性？
可观测性是指通过检查系统的输出，来理解其内部状态的能力。 在软件系统中，这意味着通过应用程序和基础设施生成的数据，来理解其内部正在发生的事情。
这一领域已经发生了重大演进，可以通过两代不同的可观测性方法来理解。
第一代方法通常被称为可观测性 1.0，是围绕传统的指标（metrics）、日志（logs）和追踪（traces）这“三大支柱”构建的。 这种方法需要为不同类型的遥测数据使用多个工具和数据存储。 它往往迫使工程师预先定义他们想要度量的内容，从而在维护多个系统时变得既昂贵又复杂。
现代可观测性，或称可观测性 2.0，则采用了完全不同的方法。 它基于为系统中每个工作单元（例如一次 HTTP 请求与响应）收集宽、结构化的事件数据。 这种方法会捕获高基数数据，例如用户 ID、请求 ID、Git 提交哈希、实例 ID、Kubernetes pod 名称、特定路由参数以及供应商交易 ID。 一个经验法则是：如果某个元数据有助于我们理解系统行为，就应当将其加入。
这种丰富的数据采集使得在无需预先定义指标的情况下，也可以对数据进行动态切分和多维分析。 团队可以从这些基础数据中派生出指标、追踪以及其他可视化视图，从而回答在最初添加观测点时尚未预料到的、关于系统行为的复杂问题。
然而，实现现代可观测性能力本身也带来了挑战。 组织需要可靠的方法，在多样化的系统和技术栈中收集、处理并导出这些丰富的遥测数据。 虽然现代方法已经超越了传统边界，但理解可观测性的基本组成部分仍然至关重要。
可观测性的三大支柱
为了更好地理解可观测性的演进以及其在实践中的工作方式，我们来 看看可观测性的三大支柱——logs、metrics 和 traces。
虽然现代可观测性已经不再将它们视为彼此独立的关注点， 但它们仍然是理解系统不同行为方面的基础概念。
- Logs - 系统中发生的离散事件的文本记录。 这些记录为特定事件、错误和状态变化提供了详细上下文。
- Metrics - 随时间收集的数值型度量。 这些包括计数器、仪表和直方图，用于跟踪系统性能、资源使用情况和业务 KPI。
- Traces - 跟踪请求在分布式系统中流转路径的记录。 这些有助于理解各个服务之间的关系，并识别性能瓶颈。
这三大支柱使团队能够监控、排障并优化其系统。 然而，真正的价值在于理解如何在这三大支柱上高效地采集、 分析并关联数据，从而获得对系统行为的有意义洞察。
可观测性的优势
虽然可观测性的技术层面——日志、指标和追踪——已经被充分理解，但同样重要的是要考虑其带来的业务收益。
在他们的著作 "Observability Engineering" （O'Reilly，2022）中，Charity Majors、Liz Fong-Jones 和 George Miranda 基于行业研究和实践反馈，总结出组织在实施完善的可观测性实践后可以预期获得的四项关键业务收益。 我们来逐一分析这些收益：
更高的增量收入
作者指出，那些帮助团队提升正常运行时间和性能的可观测性工具，可以通过提升代码质量带来更高的增量收入。 这体现在以下几个方面：
- 改善客户体验：快速解决问题并防止服务降级，可提升客户满意度和留存率
- 提高系统可靠性：更高的可用性意味着更多成功的交易和更少丢失的商业机会
- 增强性能：能够识别和优化性能瓶颈，有助于保持服务的高响应速度，从而持续吸引客户使用
- 竞争优势：能够通过全面监控和快速问题解决来维持高服务质量的组织，往往能在竞争中占据优势
通过更快速的故障响应节约成本
可观测性最直接的收益之一，是通过更快速地发现和解决问题来降低人力成本。主要体现在：
- 降低平均发现时间 (MTTD) 和平均解决时间 (MTTR)
- 改善查询响应时间，从而加快排查过程
- 更快识别性能瓶颈
- 减少值班投入时间
- 减少因不必要回滚而浪费的资源
这一点在实践中已有验证 —— [trip.com 使用 ClickHouse 构建了其可观测性系统](trip.com built their observability system with ClickHouse)， 实现了比原有方案快 4–30 倍的查询速度，90% 的查询可在 300 ms 内完成，从而支持快速的问题排查。
通过避免故障实现的成本节省
可观测性不仅能帮助更快地解决问题——还可以帮助从源头上避免问题的发生。 作者强调，团队可以通过以下方式防止严重故障：
- 在潜在问题演变为严重故障之前及时识别
- 分析规律以避免问题反复出现
- 理解系统在不同条件下的行为
- 主动处理性能瓶颈
- 基于数据对系统改进做出决策
ClickHouse 自用的可观测性平台 LogHouse 就是一个例子。它使我们的核心工程师能够在所有集群中检索历史模式，从而帮助预防 重复出现的问题。
通过降低员工流失率实现的成本节省
最常被忽视的收益之一，是对团队满意度和留任率的影响。 作者强调了可观测性如何带来如下效果：
- 通过更完善的工具提升工作满意度
- 由于未解决问题更少，从而降低开发者倦怠
- 通过更好的信噪比减少告警疲劳
- 借助更优的事件管理降低值班压力
- 提高团队对系统可靠性的信心
我们在实践中也看到了这一点——当 Fastly 迁移到 ClickHouse 时， 他们的工程师对查询性能的提升感到震惊，并指出：
“我简直不敢相信。我甚至又回去检查了好几次， 只是为了确认自己是不是正确地在查询它……这返回得也太快了。 这说不通。”
正如作者所强调的，尽管这些收益的具体衡量标准可能会因工具与实现方式不同而有所差异， 但只要采用健壮的可观测性实践，各类组织都可以预期获得这些根本性的改进。关键在于 有效选择并实施合适的工具，以最大化这些收益。
要实现这些收益，需要克服若干重大障碍。即便是那些理解可观测性价值的组织，往往也会发现， 在真正落地实施时会出现出乎意料的复杂性和挑战，必须谨慎应对。
实施可观测性时面临的挑战
在组织内部实施可观测性，是迈向更深入洞察系统性能和可靠性的一次重要变革。 然而，这个过程并非一帆风顺。 当各组织努力挖掘可观测性的全部潜力时，会遇到各种可能阻碍推进的障碍。 下面我们来逐一看看其中的一些挑战。
数据量和可扩展性
实施可观测性时的主要障碍之一，是管理现代系统生成的海量遥测数据及其可扩展性。随着组织的发展，需要监控的数据量也随之增加，因此必须采用能够高效处理大规模数据摄取和实时分析的解决方案。
与现有系统集成
与现有系统的集成是另一项重要挑战。许多组织运行在采用多种技术的异构环境中，因此可观测性工具必须能够与当前基础设施无缝集成。开放标准在促进这种集成方面至关重要，它们确保互操作性，并降低在不同技术栈上部署可观测性解决方案的复杂性。
技能差距
技能差距也可能阻碍可观测性的成功实施。向高级可观测性解决方案过渡通常需要具备数据分析和特定工具方面的专业知识。团队可能需要在培训或招聘上投入资源，以弥补这些差距，并充分发挥其可观测性平台的能力。
成本管理
成本管理至关重要，因为可观测性解决方案的成本可能会迅速攀升， 尤其是在大规模场景下。组织必须在这些工具的成本与其带来的价值之间取得平衡， 寻求相较于传统方案更具成本效益、能够实现显著节省的解决方案。
数据保留与存储
数据保留和存储管理带来了额外的挑战。在不影响性能和洞察力的前提下，决定将可观测性数据保留多长时间，需要进行周密规划，并采用高效的存储方案，在降低存储占用的同时保持数据可访问性。
标准化与厂商锁定
在可观测性解决方案中，确保标准化并避免被厂商锁定对于保持灵活性和适应性至关重要。通过遵循开放标准，组织可以避免受制于特定厂商，并确保其可观测性技术栈能够随自身需求演进。
安全与合规
在处理可观测性系统中的敏感数据时，安全与合规因素始终至关重要。组织必须确保其 可观测性解决方案遵守相关法规，并能够有效保护 敏感信息。
这些挑战凸显了在实施可观测性解决方案时开展战略规划和 基于充分信息的决策的重要性，从而有效满足组织需求。
为应对这些挑战，组织需要一个系统化的方法来 实施可观测性。标准的可观测性管道已经演进，形成了一套用于 有效收集、处理和分析 遥测数据的框架。这一演进中最早且最具影响力的示例之一 源自 Twitter 在 2013 年的实践经验。
