爱奇艺号基于Prometheus的微服务应用监控实践

前 言

微服务架构是目前各大互联网公司普遍采用的软件架构方式。在微服务架构中，系统被拆分为多个小的、相互独立的服务，这些服务运行在自己的进程中，可以独立的开发和部署。在业务快速变化时，微服务单一职责、自治的特点，使系统的边界更加清晰，提升了系统的可维护性；同时，简化了系统部署的复杂度，可以针对某个微服务单独升级和发布；在业务增长时，也可以方便的进行独立扩展。

微服务架构虽然带来了很多好处，但也带来了新的问题。在以往的单体应用中，排查问题往往通过查看日志定位错误信息和异常堆栈；但是在微服务架构中服务繁多，出现问题时的问题定位变得非常困难。另外，微服务往往通过组合已有的服务来创建新服务，一个服务的故障很可能会产生雪崩效应，导致整个系统的不可用。因此，如何监控微服务的运行状况、当出现异常时能快速给出报警，这给开发人员带来很大挑战。

本文将介绍我们基于Prometheus搭建微服务监控系统的一些实践经验，及爱奇艺号在微服务监控方面的一些探索和实践，从爱奇艺号的业务特点出发，结合现有的开发运维技术栈确定监控的对象和指标，并有针对性地自研了一些关键组件和服务，实现服务的全面监控和统一报警。

1  监控系统简介

1.1

监控的几种主要方式

在微服务架构中，不同维度有不同的监控方式。

（1）健康检查。健康检查是对应用本身健康状况的监控，检查服务是否还正常存活。

（2）日志。日志是排查问题的主要方式，日志可以提供丰富的信息用于定位和解决问题。

（3）调用链监控。调用链监控可以完整的呈现出一次请求的全部信息，包括服务调用链路、所耗时间等。

（4）指标监控。指标是一些基于时间序列的离散数据点，通过聚合和计算后能反映出一些重要指标的趋势。

在上述4中监控方式中，健康检查是云平台等基础设施提供的能力，日志则一般有单独的日志中心进行日志的采集、存储、计算和查询，调用链监控一般也有独立的解决方案进行服务调用的埋点、采集、计算和查询，本文主要讨论第4种监控方式。

1.2

微服务监控的技术选型

由于微服务架构自身的特点，使得传统的一些监控方案不再适用。在传统应用监控中，Zabbix是最常用的监控方案。Zabbix的优点在于成熟可靠、强大的社区支持、多年积累的经验和方案。但Zabbix的缺点也很明显，首先是使用难度高、学习曲线陡峭；其次，Zabbix的监控维度是主机，无法适用于微服务的云原生环境。

经过调研，我们最终采用了Prometheus。选择Prometheus的主要原因：

（1） 成熟的社区支撑。Prometheus是一个开源的监控软件，拥有活跃的社区，能够很好地与云原生环境搭配。

（2） 易于部署和运维。Prometheus核心只有一个二进制文件，没有其他的第三方依赖，部署运维均十分方便。

（3）采用Pull模型，通过HTTP的Pull方式从各个监控目标拉取监控数据。Push模型一般通过Agent方式去采集信息并推送到收集器中，每个服务的Agent都需要配置监控数据项与监控服务端的信息，在大量服务时会加大运维难度；另外，采用Push模型，在流量高峰期间监控服务端会同时接收到大量请求和数据，