运维之道——可视化业务流程监控

背景

过去很长一段时间，我们在监控平台的建设之路上不断的探索与实践，同时监控需求也在随着技术架构、业务规模不断的演变：

但最终无论怎样发展，我们运维的核心目标却始终如一，即为业务服务。

问题

监控平台的运行过程中，我们通常面临着以下几个问题：

其中监控和业务分离一直是我们所忽略的问题，随着架构和业务规模不断发展，一般情况下的多维度监控虽然可以在业务应用可用性方面发挥重要的作用，但是无法做到和业务流程进行有效关联。此时就需要更懂或者更了解业务的相关人员进一步判断，这无疑大大延长了故障时间，严重影响了我们的SLA。

需求

对于上述问题，我们虽然一直践行着多维度监控的理念，从业务架构中收集各种维度的监控指标数据约达20多万条，但都是离散的，无法有效的串联起来帮我们更精准的定位问题。

因此我们对于监控平台又提出了几个新的需求：

总之，我们想要监控更贴近业务流程，通过图形化数据展示能够更直观的定位业务流程中出问题的节点。

解决方案

由于监控平台数据可能存放在各种数据库、ES、Prometheus、Zabbix等多个监控子系统中，因此我们利用Grafana多数据源及丰富的插件等特性来满足图形可视化的需求。既然图形和数据我们都有了，现在只缺少一套完整的业务流程来将它们结合起来，来完成图形化展示的最后一步。

基于以上现状的分析，形成了我们最终的两种解决方案：

其中Grafana对接各种监控子系统，而插件Diagram 或 FlowCharting 则可以根据业务流程生成图形，通过正则匹配从各种数据源中提取数据，从而在图形展示。

Diagram

Diagram通过利用 mermaid.js 库来创建流程图、序列图和甘特图的方法。

其中组合是Diagram比较亮眼的功能，通过聚合多个metric，可以很清晰的展示出哪个节点出现问题。

根据我们的实际业务流程，我们可以通过mermaid进行绘图

graph LR      LB[Load Balancer] -- route1 --> web1      LB[Load Balancer] --> web2      web1 --> app1(fa:fa-check app1)      web1 ==> app2      web2 ==> app2(fa:fa-ban app2)      web2 --> app1      app1 --> D[(database)]

根据定义的mermaid语法，可生成以下图形：

如图，我们app2是我们定义的一个组合，在业务流程图中作为一个后端服务，其聚合的是app2_1、app2_2、app2_3 三个metric，通过组合可直观地展示此时是app2_1应用超阈值，从而很快的定位问题。

但是通过实际使用，Diagram虽然在功能上满足了我们的需求，但是在细节方面还是有不足：

FlowCharting

FlowCharting可显示复杂的图表，需借助在线图形库 draw.io 来创建多种类型的图表：

FlowChating可提供实时数据并在流程图中定义数据与图形进行交互，具体功能如下：

通过Draw绘出的 络拓扑图，结合FlowCharting的数据交互，进行下图展示：

与Diagram相比，Draw能够更方面的按业务流程进行绘图并方便维护，而FlowCharting则能够灵活的对各个metric设置阈值。

遗憾

Diagram、FlowCharting都可以非常全面的满足我们对于图形+数据+业务流程的可视化监控，但是在使用前需要我们做好以下两点工作：

以上第一点是一个长期性的工作，也是一个非常重要的基础性工作；而第二点还需要我们持续探索，找到突破点。

总结

有了这套解决方案后，剩下的问题就在于我们要了解、熟悉业务流程，这可不是一件简单的事情，需要我们在日常工作中与业务、开发、测试多沟通、多总结，还要兼顾到业务流程变更等各个环节。只有了解业务，才能更好地为业务服务。

通过不断的梳理和完成，我们就可以图形化展示各种业务流程，不仅能够更快的定位问题，其直观的可视化展示更可以帮助团队相关人员更快的上手并适应工作，对团队的发展进步非常有帮助。