共计 5709 个字符，预计需要花费 15 分钟才能阅读完成。
文 | 周江华
网易智慧企业资深业务架构师
引言
对于分布式系统，因为其远超传统软件的零碎复杂性，零碎运维的难度大大增加，且会随着分布式节点的减少而指数级增长。
当零碎呈现故障时，要在数以千百计的利用节点中找出问题所在，对于开发人员来说，是一个微小的挑战。尤其是很多节点的指标都异样时，何为因，何为果，往往难以分别。
而另一方面，对于 SaaS 利用来说，其面向企业的属性，决定了对于服务可靠性的极高要求。一是呈现故障时，咱们须要疾速定位问题并排除故障，复原服务。更重要的，则是可能时刻分明理解零碎的运行状态，在零碎有变坏趋势产生前，及时发现，毁灭故障于有形。
要做到这些，最根底，又最重要的，便是零碎具备极高的可观测性。
什么是可观测性
当咱们开着一辆汽车行驶在路上时，仪表盘上的码表、转速表、油量计等仪表批示了汽车以后的根底运行状态。
当有黄色指示灯亮起时，示意车辆对应的某个整机有隐患，须要查看，但还不至于影响车辆的根本运行和平安性能。而当有红色指示灯亮起时，则是重大正告，最好立刻把车送去查看培修，否则车辆核心部件可能受损，或者存在重大安全隐患，容易引发事变。
汽车仪表盘及其连贯的传感器和信号传输零碎，便是对于汽车零碎可观测性的最根底，最直观的例子。如果须要更深刻理解汽车各个部件的状态，还能够连贯车辆的 OBD 接口，从中获取到更多的车辆以后状态以及历史状态数据。通过 OBD 接口，汽车零碎的可观测性也被大大加强。基于 OBD 数据，又衍生出了很多的手机管理软件，能够更简略的察看车辆状态，还能记录过往更多历史数据，做驾驶习惯趋势剖析等，更大的扩大了汽车的可观测性。
在 IT 畛域，可观测性的重要性有过之而无不及。CNCF（云原生计算基金会）对于 Cloud Native 的定义中，就蕴含 observable 这一重要特色。从汽车的例子，能够简略演绎出可观测性的定义，即 可能将零碎的外在状态，通过采集，剖析，解决后，通过正当的聚合，演绎，展现指标数据，让人能够在最短时间内理解到零碎产生的所有。
具备可观测性的零碎，运维以及研发人员能够直观的察看到零碎的整体运行状态是否衰弱，同时又能轻易的深刻到运行的各个细节角落。在失常运行时，观测零碎能对系统负载进行评估，对运维操作提供倡议。在产生故障时，可帮助疾速定位和修复问题。在运维自动化和智能化的大趋势中，零碎的可观测性是其中最根底的一环。
构建欠缺的观测零碎
零碎可观测性的能力次要是由一个欠缺的监控零碎提供。市面上有很多开源的分布式监控零碎，比方 Prometheus，Zabbix，nagios，CAT 等。其中，Prometheus 更已成为事实上的接口标准。而各个大公司出于灵便，定制以及弱小的运维开发能力，会有本人的监控零碎。无论哪种监控零碎，其形成组件是根本一样的，上面是 Prometheus 的架构图：
（图片引自 Prometheus 官网）
从图中能够看到，一个零碎具备可观测性，必须具备以下这些组件：
1. 服务状态感知组件
在零碎的各个节点，以全面的维度，采集服务状态信息，提供原始数据。因为采集的数据量微小，该组件又间接部署在零碎的运行节点上，须要应用各种形式来防止对系统失常运行造成影响。感知组件通过多种形式来采集状态数据，而后依照 标准接口输入结构化的数据。罕用的采集形式包含：
- 独立监测工具，例如，监测零碎运行状态的 sar，top，dstat 等。
- 字节码注入
- 结构化日志
- 行为事件埋点
2. 状态数据收集和存储
该组件是整个观测体系的外围，将采集的数据上报，而后高效的存储下来。对于不同的数据，不同的剖析形式，应采纳适合的存储数据格式和存储介质。最罕用于存储监控数据的是时序数据库，例如 Prometheus，InfluxDB 等。对于数据采集方，提供各种度量类型，用于结构化的汇报数据，包含
- Gauges：计量器，用于内存，线程数等简略计数场景。
- Counters：计数器，用于申请数，谬误数等统计场景。
- Histograms：直方图，用于均匀响应工夫，RT 95 值等须要计算均值，方差，分位数的场景。
- Meters：TPS 计数器，用于速率统计，以及 1 分钟，5 分钟均值一类的统计。
- Timers：计时器，用于统计申请时延，例如申请时延，磁盘读取时延等。
3. 可视化展现
观测零碎是否产生价值，可视化界面是最次要的一个决定因素，可视化零碎必须反对灵便配置，灵便组合，又易于应用，信息展现足够直观。开源的可视化监控工具应用最宽泛的是 Grafana。
4. 报警
报警性能是整个监控零碎最外围的价值之一，在零碎曾经产生异样或者可能会产生异样时，报警零碎能通过邮件，IM，短信，电话等多种渠道，及时告诉到相干方，让相干的运维和研发染指解决。
（IM 通道报警示例）
报警配置次要有两类，状态事件报警和趋势报警。
状态事件是指曾经产生的异样事件，例如：
- CPU 使用率超过 95%
- 磁盘空间占用率超过 90%
- JVM 间断产生 fullgc
- 接口调用一段时间失败超过 N 次，比率超过 x%
- Tomcat 线程数超过 120
- 业务打印出 ERROR 级别日志
趋势报警是指对指标变化趋势进行剖析，而后对异样变动进行报警解决，例如：
- 音讯量比一周前降落 30%
- 某 URL 接口申请量比一分钟前减少了 30%
- 内存使用量间断十分钟增长超过 5%
笼罩全面的观测维度
资源监控
资源次要是指零碎计算资源和网络带宽资源，常见的有 CPU，内存，磁盘 ID，网卡流量等。这类指标通常是以数值，百分比等形式进行统计，用于直观的掂量零碎负载状况。作为最根底的监控我的项目，各种类型的开源监控零碎和云计算平台都有提供。
（资源状况监控示例）
对于各个类型的资源，上面是一些常常要关注的点，要在咱们的监控零碎中清晰出现进去。
- CPU：对于计算型利用，CPU 是外围资源，负载高下间接批示了以后的零碎的负载状况。对于非计算型利用，CPU 通常处于低负载状态，如果某个工夫点 CPU 负载忽然飙高，通常批示利用有 bug 了，比方有死循环，或者是虚拟机在频繁的 fullgc 导致负载下不来，或者是网络流量飙高导致 CPU IO 解决以及上下文切换累赘减轻。
- 过程存活状况：查看是否存在指定过程名的过程。
- 内存：内存使用率，残余内存量。
- 硬盘：包含硬盘空间，inode 数量，磁盘 IO 状况等。
- 网卡：进出网络流量，进出网络 PPS，丢包率等
性能监控
资源监控聚焦于操作系统层面，性能监控则聚焦于利用层面，也就是咱们常说的利用性能治理（APM）。
对于利用过程层面的监控，通常通过在虚拟机层，或者字节码执行层通过隐式注入的形式，来获取监控指标数据，常见的像 JVM，PHP 的 Zend Engine 等。以 Java 利用为例，通过这种形式，咱们能够获取到的监控指标有：
- JVM 内存状态
- JVM GC 状况
- Java 办法调用统计
- Tomcat 线程状态
- 自定义线程池工作状态
而在接口层面，对于传统的应用程序，仍旧能够通过字节码注入的形式来获取。对于云原生的利用，则能够通过 sidecar 的形式来监控。通过监控，咱们能够获取到接口的 QPS，并发调用量，响应工夫散布，谬误次数等各个指标。
（http 接口调用状况监控示例）
能通过这种形式来监控的接口类型有：
- HTTP 接口调用 / 被调用状况统计
- RPC 接口调用 / 被调用状况统计
- SQL 执行状况统计
- Redis 拜访状况统计
单节点的接口性能只能体现一个节点的状况，意义还不是那么大。但当把整个平台所有服务的接口调用状况串起来之后，就能够对系统全貌运行状况有直观的展现，这就是当下比拟炽热的调用链路追踪零碎。以后支流的调用链路追踪零碎的实践根底基本上都是 Google 的 Dapper，风行的开源组件有：Zipkin，Pinpoint，SkyWalking 等。通过调用链路追踪，咱们能够轻易做到：
- 各个服务节点性能剖析
- 故障疾速定位
- 申请调用链路剖析
- 服务依赖剖析与治理
（七鱼全链路监控大盘）
业务监控
不管何时，业务体现才是最间接的关切点，最间接的监控也就是业务监控。常见的业务监控就是各种业务大盘，比方淘宝双 11 的交易数据大屏，这类大屏数据通常用于对外展现，或者给领导看，外观都会设计的很酷炫，展现的数据类型上也会通过一些筛选。
而对于研发团队，业务监控最重要的是批示业务的衰弱水平，因而展现的数据类型会所有不同，个别会更加粗疏，维度也会更加全面。
首先，对业务整体状态有监控。整体监控次要关注外围业务的衰弱度，保障外围业务有任何异样时，能够即时揭示。
（七鱼局部业务监控面板）
比方，对于七鱼来说，其外围业务流程是访客与客服的沟通，以及客服工作效率晋升，因而整体业务监控指标会包含：
- 并发会话量
- 并发话务量
- AI 解答量
- AI 解决率
- 在线坐席数
- 音讯收发速率
- 工单创立速率
然而，整体业务趋势没有显著异样，但在某一个细分的维度下，可能业务曾经齐全不可用了。因而在整体业务之下，监控还要持续下钻，从各个不同的维度进行监控。常见的细分维度有：
- 地区：地区次要关注的是网络状况，尤其是对于视频这种网络敏感的业务。网络地区差别最大的是 CDN 笼罩品质，其次是各地区运营商对于网络拜访的限度措施，再就是常常见诸报道的某个中央的光纤被挖断的事件。
- 用户：对于不同类型的用户，可能会提供不同的性能，常见辨别用户的形式有 VIP，标签等等。
租户状态跟踪
对于 SaaS 业务，提供服务是以租户为粒度的。为了提供个性化的服务，租户有很大可自在定制的性能。同一个性能，在一个租户是失常工作的，但在另一租户那里，可能就曾经齐全不可用了。因而，还须要分租户维度对业务主体性能进行监控。对客户的状态跟踪分为两局部，一部分是 SaaS 平台性能，另一部分是客户的接口监控。
SaaS 平台性能容易了解，是指由 SaaS 平台给各个客户提供的性能服务，对客户，特地是大客户以及新客户的性能应用状况进行继续跟踪有很重要的意义。
首先，企业客户对于服务的稳定性要求很高，一旦呈现任何异样，即便是十分渺小，但只有被客户感知到，就很可能会影响客情关系，甚至引发投诉，影响后续的续费及增购。
其次，性能使用量的变动能够反映客户对于平台的依赖水平，当客户某个性能使用量忽然升高，或继续升高时，应关注客户的业务是不是有膨胀，或者是不是客户一部分业务曾经迁徙到了竞品，此时要及时理解起因，保护好客情关系。如果某个性能忽然被客户大量应用，则能够开始为客户行将到来的增购做好筹备了。
（重点企业音讯接口监控面板）
另一部分是客户本人的接口。SaaS 平台提供的性能中，很多都会波及到客户本人的业务数据，须要和客户本人的零碎做买通，因而 SaaS 通常会提供很多接口标准，由客户实现，而后 SaaS 平台在业务流程中去调用。这些内部接口不受平台管制，提供的服务质量参差不齐，出现异常的概率也很大。尽管这些接口故障不影响 SaaS 平台的整体服务，但一来对具体的客户则可能是灾难性的，二来呈现故障后客户的第一反馈通常是 SaaS 平台的故障，要求你尽快查清，这会节约团队相当多的工夫。客户也不肯定有那么欠缺的监控措施，所以，咱们必须把这些接口调用状况依照租户维度监控起来，在出现异常时及时告诉到客户，既是对客户负责，也是加重本身的工作压力。
业务日志
日志是预先剖析的次要伎俩。欠缺的日志信息，能够产生上面这些重要价值：
- 业务后果不合乎预期时，能够业务调用链路信息进行残缺还原剖析，找到问题的起因。
- 对 ERROR 级别日志以及特定关键字的日志进行监控报警。
- 通过结构化的日志，统计分析调用量，执行后果等信息，辅助经营数据统计。
为了这些价值，应用日志零碎有一些最佳实际能够遵循。
首先，良好的日志内容应该是记录的信息不多不少刚刚好的。记录信息太少的问题很显著，然而太多也同样会有问题，会导致真正有用的信息被浓缩，减少整个日志零碎的累赘，甚至影响到外围业务的性能。
其次，日志信息应该是结构化的。一条残缺的日志信息该当蕴含残缺的入参，出参，调用和被调用方信息，要害门路执行后果，耗时等，nginx 的日志就是一个典型例子。为了不便日志记录，可在架构层面做日志记录，并提供方便的 SDK 进行接入。
再者，在分布式架构下，一次残缺的申请会通过很多的节点，在剖析问题时，须要将这些节点上的调用日志都串联起来。这就须要一套残缺的日志采集和查问工具，最罕用的就是 ELK 了。因为日志散布在不同节点上，要把他们串联起来，还须要对整个调用链路打标并记录在日志中。
高效的衰弱大盘
不同的监控维度，适宜采纳的监控形式和工具都不尽相同。日常应用以及进行问题排查时，如果还须要在不同的工具之间进行切换，效率无疑会大打折扣。通过对立的利用衰弱大盘，整合来源于各个系统的数据，在一个平台进行展现和操作，能够大幅提高观测零碎的易用性。
（简洁的业务监控大盘示例）
作为一个聚合展现平台，衰弱大盘仅用于展现零碎的实时衰弱状态。各监测零碎通过对立的接口汇报数据到平台，数据内容包含：
- 服务信息：服务节点信息，服务名，节点标识，节点 IP 等。
- 业务域信息：服务所属业务域，如有必要，可反对多级业务域。
- 数据维度：资源，性能，高可用，业务指标等监控维度。
- 维度优先级：不同优先级的展现权重不一样，高优先级的异样会优先展现。
- 衰弱等级：批示服务的衰弱度，例如无异样时为衰弱，有大量正告时为亚健康，有大量报警时为不衰弱，服务不可用时为宕机。
- 详情链接：用于详情下钻。
衰弱大盘反对以下性能：
- 监控维度聚合：同一节点的所有监控维度数据可聚合展现，依照优先级权重和衰弱等级，加权计算后展现。
- 利用状态聚合：属于对立服务的节点数据能够聚合，属于同一业务域的服务能够聚合展现。
- 优先展现：可依据聚合后的衰弱度优先级实时排序展现，衰弱度低的优先展现。
- 数据下钻剖析：反对节点数据依照监控维度以及服务维度进行下钻剖析。
结语
在网易智慧企业，服务的量级曾经上千，实例数曾经到万级。欠缺的观测体系帮忙咱们屏蔽了零碎架构的复杂性，使得整体零碎的运行状态清晰可见，在故障预警以及问题排查方面施展了微小的作用。借由观测零碎，咱们能够清晰的看到零碎流动的血液，跳动的脉搏，并守护零碎的衰弱。
对于作者
周江华，网易智慧企业资深业务架构师。技术经验丰盛，先后主导过 PC 客户端、挪动端以及服务器的开发工作，是一名全栈工程师，目前次要专一于业务架构及技术治理的相干工作。