可观测性是一种通过系统外部输出理解内部状态的能力。对 IT 和研发团队来说，它不是单纯多采集一些数据，而是让团队能用指标、日志、链路追踪、事件等信号回答更具体的问题：系统现在是否健康，异常从哪里开始，影响了哪些用户，下一步该看哪类证据。
随着 IT 架构从单体系统走向云、容器、微服务和多环境部署，单靠人工巡检和预设仪表盘已经很难覆盖所有故障场景。可观测性的价值，就是把系统运行过程中产生的数据组织成可分析、可追踪、可行动的线索，帮助团队在问题扩大前发现和处理风险。
本文围绕五个问题展开：
- 可观测性是什么：它是一种从外部信号推断系统内部状态的能力。
- 可观测性为什么重要：现代系统复杂度上升，需要更快发现、定位和解释异常。
- 可观测性带来什么收益：更好地控制数据、关联请求路径、观察趋势并支撑排障。
- 可观测性如何落地：先明确目标、利益相关方、数据来源和数据去向。
- 可观测性工具怎么选：优先关注灵活性、易用性、数据管道能力和总体成本。
什么是可观测性？
可观测性既是一个工程目标，也是一套实践方法。它关注的是：系统是否能持续生成足够有用的输出，让团队在不直接进入系统内部的情况下，推断出系统真实状态。
换句话说，可观测性不是“把所有数据都存下来”，而是让组织从可收集的数据中得到最大洞察。它可以帮助团队诊断性能问题、理解系统行为，并在问题扩大之前采取行动。
应用程序和系统通常包含部署在跨多个云和本地环境的容器中的数十个微服务。数据采集变得越来越困难，让我们更难以了解系统和应用程序在现实世界中的执行方式。
不存在一刀切的可观测性解决方案，因为您的公司所需的与其他公司的需求非常不同。每个组织都有自己的方法和要求。
因此，好的可观测性体系应该允许 IT、安全、DevOps 和 SRE 团队围绕系统行为提出问题，而不是只能在预设仪表盘里寻找答案。
可观测性示例
当您去办公室时，您将使用您的徽章进入。当您扫描徽章时，系统会生成数据，例如您的姓名、您进入的时间、您使用的入口。每个进入建筑物的人都会生成日志数据。要收集、减少和清理所有数据，然后将有价值的信息发送到您的分析工具，您需要一个工具，例如Cribl Stream（本文作者的公司产品）。这是可观察系统的一个例子。
监控和可观察性有什么区别？
可观测性和监控之间的区别，首先体现在问题类型上。
监控通常依赖预先配置的指标、仪表板和告警规则，用来回答已知问题。例如 CPU 是否超过阈值、磁盘是否快满、某个接口错误率是否升高。监控工具擅长处理团队已经知道要观察什么、什么状态算异常的场景。
可观测性更关注探索性问题。它希望团队在事故现场能够继续追问：异常是否只发生在某个区域，是否和最近发布有关，是否由某个下游依赖引起，是否影响了核心用户路径。它不是替代监控，而是在监控之上补足关联、下钻和解释能力。
译者注：很多资料都宣传说可观测性可以回答未知的未知，这显然有个前提是可观测性平台得收集到足够多的数据，并结构化，数据太多又会有成本问题，所以就需要专家见解来看哪些数据真正重要，哪些数据不那么重要可以丢弃，但是一旦植入专家经验，那么就不再是未知的未知了。感觉无解啊。
为什么可观察性很重要？
可观测性通过指标、日志和链路追踪等数据跟踪分布式 IT 系统的性能。它为团队提供洞察力，也提供继续追查根因的路径。
此外，可观察性使数据工程团队能够识别环境中的意外信号（也称为“未知的未知因素”），从而防止未来出现问题并提高系统性能。
总之，可观测性重要，是因为它让团队能够：
- 在早期识别和缓解应用性能问题。
- 通过多维数据关联，发现传统监控规则没有覆盖的异常。
- 为自动化修复、机器学习分析和趋势预测提供更可靠的数据基础。
- 从最终用户体验出发判断技术异常的真实影响。
可观察性的好处
可观测性的收益可以归纳为三类：
- 数据更可用：把分散的指标、日志、链路、事件组织起来，让数据能被查询、关联和复用。
- 排障更高效：通过请求路径、资源对象和时间窗口关联，减少团队在多个工具之间手工切换。
- 成本更可控：通过数据管道、采样、过滤和路由，减少无价值数据的存储和传输。
可观测性挑战
可观测性也有边界。常见挑战包括：
- 采集太多低价值数据，导致存储和分析成本升高。
- 数据结构不统一，导致指标、日志和链路难以关联。
- 团队只建设工具，没有明确故障发现、定位和恢复的目标。
- 过度宣传“未知的未知”，却没有说明数据质量、专家经验和成本控制的前提。
可观察性的支柱及其如何运作？
可观测性的三个常见支柱是指标、日志和链路追踪。实际落地时，事件、Profiling、应用主动暴露的信息也很重要，但指标、日志和链路追踪是最常被讨论的基础数据类型。
Metrics 指标
指标是在时间间隔内测量的数据的数字表示。它适合做趋势观察、聚合计算、阈值告警和容量分析。团队可以用指标观察系统性能，也可以跟踪关键业务或客户体验指标。
在数字世界中，指标用于分析和报告系统的性能。
Logs 日志
日志是系统生成的数据记录，通常描述某个时间点发生了什么。日志能保存错误信息、请求上下文、处理分支和业务字段，是排查细节问题的重要证据。
例如，初创企业会在工作日和周末记录员工轮班或网站流量等信息。
日志是指操作系统和应用程序写入的信息。服务器通常定期制作其操作的快照并将其写入日志中。每个日志条目通常包含时间戳、记录数据的系统名称以及事件的严重性。
Traces 链路追踪
链路追踪记录一次请求在系统内的端到端旅程。它展示请求经过了哪些服务、每个阶段耗时多久、哪个下游调用失败或变慢。对请求执行的每个操作通常称为 span，span 会携带对应服务和调用信息。
当出现问题时，可以追踪跨度的历程并找到瓶颈。它可以进一步向应用程序开发人员显示其执行情况或警告可能出现的问题。
如何实现可观察性？
实施可观测性，应该先从目标和现状开始，而不是先买工具。团队需要回答几个问题：
- 您在云端有 IaaS 吗？
- 您在使用 SaaS 吗？
- 您已经拥有可观测系统了吗？
如果您的系统签订了免费增值合同且功能受到限制，您可能需要升级许可证。如果您使用开源软件，您应该知道，尽管它是免费的，但当您真正开始使用它时，可能会产生意想不到的成本。典型的就是人员成本。
了解当前能力之后，再根据未被满足的需求设计下一步。
与对可观察性感兴趣的每个部门取得联系，并准确弄清楚每个部门的需求。 IOps、AIOps、DevOps 和您的 SRE 都应该能够告诉您他们需要什么或者他们离不开哪些工具。
了解每个人的需求后，还要盘点数据来源。日志传送程序、应用程序、网络设备、客户端埋点和基础设施都会在不同程度上收集和转发数据。团队需要找出利益相关者缺少什么：他们需要哪些事件、指标或上下文，这些数据来自哪些设备或服务。
然后是数据管道硬币的另一面：目的地。您收集的数据实际上去了哪里？这些是您的日志服务器、分析系统和存储（可以位于本地或云中）、数据库、搜索引擎、APM、系统 API 收集器或开发的任何自定义系统。确定这里可能缺少什么，然后确定您引入的所有数据是否都得到了正确处理。
最后，要把可观测性嵌入日常工程管理中：新服务上线要考虑埋点和标签，告警复盘要反向改进数据质量，成本评审要检查哪些数据值得保留。
如何使系统可观测？
让系统更可观测，一个有效方法是构建灵活的可观测性数据管道。
可观测性管道位于数据源和分析工具之间。它允许用户从不同来源接收不同格式的数据，完成过滤、转换、清洗、路由和采样，再把有价值的数据送到合适的目的地。这样既能改善分析效率，也能降低应用程序和基础设施成本。
如何将数据传送到分析工具？
数据通常通过管道从收集器实时传输到分析工具。该管道还可以识别数据并将其转换为所需的格式。收集数据后，您必须对其进行分析。
鉴于有多种工具可以分析相同数据的重叠部分，组织很快就会发现这个过程非常麻烦。高度灵活的可观测性管道有助于最大限度地减少这种情况。
市场上有很多可观测工具和平台，具体选择取决于需求和偏好。原文提到的选项包括 Cribl、Datadog、Elastic。
如何优化可观测性？
可观测性是工具、服务、工程设计和分析系统的组合，必须协同工作。
优化可观测性，要先理解 IT 系统如何影响组织目标。然后把“系统、应用程序或网络应该如何运行”转化为可衡量的问题，例如成功率、延迟、错误率、资源消耗、依赖健康状态和用户体验指标。只有问题可衡量，系统状态才有机会被持续改进。
可观察性的未来是什么？
可观测性的未来，始于更普遍的应用程序埋点。应用程序需要主动暴露安全、性能和业务相关信息，让平台能够把请求、资源、事件和用户体验关联起来。
小结
可观测性不是单个可以买来的产品，而是组织持续建设的工程能力。它的核心不是“数据越多越好”，而是团队能否围绕系统健康提出问题，并用已有数据得到可信答案。
FAQ
Q1：可观测性等于监控吗？ A：不等于。监控更擅长回答预设问题，可观测性强调在复杂系统中继续探索、关联和解释异常。监控可以视为可观测性体系的一部分。
Q2：指标、日志和链路追踪三类数据都必须建设吗？ A：它们是最常见的基础数据类型，但是否一次性全部建设，取决于业务复杂度和排障目标。更务实的方式是先围绕关键系统补齐最需要的数据和上下文。
Q3：可观测性会降低成本吗？ A：只有在数据质量、采样、过滤、路由和保留策略设计合理时，才可能降低无效存储和分析成本。如果只是无限制采集数据，成本反而会上升。
原文：https://cribl.io/blog/what-is-observability/
