写点什么

微服务沉思录 - 可观测性

用户头像
余朋飞
关注
发布于: 2021 年 06 月 15 日
微服务沉思录-可观测性

可观测性(Observability)是微服务得以稳健运行的至关重要一环。在生产环境若缺乏良好的观测性工具和方法,就好比高空的飞机在没有仪表板的情况下飞行一样,两眼一抹黑,充满不确定性因素和未知风险,无法及时发现、定位、转移和修复错误。

业界通常将可观测性大致分为三大类:Metrics,Tracing 和 Logging。通常来说 Metrics 监控侧重于技术指标的收集与观测,如服务调用 QPS、响应时间、错误率和资源使用率;Logging 侧重于运行日志的采集、存储与检索;而 Tracing 则偏向于调用链的串联、追踪与 APM 分析。


数据流

要想实时观测运行时数据,必须有强劲、稳定的数据流 Pipeline 工具来持续支撑数据的采集、传输、存储和应用,包括监控指标、日志数据和链路跟踪数据。

数据采集

数据采集一般通过应用发送消息(如 Kafka、RocketMQ 等),或调用 REST API 来实现,注意一定要异步处理,防止极端情况下主线程被阻塞。也可以通过安装到服务器上的 Agent 来完成日志采集,应用只需要将日志写到磁盘对应的位置即可,典型的 Agent 软件如 Flume、Scribe、Logstash 或自研工具等;

数据传输

数据传输一般包括消息中间件等用于数据移动的平台,也包括数据处理平台,常见的流计算平台有 Storm、Spark Streaming、Flink 等。

从实际工程经验看,建议采集的数据最终都写入 Kafka 消息中间件,Kafka 性能卓越,且具备解耦、缓冲、标准化等优势。

值得注意的是,有时候采集层直接将数据写入存储层,无需额外传输和处理,这种一般适合数据量比较小的传输场景。

数据存储

数据存储一般要兼顾数据量和存储性能。常见的数据存储有:时序数据库系如 OpenTSDB、InfluxDB、Graphite、Prometheus 等;预聚合系如 Druid、Kylin(不支持实时摄入)等;Hadoop 系如 HDFS、Hbase、Hive 等;Lucene 系如 Elasticsearch。

每种数据存储系统特点不一样,一般来说,Metrics 监控用 Prometheus 的比较多,而日志存储大多使用 Elasticsearch。

数据应用

观测性数据的应用一般主要是检索、分析和展示。常见工具有 OLAP 引擎如 Hive、Impala 等,第三方分析、展示工具如 Grafana、Superset、Kibana 等,有实力的公司一般还会自研分析工具;



监控

为什么要分层

很多微服务匆匆上线后,缺乏全面的、分层的、立体化、多维度的监控,仅支持少量的 Metrics 埋点,如 API 接口的 QPS 及响应时间,维度单一,不利于发现和排查问题。等真正出现问题时,要么无法及时感知故障,要么无法下钻和定位问题。以下是一个真实的案例:

某视频播放服务,在晚高峰(21:00 左右)期间,出现了部分 API 告警,监控面板耗时升高,客户端甚至出现了超时等现象。除此之外,工程师拿不到其他任何信息,对接口的成功率、长尾延迟(TP90、TP99 等)、外部依赖情况、运行时监控(线程池、JVM、连接池等)、调用链异常等指标一无所知,查询分析业务日志也没看到明显异常。经过长时间的排查,最终发现是某第三方服务出现故障,导致播放服务延迟上升,整个服务可用性受到了较长时间的影响。

如果能有一套成熟的、立体化的监控体系,可以从多维度来监控和感知系统问题,则可以极大缩短问题的处理时间、提升故障处理效率。本章节重点介绍一种经过实践验证过的分层监控体系。

在分层监控体系中,将监控分为:基础监控、接入层监控、中间件监控、应用层监控、链路监控、端到端监控。通过分层架构设计,使得可观测性得到较大提升。可以 7*24 小时监控服务的 QPS、平均及长尾响应时间、错误率、系统负载等情况,并提供实时的告警机制,提升问题发现的敏捷性。

基础监控

