爱奇艺微服务监控的探索与实践

发布于:2020 年 6 月 22 日 10:05

爱奇艺微服务监控的探索与实践

作为一线程序猿,是否有过类似经历?新接手一个系统,各接口入口流量是多少,又是哪些业务方在调用?系统大量异常报警,如何快速锁定影响范围,恢复故障并定位问题?接口调用超时,究竟是客户端问题还是服务端响应慢,还是网络波动来背锅?
监控的重要性不言而喻,可是接入监控的额外工作又让人望而却步?每天编写代码之余,又要花多少时间定位线上问题?自己负责的系统故障,是否要等调用方反馈才知道?本文分享爱奇艺有关微服务监控的实践和思考。
如文章《爱奇艺视频后台从 " 单兵作战 " 到 " 团队协作 " 的微服务实践》 所述,2018 年爱奇艺信息流技术团队基于 Spring Cloud 和公司服务云组件,实现了业务系统的全面微服务化。微服务的拆分,一方面提升了服务负责人的 ownership,助力业务快速迭代。另一方面,随着微服务的增加,监控成本随之增加,构建简单有效的微服务监控体系的诉求愈发强烈。本文从以下 3 个方面展开介绍。

  • 背景 & 初探: 介绍建设微服务监控体系的背景,微服务监控体系建设初期的探索和尝试。
  • 演进 & 实践: 基于早期微服务监控探索和思考,落地微服务微服务监控体系的具体实践。
  • 总结 & 展望: 总结微服务监控建设过程中的实践和思考,以及工作规划。

背景 & 初探

经过一年多的野蛮生 长,信息流团队微服务发展快速,人均负责 5 个微服务以上,为了全面了解每个微服务运行情况,第一时间感知微服务异常,快速定位线上问题,提高运维效率,微服务建设初期我们尝试了多种监控方案。

这个阶段,我们对微服务监控缺少系统的理论认知和实践经验,所以更多是对已有的监控基础设施和框架低成本的整合和适配。

下面分别从日志监控,Hystrix 监控,Actuator 监控,拨测监控 5 个方面介绍。

日志监控

基于日志的监控方案,原理如下图,业界技术方案成熟(例 ELK),公司也提供了通用解决方案(Venus),容易落地。缺点是,日志监控链路较长,延迟时间大,报警可能不够及时。

爱奇艺微服务监控的探索与实践

Hystrix 监控

很长一段时间 Hystrix 是服务熔断降级监控的代名词,Spring Cloud 应用中使用 hystrix 极致易用,从低成本埋点,到配置动态调整,再到原生的可视化 Dashboard,使用成本都很低。缺点是,指标数据原生没有持久化,二次开发有一定成本。

下图描述基于 Hystrix 监控的方案。

爱奇艺微服务监控的探索与实践

Actuator 监控

Actuator 端点是 Spring Boot 应用开发者的最大福利之一,可以零成本了解单实例运行情况。缺点是,同服务多实例指标聚合,指标持久化,指标时序可视化,都需要二次开发。下图描述 Actuator 端点监控的方案。

爱奇艺微服务监控的探索与实践

拨测监控

对于面向用户的服务,用户所处网络,地域差异性很大,应用本身可用不代表用户可以正常使用服务,这就需要从用户角度,对服务可用性进行定时拨测。

下图描述拨测监控的方案,主要包括微服务实例自发的健康检查和各拨测点定时拨测。

爱奇艺微服务监控的探索与实践

链路监控

链路监控既可用于调用链路分析,快速定位具体问题,又可用于梳理服务拓扑结构和依赖合理性,是微服务监控必不可少的一环。

我们使用公司服务云提供的日志收集组件 Venus(如前所述)和链路跟踪组件 Rover(基于 Skywalking+Brave)实现该功能。实现方案如下图所示。

爱奇艺微服务监控的探索与实践

其中,接入固定成本表示为引入相应监控而产生的一次性固定投入,包括学习调研,二次开发,集成适配等成本。接入边际成本表示每新增一个微服务或一个监控指标,新产生的开发配置成本。几种监控方案对比和适用场景如下表所示。

监控类型 接入固定成本 接入边际成本 时效性 持久化可追溯 适用场景
日志监控 极低,基于现有日志收集系统 中,日志埋点、解析有一定成本 秒级,链路长,有时延迟较大 日志持久化,可查看历史 时效性要求不高的监控;具体问题排查
Hystrix 监控 低,需要部署 Hystrix Dashboard 低,简单配置 秒级 需二次开发 依赖接口实时监控;熔断降级
Actuator 监控 低,需要部署 Spring Boot Admin 无,应用内置 秒级 需二次开发 单实例指标查看
拨测监控 无,基于公司云拨测服务 低,简单配置 分钟级,取决于拨测间隔 有报警历史 面向用户服务可用性定时拨测
链路监控 中,需要适配各种中间件 低,简单配置 秒级,依赖日志流 可以 跨系统调用链路分析

