架构师的十八般武艺：可观测性

应用系统在线下，我们可以 debug、可以打点，来观测系统是否运行正常。但是一旦发布都线上之后，这些手段就已经不可用。如果系统有问题或者部分业务场景有异常，我们必须能有相应的手段来发现问题、定位问题，从而最终解决问题。这个就是可观测性需要解决的诉求。

可观测性，我将其分成了被动观测和主动探测两个方面。

首先，对于被动观测，又可以根据观测手段不同，分为度量、日志和跟踪三类。

度量，这个是一个总体的概念。比如网络的丢包率、应用服务的 qps、应用的平均相应时间，等等。这部分指标，标识的是一个系统总体的健康度。maybe 个别请求已经失败了，但是如果度量指标总体看如果是正常的话，大概率系统还是健康的。

日志，这个是我们日常做的最多的，它体现的是一个特定事件的概念。比如服务的报错、服务执行过程中的一些关键请求/响应、网络上被丢弃的包，等等。这部分观测的是特定的异常和 pattern，我们可以利用 ELK 等工具，将系统输出的日志，转化成可分析可挖掘的内容。

跟踪，这个是请求维度的，针对的是单笔请求的执行情况的分析。使用做多的手段就是采用 zipkin 等 tracer 工具，纪录单笔请求经过的应用系统，同时将相应的日志串联起来，形成单笔请求的处理概览。如果有问题可以针对性的分析。

对于主动探测，需要我们的应用系统做相应的架构设计。

比如在网络上，如果我们针对某个服务器的状态进行探测可以采用 ping；如果要看某个网络服务是否 ok 可以用 curl。

对于我们设计的应用系统，我们也有必要做相应的埋点：

• 对于每个服务，可以有一些特殊的 mock 请求，针对 mock 请求，可以进行 dummy 的响应，从而在线探测服务的可用性而不会造成业务影响。这部分也可以和线上压测的影子链路结合在一起。

• 对于配置缓存，需要提供受到权限管控的 get 方法，从而在线判定某些缓存是否正常加载；同时可以提供受到严格权限管控的 put 服务，补充漏加载的配置。

• 对于一些后台服务如定时任务等，需要有受到权限管控的可访问服务，query 运营的情况或者做一次主动的触发。这个在 java 生态中可以用 JMX 协议来设计。

• 其他一些系统必要的埋点。这个需要根据不同的诉求 case by case 来看。