SRE体系19----可观测性

系统的可观测性是指在复杂的分布式系统中，能够及时、准确的感知到服务状态，特别是异常或故障的发生，能够确定影响范围、故障点位，协助运维人员决策的能力。

观测能力是业务产品内在特性和支撑能力的结合。过去一般认为观测能力是运维工程师的事，开发只负责写代码逻辑。而在SRE眼中，观测能力应该是业务产品的内在能力之一，目的是为产品故障发现、诊断和修复提供帮助。例如软件产品在设计和开发时应该提供错误监控，性能监控，状态监控的api，可以通过打印日志，上报自身监控信息等操作将软件产品的内在观测能力暴露出来。支撑能力一般指软件产品外部的观测能力(黑盒方式)，能够通过软件产品的外部行为观测内部可能发生的故障，例如运维监控系统里对应用进程的端口探测，健康检查，进程存活检测等能力。

业务系统的可观测性建设有三大支柱：监控、日志、链路追踪

1.监控
监控是对业务系统最基础的感知系统，前章节已做说明，不再赘述

2.日志
常见的业务相关的日志包括sys_log，access_log，error_log等。是我们定位错误根因的一手资料。由于目前业务都是分布式架构部署，日志散落在各个节点上，所以我们必须把日志集中起来分析，常见日志结构如下图

在日志系统的建设中，我们需要规范日志的输出格式，避免清洗转换的麻烦。 例如我们要规定日志的每个字段含义，类型，打印格式，编码方式以及关联性标识。日志规范要有包容性，确保绝大多数的业务产品能够遵循

3.链路追踪
监控系统告诉我们发生了什么现象，但产生这种现象的上层原因却有很多，只能大致的确定故障范围与可能性， 而日志系统是在确定了准确的故障点后排查具体错误，定位根因使用的。这中间似乎缺少了一个环节：怎么定位到是哪个服务出了问题？

一个大型的虚拟化集群中，可能跑了上百个服务，服务之间的调用关系异常复杂，只要调用链上的任何一个服务失败，而且有可能你调用的还是别人的服务(你完全不了解，也没有权限查看日志)，那么最终的结果就是失败。如果人肉去排查调用链上的每一个服务着实太费劲，而且消耗时间，影响MTTR，所以需要一种技术来帮助我们监控调用链。

链路追踪系统的设计思路是从请求发起端到最终的数据存储端(如数据库)的整个请求调用链中，用一个trace_id标识串联起来(例如在请求头中加入tracce_id), 经过的每个节点叫span，每个途径节点调用的耗时、状态码均附着在节点信息里。这样就可以唯一标识出一条请求调用链，从而进行追踪监控。这个过程有些像高速公路收费站，把你的ETC当成唯一标识，通过时间排序你经过的收费站，从而绘出你的行车轨迹，并在每个站点显示每段路跑了多长时间，收费站花了多少钱等信息。

链路追踪的好处是即使我们不了解业务系统的具体应用架构(让SRE/运维了解集群内所有服务的架构也不现实)，也可以大致判断出出现异常的服务节点，再结合监控指标和服务日志，就可以做到准确的故障定界定位，这就是可观测性的直观体现