演进 & 实践

如上所述,我们在微服务监控建设初期尝试了多种监控方案,实现了不同场景下的监控需求,也遇到了新的问题。概括起来,有以下几个:

  • 缺少对监控项的统一认知和定义
  • 重复性埋点配置工作,监控成本高
  • 各种监控方案简单组合,可视化分散,报警不统一
  • 日志监控,报警时效性无保障

比如,每新增一个监控指标,需要把接入,埋点,可视化,报警,从头来一遍,随着微服务和指标增加,这种重复性工作严重制约了监控体系的推广落地。特别是 metrics 监控,指标繁杂,维度多变,应用广泛。

为此,建设一套 监控模型统一,接入成本低,可视化集中管理,报警时效性高,监控指标全面 的微服务监控体系势在必行。下面着重介绍信息流监控系统针对 metrics 监控的实践。

爱奇艺微服务监控的探索与实践

信息流 Metrics 监控在 Prometheus 基础上,以构建简单易用的监控系统为目标,对 Spring Cloud 框架进行适配整合和定制开发。整体结构如上图,我们主要做了以下工作。

监控模型

监控指标是监控系统的基本对象,监控哪些指标,如何定义描述这些指标,是首要解决的问题。我们通过引入指标 - 维度 - 数值多维度数据模型,对常用监控指标和维度进行梳理和定义,形成对监控对象的统一描述和共识,为后续实现维度灵活聚合、定义统一的可视化模板和报警模板奠定基础。

通用指标定义

指标 说明
QPS 系统每秒处理业务请求量,反应系统的容量
TP 指标 TP99、TP95、MEAN 等,反应的是系统的时效性
错误量 http 错误响应码的次数,方法调用异常次数等,反应系统的错误面
资源使用率 CPU 利用率、内存利用率、磁盘利用率等,反应系统资源利用面

通用维度定义

维度 说明
service_name 服务名,例:Order
dc 机房, 例:bjdx
instance 服务实例,例:1.1.1.1:2222
url 接口 API,例:/order/list
method 方法签名
status http 响应码

定制扩展

自动接入 & 埋点

前期我们尝试了多种监控方案,发现能够顺利推广落地的,都有一个共同点,就是服务接入监控的成本很低。最好是不要求应用做任何改动,就可以自动接入,享受监控系统带来的便利。为此我们做了以下工作:

  • 每个服务引入 sdk 自动完成通用指标(Http 请求,JVM 指标等)采集,并暴露指标拉取端点
  • 每个服务自动注册到 Eureka 注册中心
  • Eureka 增加 Adapter,提供监控系统可识别的接口方法
  • 监控系统从注册中心,自动发现要监控的服务实例列表
  • 监控系统定期从服务指标端点拉取监控数据

爱奇艺微服务监控的探索与实践

声明式方法监控

很多情况下,需要对某些业务方法耗时进行监控,传统的埋点方式是在方法入口和出口添加监控代码,业务代码侵入高,开发成本高。

爱奇艺微服务监控的探索与实践

PUSH 模式扩展

如前所述,Prometheus 是用 PULL 模式获取应用埋点数据,但是有的场景下 PULL 模式并不适用(比如短生命周期的任务),因此我们基于 Prometheus 提供的 Pushgateway 组件,实现 PUSH 模式获取监控埋点数据。

一种应用场景是,实时收集各个服务日志流中的异常信息。我们监听日志采集的 Kafka 消息,Flink 实时解析出服务异常名称,将各个服务产生的异常实时推送到监控系统,并在 Grafana 上集中展示。基于 Pushgateway 的异常监控方案及效果图如下。

爱奇艺微服务监控的探索与实践

集中可视化

不同的监控系统,往往会提供不同的可视化方案。分散的可视化,不利于监控数据的集中展示和全局问题分析。我们使用 Grafana 实现所有微服务,所有指标的集中可视化。

每个微服务使用统一的监控模板,集中展示各服务入口流量、内部方法、JVM 等相关指标。Dashboard 模板主要包含以下模块:

  • 维度筛选模块

爱奇艺微服务监控的探索与实践

  • JVM 和系统指标模块

爱奇艺微服务监控的探索与实践

  • 入口流量机房分布 & 状态码 &QPS& 响应延时模块