基础监控一般指单机的系统指标监控,如 CPU 使用情况、内存占用情况、磁盘使用率、系统平均负载、网络情况等。一般采用开源软件实现,如 Nagios、Zabbix、Ganglia 等,有条件的公司则会自研监控软件,用于定制化需求。

中间件监控

中间件监控泛指应用之外的资源监控,典型的有存储、消息中间件、搜索等。如 MySQL、MongoDB、HBase、Redis 的数据量监控、连接数监控、QPS 监控、主从同步、慢查询监控如分析等。如 ActiveMQ、RocketMQ、Kafka 的消息写入和消费监控、消息积压监控等。

接入层监控

监控流量的入口,如请求 QPS、延迟(平均/百分比分布/区间分布)、错误率、HTTP 状态码、API 业务码等监控,一般通过采集和分析接入层(如 Nginx)的访问日志得到。

应用监控

应用监控指应用服务本身的各类指标监控,如 QPS、延迟(平均/百分比分布/区间分布)、错误率、资源饱和度、入口(Inbund)监控、出口(Outbund)监控等。一般由应用服务内部埋点 Metrics 数据得到。

链路监控

链路监控,泛指拓扑分析、错误分析、资源分析、监控告警(QPS/延迟:百分比分布|区间分布/错误率)、链路检索等一系列标准监控。可以支持请求的串联与分析,较大程度提升排查问题效率。

端到端监控

端到端监控也称黑盒监控,通常会在全国各地乃至海外设立许多拨测点,覆盖各主流地理位置(如华东、华北、华中和华南)和各主流运营商(如移动、联动、电信)。由拨测点发起周期性请求,对目标服务进行远侧拨测,并对返回结果进行必要的校验(如 HTTP 状态码、耗时、报文分析校验等),对有问题的拨测进行及时告警通知。

端到端监控和以上其他监控不同点在于,能模拟真实外网环境,能发现其他监控无法识别的故障,如华南地区到服务主机房的网络出现大量丢包和延迟。

侵入 OR 非侵入

涉及到 Metrics 埋点的代码,侵入式和非侵入式孰优孰劣并不能一概而论。侵入式并不一定总是糟糕的、强耦合、不易扩展设计,非侵入式也不一定就是优雅的设计。

大多数情况下,侵入式埋点粒度更细,能细到代码级别的织入监控指标,而且具备更好的性能和灵活性。非侵入式埋点由于大多采用了运行时织入(RTW)或 Agent 技术,往往都有一些性能损耗,另外粒度一般只能到方法级别。

能否标准化

试想一下一个微服务的监控是如何上线的。通常工程师会捕捉需要监控的技术指标,并在代码进行埋点,等服务上线后,在监控系统上配置对应的监控面板(Dashboard)和必要的报警。

看起来似乎很完美,但经过长期的项目迭代,我们也会发现一些问题:

·       埋点不规范,似乎各种指标都不缺,在关键时刻似乎又派不上用场;

·       大量的手工埋点和重复性埋点,效率低,容易出错;

鉴于此,可以考虑对各种常见的监控指标进行抽象和总结,提炼出标准化的监控。常见的标准化监控有:

入口(Inbund)监控,对服务的 QPS、延迟(平均/百分比分布/区间分布)、错误率、HTTP 状态码、业务码进行监控,并支持自动化生成监控大盘。

出口(Outbund)监控,对第三方依赖的 QPS、延迟(平均/百分比分布/区间分布)、错误率进行监控,能自动生成监控及报表,并具备告警能力,可通知到第三方技术负责人。

资源(Resource)监控,对应用的运行时进行监控,如 JVM 内存分布、线程池(核心大小、队列占用情况等)、连接池(最大连接数、最小活跃连接数、连接可用情况等)。

发布于: 2021 年 06 月 15 日阅读数: 418
用户头像

余朋飞

关注

还未添加个人签名 2018.08.18 加入

程序员,技术Leader。长期专注于软件开发和技术管理,乐于分享。

评论 (3 条评论)

发布
用户头像
skywalking到哪里去了?
2021 年 06 月 16 日 11:43
回复
用户头像
skywalking应该有
2021 年 06 月 16 日 11:41
回复
用户头像
好文章
2021 年 06 月 16 日 10:49
回复
没有更多了
微服务沉思录-可观测性