本文内容分为3部分，首先简单介绍了美图的业务背景和监控体系，然后是两个美图的监控实践——基于Grafana FlowCharting插件的「监控大盘」实战和基于GrafanaImageRender+企业微信机器人的「图文告警」实战。

这两个监控实战都是非常容易落地的，基本是开箱即用，中间只涉及到非常少量的代码工作。本文除了介绍我们做相关技术选型时的一些考量，同时给出了两个实战完整的“step by step”的操作步骤，对于涉及到的少量代码工作，文中也给出了代码样例。希望这两个案例对于大家做监控大盘和富文本告警的工作可以有所参考。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常的思路就是我们在一张Dashboard中，以业务的维度建立不同层次的Panel，把这个业务相关的各个环节的监控图放到一起，这样业务方在一个页面里去做点击和滚动就可以了，相比前面的方式我们又往前迈了一步。

比如下面的两个样例：

回顾一下上面两个阶段中监控报表的发展：

这个发展路径中，我们都是在试图把(相关联的)监控数据汇总到一个地方，整体的方向是越来越集中的。因为我们的一个诉求是期望可以在更少的页面中去看到更多的信息，以此来辅助我们更好地掌控服务、更快地排查问题。

但其实，上面的这些方式都只是解决了“监控数据集中展示”的问题，我们还有一个更核心的诉求之前是一直没有得到满足的：我们希望看到各个监控数据之间的关联关系。我们希望可以通过各层次、各依赖服务、各资源的监控状态，以及它们之间的关联关系，来辅助业务方构建一个更立体的全局视角。

比如现在服务SLA告警了，我希望一眼看到整个系统中所有关联模块的状态，希望能够知道这个SLA问题(告警)可能是由什么导致的。如果监控系统可以达到这个目标的话，它就可以辅助业务方打造一个全方位的服务感知能力，也可以让问题排查和定位变得更高效。

这个需求类似于「服务链路跟踪」或者「根因定位」，但是这两个领域都是需要大量基础建设和业务适配的，工作量大，推行成本比较高。那我们有没有什么折中的方案，是可以“以较小的代价”来实现(或者部分实现)这个需求呢？接下来，让我们看一下目前在美图推广的一个基于Grafana FlowCharting插件的监控大盘实践，看下这个是否可以给你带来一些参考。

FlowCharting是一款Grafana的插件从名字应该就可以大概了解这款插件的用途。flow，流、数据流；charting，图表。这个插件是基于draw.io在线绘图库的，用draw.io可以完成非常复杂的图表的绘制，比如网络拓扑图、数据流量图、技术架构图等，然后我们可以用FlowCharting为图表中的各个元素绑定动态的数据，从而完成一张动态的图表。

我们借助这个插件完成了“把服务整个请求链路的监控数据汇总到一张图表”的需求，通过这样的图表我们可以一眼看到服务当前状态的全貌。如下图所示，我们把一个服务从「客户端」到「服务端」以及「依赖服务」和「资源服务」的监控数据都汇总到了一起。通过为不同的监控数据设置不同的阀值、配置不同的颜色，可以更直观的看到整个系统的健康状态。

这个方案里各个监控数据之间的逻辑关联性可能不像trace系统中那么紧密，需要人工去梳理服务的监控项、绘制可以体现数据链路及逻辑关系的图标，但是它切实解决了之前我们监控数据逻辑性不够直观的问题。当系统出现问题的时候，我们可以快速的从这张图表中看到各层、各组件及组件之间的链路状态，它切实提高了我们在问题排查中的效率。

对于这个方案的另一点说明：这个插件只是提供了一种数据可视化的方法，前提还是需要先建设有相关的监控数据。如果你面临的场景跟我们是类似的——已经有各类监控数据，但是苦于如何更直观地把监控数据展示出来，那么这款插件一定值得尝试。

首先，我们需要借助draw.io来绘制我们的业务架构图（如图-业务架构图）。

流程图绘制工具可采用以下两种方式：

业务架构图绘制完毕后，我们通过点击【其他】-【编辑绘图】可以看到图形的代码。

我们先将draw.io中的流程图代码粘贴在Source Centent中，粘贴完毕后，我们就可以从Grafana看板中看到绘制好的图形了。

生成好绘制的图形后，我们就可以开始调整看板的基础配置。

我们需要为关键图形元素添加监控数据源。根据需求可以在报表中添加相应的Query语句。

在报表中可以通过添加Rule ，来设置我们图形的展示效果。

如上图所示，Options是用来关联上一步中添加的监控数据源。

