美图全链路监控实战

一. 摘要

本文内容分为3部分，首先简单介绍了美图的业务背景和监控体系，然后是两个美图的监控实践----基于Grafana FlowCharting插件的「监控大盘」实战和基于基于GrafanaImageRender+企业微信机器人的「图文告警」实战。这两个监控实战都是非常容易落地的，基本是开箱即用，中间只涉及到非常少量的代码工作。本文除了介绍我们做相关技术选型时的一些考量，同时给出了两个实战完整的“step by step”的操作步骤，对于涉及到的少量代码工作，文中也给出了代码样例。希望这两个案例对于大家做监控大盘和富文本告警的工作可以有所参考。

二. 美图监控的整体架构

1. 业务背景

在展开技术实战部分的讲解之前，我们先简单了解下美图公司的业务场景和规模。美图公司的业务主要分为 ToC 和 ToB 两类，以「消费者社区」为核心，在「影像美化」、「美妆平台」、「皮肤管理」几个垂直领域均有面向终端用户和面向企业的产品或解决方案。

美图的产品线覆盖社区、美颜、美妆、短视频、直播等领域，比较知名的C端APP有美图秀秀、美颜相机、美妆相机、美拍等。此外，美图拥有大量的海外用户，知名的产品有 BeautyPlus、AirBrush 等。围绕这些 APP 同时建设有大量的支撑服务，比如基础架构、大数据、AI开放平台、商业化生态等。

美图的产品线众多、业务形态丰富、ToC和ToB的服务并存，如何保障众多线上服务的稳定性也就是众多技术同学尤其是SRE同学所面临的挑战。而要保障服务的稳定性，不可或缺的一点就是对服务质量的感知力，也就要求我们建设一套稳定、高效、契合业务的监控系统。美图的监控体系就是建立在前文的场景和规模之下的，下面让我们来深入了解一下。

2. 监控体系

美图的整个监控体系分为「用户端」和「服务端」两大块。

• 「用户端」主要覆盖客户端和中间链路。目前主要基于美图自研的APM(内部代号哈勃)来做客户端的的质量监测，监控的指标有：网络质量、崩溃、卡顿、响应时间、错误率、慢请求等。除此之外，美图还建设有流媒体的监控体系，主要用来覆盖直播推流拉流、点播拉流、CDN质量等。

• 「服务端」的部分涵盖的内容比较多，如果从业务的请求链路来看，服务端的监控会覆盖从「入口层负载均衡」到「业务服务」、到「周边依赖服务」的调用、到「后端资源类服务」等整个请求链路。此外，还有一些基础设施的监控。

因为目前美图的业务已经“全量上云”，我们对基础设施的监控就不再过多关注网络设备、服务器等物理硬件相关的内容了，更多地转向了对云上基础设施的监控，比如网络质量、ECS虚机、容器平台、DNS等基础服务等。

美图整体的监控体系可以参照上图，本图的绘制时间稍微有点早了，但是基本的信息都还是适用的。

美图是从2016年开始推进完善上述监控体系的，在这个过程中我们也调研、测试、引入了众多的技术工具和技术栈：

• Zabbix、OpenFalcon、OpenTSDB 基础监控

• ELKB 日志套件

• InfluxDB 的 TICK 套件

• Prometheus

• Spark、Storm、Kafka、Flink 等大数据套件

• Netdata、Sentry、EagleEye、SkyWalking 等

此外，美图也基于开源的组件做了大量的二次开发的工作，同时也建设了一些诸如通知系统 NoticeSystem、统一告警平台 MTAlert 等工具。

监控体系涉及的内容比较庞杂，无法在一篇文章中做到全面细致的讲解，下面会将更多的篇幅放在「全链路监控报表」的建设思路上，并且会附带一个监控大盘和告警的实战。

3. 监控大盘

a. 统一监控报表查看入口到Grafana

经过上述的建设，已有的监控工具已经可以较好的覆盖从客户端到服务端的各个环节了，这时却有了新的问题：监控系统太多、报表散落在各个系统，业务方排查一个问题可能需要在多个系统之间来回切换，体验非常不好。

这时候我们希望有一个统一的用户界面来展示不同监控系统的数据，我们也做了一些简单的调研。当时我们调研的方案有：自建前端、用iframe简易嵌套组合、Grafana。

自建前端和iframe嵌套的优点都是可以接入更多的监控系统，但是缺点也都比较明显。自建前端是可定制化程度最高的方案，但是需要比较多的适配工作，随着各个监控系统的迭代，平台维护的工作量也是比较可观的；iframe嵌套的方式倒是简单粗暴，但是并没有从本质上解决数据割裂的问题，并且还需要解决不同监控平台之间的用户权限打通的问题。

最终我们选择了Grafana作为统一的监控Dashboard工具，当时考量的点主要有：

• Grafana对我们当时在用的大部分监控系统(数据源)都有支持，比如Zabbix、OpenTSDB、Prometheus、InfluxDB、Elasticsearch

• Grafana是Prometheus官方推荐的展示组件，当时我们已经在大量推进业务侧的Prometheus监控，这个点对我们的决策比较重要

• Grafana的发展很迅猛，社区活跃，有“大一统”之势

于是把原先没有接入到 Grafana 的数据源做了统一的接入，用 Grafana 来提供统一的监控用户界面。

当然，Grafana也有一些问题，比如对一些数据源没有提供支持或者支持不够完美，日志、告警的能力比较弱(现在已经有非常大的改观)等。对于这些问题，我们选择容忍或使用其他方案来配合和覆盖，比如：

• ELK技术栈中的日志细节查看还是需要借助Kibana，Grafana则更合适去呈现Elasticsearch的汇总数据或变化趋势

• Prometheus的PromQL的调试、AlertManager的管理，可能还是原生的UI会更友好

• 监控告警的需求，我们则更多的依赖我们的告警平台MTAlert来做覆盖

考虑到我们的原始需求(统一的监控UI)，目前Grafana是可以满足我们绝大多数日常的监控可视化需求的。

b. 在一张报表(Dashboard)中展示业务链路

在用 Grafana 解决了数据源散落在多个系统的问题之后，业务方可以不用频繁的在多个监控系统之间做切换了。但是由于请求链路中不同阶段的监控图表还是存放在不同位置的，业务方在实际的使用中还是需要在多个Org、Dashboard 或 Panel 中切换。

比如上文提到的典型的请求链路：

业务方期望能有一个全局的视角，可以在一个页面或者图表中体现出这些环节的监控数据，这时候我们可以怎么做呢？

通常的思路就是我们在一张 Dashboard 中，以业务的维度建立不同层次的