微服务架构是各大互联网公司常用的一种软件架构方式。在微服务架构中，系统被拆分成多个独立的小服务，运行在各自的进程中，可以独立开发和部署。当业务快速变化时，微服务职责单一、自治的特点，使得系统的边界更加清晰，提高了系统的可维护性；同时简化了系统部署的复杂度，可以针对一个微服务单独升级发布；当业务增长时，也可以方便地独立扩展。虽然微服务架构带来了很多好处，但也带来了新的问题。在以前的单体应用中，故障排除通常是通过查看日志来定位错误消息和异常堆栈；但是在微服务架构中，服务比较多，一旦出现问题，定位就变得非常困难。此外，微服务通常通过组合现有服务来创建新服务。一个服务的故障很可能会产生雪崩效应，导致整个系统不可用。因此，如何监控微服务的运行状态，并在出现异常时快速报警，对开发者提出了很大的挑战。本文将介绍我们基于Prometheus搭建微服务监控系统的一些实践经验，以及爱奇艺在微服务监控方面的一些探索与实践。从爱奇艺的业务特点出发，结合现有的开发运营技术栈，确定监控对象和指标，有针对性地开发一些关键组件和服务，实现对服务的全面监控和统一告警。一、监控系统介绍1、监控的几种主要方式监控的几种主要方式在微服务架构中，不同的维度有不同的监控方式。1）健康检查。健康检查就是监控应用本身的健康状态，检查服务是否还活着。2）日志。日志是排查问题的主要途径。日志可以为定位和解决问题提供丰富的信息。3）调用链监控。调用链监控可以完整呈现一个请求的所有信息，包括服务调用链接、耗时等。4）指标监控。指标是一些基于时间序列的离散数据点，经过聚合计算可以反映一些重要指标的变化趋势。以上四种监控方式中，健康检查是云平台等基础设施提供的能力，日志一般有独立的日志中心进行日志收集、存储、计算、查询，调用链监控一般有独立的服务调用解决方案埋点、采集、计算、查询，本文主要讨论第四种监测方法。2、微服务监控的几种主要技术选型和监控方法由于微服务架构本身的特点，一些传统的监控方案已经不适用了。在传统的应用监控中，Zabbix是最常用的监控方案。Zabbix的优势在于其成熟可靠、强大的社区支持以及多年积累的经验和解决方案。但是Zabbix的缺点也很明显。首先，它很难使用并且学习曲线陡峭。其次，Zabbix的监控维度是宿主机，无法应用于微服务云原生环境。经过研究，我们最终采用了Prometheus。选择Prometheus的主要原因：1）成熟的社区支持。Prometheus是一款开源监控软件，拥有活跃的社区，可以很好地与云原生环境配合使用。2）易于部署和维护。Prometheus的核心只有一个二进制文件，没有其他第三方依赖。部署和维护都非常方便。3）使用Pull模型，通过HTTPPull方式从各个监控目标中拉取监控数据。Push模型一般采用Agent方式收集信息，推送给采集器。每个服务的Agent需要配置监控数据项和监控服务器信息，在大量使用服务时会增加运维难度；另外，使用Push模型，在流量高峰期，监控服务器会同时收到大量的请求和数据，这会给监控服务器带来很大的压力，严重时甚至会导致服务崩溃不可用。4）强大的数据模型。Prometheus采集的监控数据以指标的形式存在于内置的时序数据库中。除了基本指标名称外，还支持自定义标签。可以通过标签定义丰富的维度，方便监控数据的聚合和计算。5)强大的查询语言PromQL。通过PromQL，可以实现监控数据的查询、聚合、可视化和告警。6）完善的生态。常见的操作系统、数据库、中间件、类库、编程语言，Prometheus提供接入解决方案，并提供Java/Golang/Ruby/Python等多种语言的客户端SDK，可快速实现自定义监控逻辑。7)高性能。Prometheus单实例可处理数百个监控指标，每秒处理数十万条数据，在数据采集和查询方面具有卓越的性能。由于采集到的数据可能会丢失，Prometheus不适合对采集到的数据要求100%准确的场景。其实对于监控系统场景来说，偶尔的数据丢失是完全可以接受的。二、基于Prometheus的微服务监控解决方案1、爱奇艺账号的业务特点。动漫、知识、网络综艺、纪录片、文学、轻小说、漫画等内容是爱奇艺内容生态的重要组成部分。爱奇艺整体采用微服务架构。它内部根据功能和领域划分为不同的微服务。外部流量首先经过DNS、QLB、前端处理器、网关等层级，完成统一认证、负载均衡、限流等。运行后，路由到系统内部不同的微服务实例。除了专有的MySQL、Redis、MQ等资源外，系统内部的微服务共享服务注册/发现、配置中心等服务管理能力。系统整体架构如下图所示：爱奇艺服务于内容创作者，服务质量直接决定创作者的用户体验，影响内容创作的积极性，进而影响内容生态的健康，因此它对服务质量有很大的影响。要求。同时，爱奇艺作为前端业务，依赖于公司内部的很多服务和中台服务，服务的稳定性直接影响到自身服务的质量。基于爱奇艺的业务特点，在构建微服务监控系统时，重点关注自身服务接口和第三方服务接口的监控。2、微服务监控系统概述我们基于Prometheus构建了适合自身业务特点的微服务监控系统。Prometheus提供了非常丰富的组件，我们也开发了一些组件来满足我们的监控需求。微服务监控系统整体架构如下图所示：使用SpringBootActuator和Micrometer采集服务监控数据，暴露给Prometheus拉取；开发第三方服务接口监控数据采集工具；开发qae-monitor组件，收集服务运行时容器的监控数据；开发了基于文件的动态服务发现，为Prometheus提供拉取目标；开发了Alert代理服务，将告警内容下发到统一的告警平台；使用Prometheus联邦集群方式部署，使用Grafana进行监控数据展示。3.业务全面监控监控系统一般对监控对象进行分层划分。在我们的监控体系中，主要关注以下几类监控对象：容器环境监控，主要是指服务所在运行环境的一些监控数据；应用服务监控，主要是指服务本身的基础数据指标，提现服务本身的运行状态；第三方接口监控，主要是指调用其他外部服务接口的情况。对于应用服务和第三方接口监控，我们常用的指标包括：响应时间、请求量QPS、成功率。1）容器环境监控微服务应用部署在爱奇艺内部应用云平台（QAE）上。在云平台中，一台主机上同时存在多个容器实例。宿主机监控收集到的资源使用情况和性能特征，其实是宿主机的指标数据，而不是运行中的容器。Prometheus虽然支持使用cAdvisor进行容器监控，但是cAdvisor需要安装在宿主机上，而QAE是公共平台，自己安装部署其他软件不太现实。幸运的是，QAE提供了一个开放的API，很好地解决了这个问题。QAE平台本身内置了监控功能，包括容器级和应用级两个层次。除了通过QAE平台的页面查看外，还支持通过HTTP接口暴露监控数据，为我们提供统一的监控数据采集。可能的。我们开发了一个QAE容器监控数据采集服务qae-monitor。qae-monitor服务通过自定义PrometheusCollector实现QAE监控数据的采集。服务定时调用QAE平台的HTTP接口抓取容器监控数据，整理成Prometheus的数据格式。qae-monitor本身也通过Micrometer暴露了监控数据采集端点，Prometheus通过该端点抓取采集到的监控数据。2）应用服务监控基础监控数据主要是指应用服务实例的运行状态、资源使用情况等指标。默认情况下，Micrometer提供了一组非常丰富的应用程序指标。只要连接Micrometer，就可以直接采集这些数据，主要包括：系统信息，包括运行时间、CPU使用率、系统负载等；内存使用情况，包括堆内存使用情况和非堆内存使用情况；线程使用情况，包括线程数、守护线程数、线程峰值等；类加载信息；GC信息，包括GC次数、GC消耗时间等；HTTP请求状态，描述HTTP请求的性能指标，是一个非常重要的监控指标，在统计HTTP服务的QPS、响应时间和成功率时必不可少。3）第三方接口监控在微服务架构中，可以通过调用和组合已有的服务来创建新的服务。第三方接口会直接影响到自己的服务，所以第三方服务接口的调用也是值得关注的。关于如何采集第三方服务接口的监控数据，主要有两种解决方案：①显式主动采集在第三方接口调用发生的地方主动采集监控数据。要么直接硬编码，要么采用注解和切面的形式，优点是解决方案简单，缺点是会对现有业务代码造成入侵。②隐式组件采集在使用的??HTTP/RPC组件中加入埋点采集逻辑。优点是不需要修改业务代码，缺点是需要扩展升级HTTP/RPC组件。我们最终选择了第二种方案。主要原因有：一是我们的技术方案比较统一，服务调用使用HTTP协议，使用的HTTP客户端组件（fluent-hc）也是基于Okhttp3的二次封装。便于统一修改；其次，Micrometer支持通过SDK自定义监控指标数据采集，也提供了很多常用的组件嵌入方案，Okhttp3就是其中之一，进一步简化了第三方接口的监控数据采集难度。具体来说，Micrometer提供了OkHttpMetricsEventListener组件，用于收集Okhttp监控数据。我们只需要在构建Okhttp实例时传入OkHttpMetricsEventListener实例即可；我们也可以传入一个EventListener.Factory实例，在工厂创建方法中返回OkHttpMetricsEventListener实例。Okhttp官方在3.11.0版本加入了EventListener功能，所以使用时需要注意Okhttp的版本。通过第三方接口监控这个维度，我们可以方便的将自己的服务和我们使用的第三方服务关联起来，统一展示使用了哪些第三方服务接口，这些第三方服务的响应时间和成功率。方服务接口率是多少。当服务出现异常时，对于定位问题很有帮助；同时，一些内部服务在监控告警方面可能还不够全面，第三方监控也可以帮助他们提升服务质量。4、基于文件的服务发现Prometheus采用的Pull模型需要知道哪些是需要监控的目标对象。Prometheus中有两种类型的配置监控目标：静态和动态。常用的有静态文件配置、文件服务发现、Consul服务发现等。此外，Prometheus还支持DNS、MicrosoftAzure、AmazonEC2、GoogleGCE、Kubernetes等服务发现方式。静态配置是最简单的方式，但在实际生产环境中不可取。容器每时每刻都可能被创建和销毁，无法通过静态配置来设置监控目标。我们首先选择了Consul的服务发现，它引入了中心化的注册中心。微服务启动时，会向注册中心注册一个服务实例，Prometheus可以从注册中心查询服务实例作为监控目标。但是，我们最终没有采用Consul。主要有两个原因：首先，微服务访问Consul需要修改代码。单独部署和维护一个Consul环境会带来新的维护成本。Prometheus服务发现的原理非常简单。Prometheus通过第三方提供的接口查询需要监控的目标列表，然后轮换监控目标获取监控数据。由于QAE是一个私有云平台，Prometheus不能直接提供支持，但是基于以上原则，我们可以实现类似的服务发现机制。我们开发了基于文件的服务发现prom-sd-qae。prom-sd-qae是部署在Prometheus服务所在机器上的独立程序。它通过QAE平台的HTTP接口定时抓取容器服务列表，并按照Prometheus要求的格式在本地磁盘上生成一个JSON或YAML文件，定义了所有监控目标的列表。Prometheus定时从文件中读取最新的监控目标，并从中拉取监控数据。该方案中，监控目标的销毁和创建可能发生在两个刷新的监控目标之间，此时存在短期过期的监控目标；但是，这个解决方案考虑到了服务发现的动态性和简单性，仍然是一个简单有效的选择。5.统一告警Prometheus允许基于PromQL定义告警的触发条件。Prometheus定期计算PromQL，当满足条件时，向Alertmanager发送告警信息。在配置告警规则时，我们为一个分组下的每个服务定义告警规则，每个分组定义多个告警规则，包括：响应时间告警、接口成功率告警、QPS告警、第三方接口告警等。这是将告警规则在服务维度聚合在一起，更方便查看和配置；另外，同一个告警规则下不同业务的告警阈值可能不同，也可以独立配置。下图是一个告警规则的例子：Alertmanager收到告警后，可以对告警进行分组、抑制、静音等附加处理，然后路由到不同的接收者。Alertmanager支持多种报警通知方式。除了常用的邮件通知，还支持钉钉、微信等，也支持通过webhook自定义通知方式。爱奇艺统一报警平台实现报警主题、报警内容、报警通道、报警订阅的统一处理。我们充分利用统一报警平台，开发了Alert-proxy报警代理服务。Alertmanager通过webhook将告警发送给Alert-proxy，再由Alert-proxy投递到统一告警平台，最后发送到热聊、邮件、短信等接收端。Alert-proxy将告警投递到统一告警平台默认的告警topic主题，也支持投递到其他topic。可以针对不同的业务、不同的告警级别分别设置主题，实现更精准的通知触达和聚焦。告警涵盖服务HTTP接口、第三方HTTP接口，还包括JVM和容器的状态，目前基本满足需求。写在最后监控是一个老生常谈却又时常新鲜的话题。跟业务特点、技术栈、方案选择有很大关系。不同的角度来看最终的解决方案是不同的。它是一种什么样的方法？最适合，这就是仁者见仁，智者见智，只有适合自己的才是最好的。这篇文章是现阶段微服务监控的一些实践总结。随着业务和技术的不断发展，未来还有很多方面需要不断探索和完善，比如告警规则优化、报表自动化、系统监控智能化等，让监控更加高效。全面、强大、智能，进一步提升服务质量和稳定性，助力业务快速发展。
