可观测性的三大支柱
现代软件系统不再是安静运行在单台服务器上的简单应用。
一个用户操作可能需要经过 API 网关、认证服务、数据库、缓存、支付提供商、邮件服务、消息队列和多个内部微服务，最终响应才会到达浏览器。当一切正常时，用户看到的是流畅的体验。当某个环节出问题时，故障可能深藏在系统内部。
这就是可观测性重要的原因。
可观测性是通过研究系统产生的信号来理解其内部状态的实践。它帮助工程团队回答三个关键问题：正在发生什么？发生了什么？是怎么发生的？
这三个问题直接对应可观测性的三大支柱：指标、日志和追踪。每个支柱提供不同维度的可见性。单独来看，每个都很有用。合在一起，它们能讲述完整的故事。
1、为什么可观测性在现代系统中很重要
监控告诉你出了问题。
可观测性帮助你理解原因。
这个区别很重要。监控面板可能显示 CPU 使用率飙升或错误率上升。但这本身无法解释是什么导致了飙升、哪些服务受到了影响，或者问题是如何在系统中传播的。
没有可观测性，工程师往往只能靠猜测来调试。他们查看面板、扫描日志、重启服务，希望问题能变得明显。在小系统中，这可能行得通。但在分布式系统中，这很快就会变得非常痛苦。
可观测性为团队提供了一条从恐慌走向诊断的路径。它将生产环境从一个黑盒转变为一个能够自我解释的系统。
2、指标：正在发生什么？
指标是随时间收集的数值测量。
它们回答的问题是：系统内部现在正在发生什么？
指标可以追踪 CPU 使用率、内存消耗、请求速率、延迟、错误率、队列深度、缓存命中率或数据库连接数。因为指标是数值化且基于时间的，所以非常适合用于面板展示、告警和趋势分析。
假设你的结账 API 突然变慢了。第一个信号可能来自指标。响应时间在下午 3:45 飙升。CPU 使用率跳升。错误率增加。请求量可能保持正常，这说明问题不是简单的流量增加。系统内部发生了变化。
这就是指标的力量。它们通常是最快发现问题的方式。
指标让你掌握系统的脉搏。它们显示系统是否健康、过载、变慢或故障。像 Prometheus、Grafana 和 Datadog 这样的工具通常用于收集和可视化这类数据。
但指标也有局限性。它们告诉你出了问题，但不一定总是告诉你确切原因。CPU 飙升可能是由糟糕的部署、昂贵的查询、内存泄漏、流量突增或依赖故障引起的。指标发出警报。接下来的支柱帮助解释原因。
3、日志：发生了什么？
日志是离散事件的记录。
它们回答的问题是：到底发生了什么？
日志可能记录用户成功登录、购物车被更新、支付失败、发生超时或触发重试。日志捕捉了应用内部单个事件的故事。
如果指标显示结账 API 变慢了，日志帮助揭示周围的细节。你可能会发现重复的超时消息。你可能会看到数据库连接池耗尽。你可能会注意到支付失败是在一次部署后立即开始的。
日志特别有用，因为它们包含上下文。一条好的日志消息可以包含时间戳、请求 ID、用户 ID、服务名称、错误代码、堆栈追踪和重要的业务事件。
一条弱的日志说："数据库错误。"
一条有用的日志说："checkout-service 的数据库连接池已耗尽，request_id=abc123，pool_size=20，timeout_after=30s。"
这种上下文将日志从噪音转变为证据。
像 ELK Stack、Loki 和 Papertrail 这样的工具通常用于集中式日志管理。在生产系统中，日志应该是可搜索的、结构化的，并且能与指标和追踪相关联。
日志告诉你事实。它们展示故障周围的确切事件。
4、追踪：是怎么发生的？
追踪跟随一个请求在系统中的移动过程。
它们回答的问题是：这个请求是如何传播的，时间花在了哪里？
这在微服务架构中变得至关重要。一个请求在完成前可能经过多个服务。没有追踪，每个团队可能只能看到自己负责的那一小部分请求。API 网关团队看到一种情况。认证团队看到另一种。数据库团队又看到别的。
追踪将这些片段连接成一个完整的旅程。
例如，一个结账请求可能在 API 网关花费 5 毫秒，在认证服务花费 12 毫秒，在数据库花费 145 毫秒，在邮件服务花费 18 毫秒。如果数据库调用是最慢的部分，追踪会立即让这一点变得可见。
这就是为什么追踪对于识别瓶颈如此有价值。
指标可能告诉你结账 API 很慢。日志可能告诉你数据库连接池已耗尽。追踪则准确显示请求路径中哪里发生了 slowdown。
像 Jaeger、Zipkin 和 Datadog APM 这样的工具帮助团队可视化分布式追踪，并理解跨服务的请求瀑布流。
当系统变得分布式时，追踪尤其关键，因为延迟很少是由一行明显的代码引起的。它通常隐藏在服务调用、网络跳转、重试、队列和数据库交互之间。
5、为什么你需要三者一起使用
指标、日志和追踪不是相互竞争的工具。它们是互补的信号。
指标从高层次展示问题。日志解释问题背后的事件。追踪揭示问题的路径和时序。
考虑一个真实的生产场景。
结账 API 变慢了。指标检测到响应时间在下午 3:45 飙升。追踪显示数据库调用花费了 145 毫秒，比平时长得多。日志显示数据库连接池已耗尽。现在修复方案变得清晰了：增加连接池大小、调优数据库使用，或者调查为什么连接没有被正确释放。
没有指标，你可能无法快速发现问题。
没有追踪，你可能不知道 slowdown 发生在哪里。
没有日志，你可能不知道 slowdown 发生的原因。
三者结合，将混乱转变为清晰的调试路径。
6、事故的全貌
可观测性在事故期间最有价值，因为时间很重要。
当用户受到影响时，工程师需要快速行动。目标不是无休止地盯着面板看。目标是在用户失去信任之前足够快地理解问题并修复它。
健康的可观测性工作流通常从指标的告警开始。工程师看到延迟或错误率超过了阈值。然后他们打开追踪来识别最慢的服务或失败的依赖。之后，他们检查受影响服务的日志，以找到确切的错误消息和根本原因。
这个序列很强大，因为它缩小了搜索范围。
团队不再问"系统某处出了什么问题？"，而是可以问"为什么这个特定的数据库调用在这个特定的请求路径中变慢了？"
这种精确性节省了时间。
更快的检测带来更快的解决。更快的解决带来更满意的用户。更满意的用户带来更好的系统可靠性和信任。
7、指标最适合用于检测
指标通常是第一个显示问题的信号。
它们轻量、查询速度快、易于设置告警。一个展示请求速率、错误率、持续时间、CPU 使用率、内存使用率和饱和度的面板可以快速揭示不健康的行为。
这就是为什么指标在生产监控中如此常见。它们让工程师在问题对用户变得明显之前检测到异常模式。
但指标是聚合的。它们将许多事件压缩成数字。这使它们非常适合发现模式，但在理解单个故障方面较弱。
指标是烟雾报警器。
它们告诉你某些东西发生了变化。
8、日志最适合用于获取确切的故障细节
当你需要细节时，日志变得有价值。
它们展示确切的错误、确切的时间戳和故障周围的准确上下文。它们对于调试应用逻辑、认证失败、支付错误、无效输入、超时和业务事件特别有用。
然而，如果日志是非结构化的或太嘈杂，它们可能会变得不堪重负。一个生成数百万条模糊日志的系统不是可观测的。它只是很吵。
好的日志是有意图的。它们解释重要的内容，包含有用的上下文，并避免泄露敏感数据。
日志是证人陈述。
它们告诉你发生了什么。
9、追踪最适合用于分布式系统
当请求跨越服务边界时，追踪大放异彩。
在单体应用中，日志和指标通常就足够了。但在微服务中，追踪变得至关重要，因为没有一个服务拥有整个请求旅程。
追踪为工程师提供跨服务的可见性。它显示哪个服务被调用了、每个调用花费了多长时间、是否发生了重试，以及延迟在哪里累积。
这使追踪成为现代后端团队最重要的工具之一。
追踪是地图。
它们展示问题是如何在系统中传播的。
10、尽早构建可观测性
团队犯的最大错误是在事故发生后才添加可观测性。
到那时，已经太晚了。
可观测性应该从设计之初就融入系统。每个关键服务都应该发出有用的指标、结构化日志和追踪数据。每个请求都应该携带关联 ID 或追踪 ID，以便工程师能够跨工具连接信号。
没有可观测性的生产系统就像没有灯的建筑物。你可以四处走动，但当某些东西出错时，一切都会比应有的更难。
在需要之前就建立可见性。
因为你终将需要它。
11、好的可观测性在于信号，而非噪音
更多的数据并不自动意味着更好的可观测性。
一个包含五十个图表的面板可能看起来很 impressive，但在事故期间仍然毫无用处。充满重复消息的日志可能消耗存储空间，却无法帮助任何人调试。没有有意义的服务名称或 span 的追踪可能难以解读。
好的可观测性在于有用的信号。
最好的系统让重要信息易于查找。面板回答运维问题。日志提供上下文。追踪突出瓶颈。告警是有意义的，而不是嘈杂的。
目标不是收集所有东西。
目标是理解重要的东西。
12、最后的思考
可观测性不仅仅是一个工具类别。它是一种工程思维。
指标告诉你正在发生什么。日志告诉你发生了什么。追踪告诉你是怎么发生的。
三者结合，提供完整的系统可见性。
在现代软件中，故障是不可避免的。服务会变慢。依赖会失败。数据库会饱和。网络会异常。部署会引入 bug。
可观测性无法阻止每一次故障。
但它帮助你更快地发现问题、更清楚地理解它们，并自信地修复它们。
核心教训很简单：
你看不到的东西，就无法修复。
所以尽早构建可观测性，同时使用三大支柱，让你的系统在用户发现问题之前就能自我解释。
原文链接: The 3 Pillars of Observability: Metrics, Logs, and Traces
汇智网翻译整理，转载请标明出处