Type是用来设置数据源展示的指定单位和类型。

Thresholds用来设置图形展示的颜色变化规则。

Tooltips开启后，将鼠标移动到具体图形上，会自动展示对应监控值一个周期状态，

如下图所示：

Graph Tooltips用来设置弹出图形展示的效果：

我们将具体的图形关联到配置好的Rule中，这样就可以在Grafana看板中看到具体图形的状态颜色了。

Color/Tooltip Mappings颜色映射，图表颜色填充/边框填充等：

Label/Text Mappings: 数值映射， 图表与查询结果的数值填充：

Link Mappings: 链接映射，点击图形可跳转至指定 URL(比如具体监控项的详情页面)。

Event/Animation Mappings: 事件映射。

最后，为所有需要监控的图形创建对应的Rule ，整个业务流程监控大盘就制作完毕了。至此，你将收获一张包含动态监控数据的监控大盘。

这个部分可以算作是上一个实战的延展，经过上面的建设我们已经有了服务级整体的请求流向图后。如果我们可以在服务发生「告警」的时候，同时把「监控大盘」的信息发出来，让我们在收到服务告警的同时可以快速感知服务的整体状态，这将大大提升我们问题排查的效率。

结合目前我们在用的企业IM的群机器人告警通道和Grafana的ImageRender，告警和监控大盘的联动也就水到渠成了。目前美图选用的企业IM是企业微信，我们只需要在服务告警发生的时候，同时将监控大盘的「状态截图」通过企业微信的IM机器人发到各个群组即可。

结合美图已有的监控告警组件，我们选择的告警发送请求链路为Grafana-Image <-> MTAlert -> 企业微信机器人。 

组件说明

告警流程

我们的告警规则是维护在MTAlert中的，当告警发生的时候我们将告警消息发给一个指定的脚本。这个脚本负责根据约定好的规则做过滤和处理，去GrafanaImageRender渲染图片并获取图片的链接，然后将组合后的图文消息发送给指定的企业微信群机器人。

用这样的方式，我们就可以在一条告警消息中获取到服务本身及上下游的即时状态，从而让我们对问题的原因和影响范围有一个快速的大致判断，进而缩短问题排查时间，降低MTTR(故障平均修复时间)，提升服务的稳定性。

 > [企业微信 - 如何使用群机器人](https://work.weixin.qq.com/help?doc_id=13376)

因告警会包含图片和标题, 使用图文类型消息, 需要发送给Webhook的格式如下: 

调用成功可得到如下的返回值：

为提升扩展脚本的可扩展性, 我们对告警配置中的grafana链接约定了一个固定的格式：grafana链接&&&&&&微信机器人webhook地址&&&&&&报警名称&&&&&&报警描述&&&&&&

告警扩展脚本我们使用了Python，告警扩展会固定调用脚本中的 getExtendData(data) 这个函数，其中 data 为告警平台传送的告警内容。扩展脚本部分代码如下:

以上就是这个实战的全部内容了，其实整个实践的思路还是比较简单和清晰的，大家可以根据自己的环境做些灵活的适配。

基于FlowCharting的大盘实践和信息更丰富的图文告警，相比于传统的监控和告警方式来讲，虽然略新颖，但是基本都还是围绕“工具应用”的层面开展的。这远不是终点，我们还有非常多的事情需要继续去推进，下面是两个较为“清晰”的思路或方向，大家或许可以参考：

再有一个较为前沿，也正在如火如荼开展的方向则是「基于DataOps/AIOps的(监控)实践」。通过大数据、机器学习等新兴技术手段，更好的挖掘监控数据的价值，打造更智能的工具体系，用更科学、更智能的方法来辅助运营和生产。

当然，未来在监控上可以做的事情也远不止这些，我们可以一同努力、共同期待。

本文先介绍了美图的监控体系，然后着重讲解了监控大盘的发展：按照将监控数据尽可能集中汇总的思路，我们逐步把监控数据从多个系统收敛到一个系统，然后我们把多个监控报表整合到一个页面中进行呈现，最后我们用FlowCharting这个插件把监控数据的集中展示做到了“极致”，在一张图表中展示。

同时巧用FlowCharting插件来体现监控数据之间的关联关系，由此我们就可以用它以较低的成本构建出一个「端到端的全链路监控」了。

最后，我们分享的一个基于GrafanaImageRender组件和企业微信群机器人的“图文告警”实战。

PS：目前这套监控大盘和图文告警在美图的应用效果非常不错，感兴趣的同学也可以做一些尝试。

作者丨石鹏、朱起飞、王苑卜