查看原文

有人开玩笑，开发不喜欢 Monitoring ，就造了个新名词 Observability 让开发们觉得这事就是潮流得跟上！曾经其实所有 Ops 监控的东西，都叫 Monitoring，从视觉上看那就是 Nagios 面版，没啥技术含量。但后来人们发现，这个面版上只是 up/down 完全不够用了，那些简单的 pings 根本看不出问题出在哪里。测个节点挂没挂，服务进程死没死其实已经不足以保证服务的正常运行了。我们真正要登录到服务器去看报错日志和实时的打点数据才有可能找到根因，这就引入了 APM。

Google SRE 一书中将 Monitoring System 认定为要解决两个问题：什么坏了，为什么坏了：既要发现病症，也要发现病灶。当然，前提是，你需要先发制人知道系统在某个域里面可能会发生什么问题，然后做到相关监控，进而做到 Whitebox Monitoring。例如说，对于存储系统最关注 disk-space，对于代理最关注 fd-count，对于分布式kv服务最关注 error-rate, query-latency, repl latency。对于某个服务，我们在上线之初就要为其定出内部的 SLA，为其定制如何衡量 Availability 的规则。不仅如此，系统里面最好还要做到能监控的地方就监控，将 unknown-unknowns 的东西变得尽可能少。在有很多监控指标后，又要好好分析，减少噪音，这是另外一个挑战。我们要知道，系统失效是必然的，监控不会减少它的发生，它只是提供了系统健康的近似模拟，让我们可以尽快处理。这里有几个简单的规则设定这样的规则：

• 指标能够捕获真正的事故，它应当是尽可能简单，可预测，可靠的。
• 定期清理：如果数据收集，聚合，报警配置很多人碰都不碰一下的，那就清掉。
• 同上，没被纳入面版的，或没设置报警的信号也都清掉。
• 核心规则：监控指标必须是 actionable 的，它必须能在系统出问题的时候，立即指出哪里出问题了。

Observability 要处理的问题可以是 detailed system profiling, single-process debugging, tracking details about exceptions or crashes, load testing, log collection and analysis, or traffic inspection 中之一，它不一定要是跟 outage 有关系。如果将这些东西混入 Monitoring，那就违反了它简单，迅速定位的初衷。Observability 想要在高层次提供复杂系统行为，并给出能用于 debug 的上下文，从这个角度看，Sentry，Log 这些都能提供一定的 Observability。这个特性要求我们的系统本身是可以被 Debug 的。Observability 关注的东西：

• Monitoring
• Alerting/visualization
• Distributed systems tracing infrastructure
• Log aggregation/analytics

对于系统失败，我们可以简单理解为 Monitoring 是针对已知的系统失效，而 Observability 则是一种对已有系统的性能和行为的观测（甚至不一定要是跟 outage 有关）。从定义的广度，Observability 是 Monitoring 的超集。