引言
而另一方面,对于 SaaS 应用来说,其面向企业的属性,决定了对于服务可靠性的极高要求。一是出现故障时,我们需要快速定位问题并排除故障,恢复服务。更重要的,则是能够时刻清楚了解系统的运行状态,在系统有变坏趋势发生前,及时发现,消灭故障于无形。
什么是可观测性
汽车仪表盘及其连接的传感器和信号传输系统,便是对于汽车系统可观测性的最基础,最直观的例子。如果需要更深入了解汽车各个部件的状态,还可以连接车辆的 OBD 接口,从中获取到更多的车辆当前状态以及历史状态数据。通过 OBD 接口,汽车系统的可观测性也被大大增强。基于 OBD 数据,又衍生出了很多的手机管理软件,可以更简单的观察车辆状态,还能记录过往更多历史数据,做驾驶习惯趋势分析等,更大的扩展了汽车的可观测性。
具备可观测性的系统,运维以及研发人员可以直观的观察到系统的整体运行状态是否健康,同时又能轻易的深入到运行的各个细节角落。在正常运行时,观测系统能对系统负载进行评估,对运维操作提供建议。在发生故障时,可协助快速定位和修复问题。在运维自动化和智能化的大趋势中,系统的可观测性是其中最基础的一环。
构建完善的观测系统
图片引自 Prometheus 官网
1.服务状态感知组件
- 独立监测工具,例如,监测系统运行状态的 sar,top,dstat 等。
- 字节码注入
- 结构化日志
- 行为事件埋点
该组件是整个观测体系的核心,将采集的数据上报,然后高效的存储下来。对于不同的数据,不同的分析方式,应采用合适的存储数据格式和存储介质。最常用于存储监控数据的是时序数据库,例如 Prometheus,InfluxDB 等。对于数据采集方,提供各种度量类型,用于结构化的汇报数据,包括
- Gauges:计量器,用于内存,线程数等简单计数场景。
- Counters:计数器,用于请求数,错误数等统计场景。
- Histograms:直方图,用于平均响应时间,RT 95 值等需要计算均值,方差,分位数的场景。
- Meters:TPS计数器,用于速率统计,以及 1 分钟,5 分钟均值一类的统计。
- Timers:计时器,用于统计请求时延,例如请求时延,磁盘读取时延等。
观测系统能否产生价值,可视化界面是最主要的一个决定因素,可视化系统必须支持灵活配置,灵活组合,又易于使用,信息展示足够直观。开源的可视化监控工具使用最广泛的是 Grafana。
报警功能是整个监控系统最核心的价值之一,在系统已经发生异常或者可能会发生异常时,报警系统能通过邮件,IM,短信,电话等多种渠道,及时通知到相关方,让相关的运维和研发介入处理。
报警配置主要有两类,状态事件报警和趋势报警。
- CPU 使用率超过 95%
- 磁盘空间占用率超过 90%
- JVM 连续发生 fullgc
- 接口调用一段时间失败超过 N 次,比率超过 x%
- Tomcat 线程数超过 120
- 业务打印出 ERROR 级别日志
- 消息量比一周前下降 30%
- 某 URL 接口请求量比一分钟前增加了 30%
- 内存使用量连续十分钟增长超过 5%
覆盖全面的观测维度
(一)资源监控
对于各个类型的资源,下面是一些经常要关注的点,要在我们的监控系统中清晰呈现出来。
- CPU:对于计算型应用,CPU 是核心资源,负载高低直接指示了当前的系统的负载情况。对于非计算型应用,CPU 通常处于低负载状态,如果某个时间点 CPU 负载突然飙高,通常指示应用有 bug 了,比如有死循环,或者是虚拟机在频繁的 fullgc 导致负载下不来,或者是网络流量飙高导致 CPU IO 处理以及上下文切换负担加重。
- 进程存活情况:检查是否存在指定进程名的进程。
- 内存:内存使用率,剩余内存量。
- 硬盘:包括硬盘空间,inode 数量,磁盘 IO 情况等。
- 网卡:进出网络流量,进出网络 PPS,丢包率等
资源监控聚焦于操作系统层面,性能监控则聚焦于应用层面,也就是我们常说的应用性能管理(APM)。
- JVM 内存状态
- JVM GC 情况
- Java 方法调用统计
- Tomcat 线程状态
- 自定义线程池工作状态
能通过这种方式来监控的接口类型有:
- HTTP 接口调用/被调用情况统计
- RPC 接口调用/被调用情况统计
- SQL 执行情况统计
- Redis 访问情况统计
- 各个服务节点性能分析
- 故障快速定位
- 请求调用链路分析
- 服务依赖分析与治理
(三)业务监控
而对于研发团队,业务监控最重要的是指示业务的健康程度,因此展示的数据类型会所有不同,一般会更加细致,维度也会更加全面。
比如,对于七鱼来说,其核心业务流程是访客与客服的沟通,以及客服工作效率提升,因此整体业务监控指标会包括:
- 并发会话量
- 并发话务量
- AI 解答量
- AI 解决率
- 在线坐席数
- 消息收发速率
- 工单创建速率
- 地域:地域主要关注的是网络情况,尤其是对于视频这种网络敏感的业务。网络地域差异最大的是 CDN 覆盖质量,其次是各地域运营商对于网络访问的限制措施,再就是经常见诸报道的某个地方的光纤被挖断的事件。
- 用户:对于不同类型的用户,可能会提供不同的功能,常见区分用户的方式有 VIP,标签等等。
对于 SaaS 业务,提供服务是以租户为粒度的。为了提供个性化的服务,租户有很大可自由定制的功能。同一个功能,在一个租户是正常工作的,但在另一租户那里,可能就已经完全不可用了。因此,还需要分租户维度对业务主体功能进行监控。对客户的状态跟踪分为两部分,一部分是 SaaS 平台功能,另一部分是客户的接口监控。
另一部分是客户自己的接口。SaaS 平台提供的功能中,很多都会涉及到客户自己的业务数据,需要和客户自己的系统做打通,因此 SaaS 通常会提供很多接口标准,由客户实现,然后 SaaS 平台在业务流程中去调用。这些外部接口不受平台控制,提供的服务质量参差不齐,出现异常的概率也很大。虽然这些接口故障不影响 SaaS 平台的整体服务,但一来对具体的客户则可能是灾难性的,二来出现故障后客户的第一反应通常是 SaaS 平台的故障,要求你尽快查清,这会浪费团队相当多的时间。客户也不一定有那么完善的监控措施,所以,我们必须把这些接口调用情况按照租户维度监控起来,在出现异常时及时通知到客户,既是对客户负责,也是减轻自身的工作压力。
(五)业务日志
- 业务结果不符合预期时,可以业务调用链路信息进行完整复原分析,找到问题的原因。
- 对 ERROR 级别日志以及特定关键字的日志进行监控报警。
- 通过结构化的日志,统计分析调用量,执行结果等信息,辅助运营数据统计。
首先,良好的日志内容应该是记录的信息不多不少刚刚好的。记录信息太少的问题很明显,但是太多也同样会有问题,会导致真正有用的信息被稀释,增加整个日志系统的负担,甚至影响到核心业务的性能。
再者,在分布式架构下,一次完整的请求会经过很多的节点,在分析问题时,需要将这些节点上的调用日志都串联起来。这就需要一套完整的日志采集和查询工具,最常用的就是 ELK了。由于日志分布在不同节点上,要把他们串联起来,还需要对整个调用链路打标并记录在日志中。
高效的健康大盘
作为一个聚合展示平台,健康大盘仅用于展示系统的实时健康状态。各监测系统通过统一的接口汇报数据到平台,数据内容包括:
- 服务信息:服务节点信息,服务名,节点标识,节点 IP 等。
- 业务域信息:服务所属业务域,如有必要,可支持多级业务域。
- 数据维度:资源,性能,高可用,业务指标等监控维度。
- 维度优先级:不同优先级的展示权重不一样,高优先级的异常会优先展示。
- 健康等级:指示服务的健康度,例如无异常时为健康,有少量警告时为亚健康,有大量报警时为不健康,服务不可用时为宕机。
- 详情链接:用于详情下钻。
- 监控维度聚合:同一节点的所有监控维度数据可聚合展示,按照优先级权重和健康等级,加权计算后展示。
- 应用状态聚合:属于统一服务的节点数据可以聚合,属于同一业务域的服务可以聚合展示。
- 优先展示:可根据聚合后的健康度优先级实时排序展示,健康度低的优先展示。
- 数据下钻分析:支持节点数据按照监控维度以及服务维度进行下钻分析。
结语
更多技术干货,欢迎关注vx公众号“网易智慧企业技术+”。系列课程提前看,精品礼物免费得,还可直接对话CTO。