爱奇艺微服务监控的探索与实践

• 方法监控指标模块

爱奇艺微服务监控的探索与实践

统一报警

基于前边定义的通用指标和维度,对所有指标配置默认的报警规则,同时支持自定义报警规则和阈值。基于 Grafana Web hook 将报警通知发送给 Alert Manager,Alert Manager 对报警进行相同合并、重复过滤、并格式化为统一报警模板后,投递到爱奇艺统一报警平台,业务 owner 通过统一报警平台完成报警订阅。统一报警方案及报警样例如下图。

爱奇艺微服务监控的探索与实践

以上所述,爱奇艺信息流监控整体方案总结如下。

爱奇艺微服务监控的探索与实践

自下至上包括 4 层:

  • 监控对象既包括常驻进程微服务,也包括短生命周期的非常驻进程。
  • 指标获取方式既可以基于 Prometheus 实时拉取,也可以基于 Venus 日志收集,前者用于指标实时获取,保证监控报警时效性,后者记录详细日志,用于具体问题排查和链路分析。
  • 监控维度 从 4 个维度监控应用:
    1. Metrics 监控宏观上检测系统 QPS,响应耗时,错误率和资源利用率;
    2. 拨测监控从用户角度监控服务可用性;
    3. 链路监控提供单个请求完整生命周期的跟踪路径,专门应对微服务架构带来的分布式调用复杂性;
    4. 日志查询提供应用监控最精细化的信息,用于具体问题排障。
  • 集中管理,集中可视化和统一报警管理,在最上面一层,便于排查问题时全面快速获取应用所有监控报警信息。另外,微服务监控的统一认知和必要的流程规范,贯穿监控系统落地始终。

监控系统落地 1 年多,新增服务基本实现零成本 100% 接入自动埋点、集中可视化和统一报警,业务 owner 不需要为接入监控做额外工作,就可以享受监控带来的各种便利;系统异常发生后,可以做到秒级收到报警,借助微服务监控大盘,配合链路监控和日志查询,分钟级确认异常影响范围并定位问题,大大减少故障恢复时间,提升运维效率;目前该方案也在多个其他团队推广落地。

总结 & 规划

本文介绍了爱奇艺信息流团队微服务监控的探索和实践,涵盖了日志监控,Hystrix 监控,拨测监控,链路监控,Prometheus 监控等,从最初的多种监控方案兼容并包,到基于多维度数据模型和集中可视化的定制开发。不能简单说,后面的监控方案比前期的好,而是在微服务监控不同发展阶段,监控体系建设投入和收益的折中选择。下面是微服务监控探索过程中一些心得。

  1. 简单有效。简单有效是评测监控系统好坏的最高准则,埋点是否简单甚至可省去,是否存在重复性的配置工作,都会影响监控方案能否最终落地推广。好的监控方案一定是,没有故障时,开发人员无感知,出现故障时,想看的指标都能拿到。
  2. 集成定制。业界和公司提供了固定场景下的监控框架和方案,基于这些成熟的方案和基础设施,会大大减少监控系统建设投入;另一方面,必要的定制开发封装,会进一步推动自动化监控落地。
  3. 集中管理。考虑监控指标的多样性(系统,应用,业务等),不同监控方案关注点不同,指标埋点,收集,获取未必仅用一套,但是可视化应该尽可能集中,方便统一管理和全局分析。
  4. 流程规范。微服务监控不是一个人或少数几个人的事,也不应该微服务上线后才被关注,它需要每位微服务 owner,从编码,甚至设计阶段,就要考虑监控指标和维度。为了减少监控带来的额外负担,保障落地效果,必要的流程规范和分享培训是必要的。

以上是监控实践的阶段性探索实践总结,未来还有很多方面需要持续的优化和改进,例如灵活的报警规则,恰如其分的报警,更低成本的埋点、可视化,服务质量评测报告等。另外,依托大数据分析和人工智能能力,系统异常检测,根因分析,智能合并,故障预测和自恢复技术愈发成熟,推动 AI 赋能数字化运维落地也是我们努力的方向。

本文转载自公众号爱奇艺技术产品团队(ID:iQIYI-TP)。

原文链接

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247487206&idx=2&sn=2109191dfba890b0f6ff6a5b08870bc5&chksm=e97692c5de011bd32c588762402b51b946813d9eb0bec2f4aced3c1d6de3e296fbe5b833a894&scene=27#wechat_redirect

阅读数:2 发布于:2020 年 6 月 22 日 10:05

评论

发布
暂无评论