背景
过去很长一段时间，我们在监控平台的建设之路上不断的探索与实践，同时监控需求也在随着技术架构、业务规模不断的演变：
从Nagios、Zabbix到Prometheus； 从关系型数据库、非关系型数据库到时序数据库； 从服务器硬件、基础运行状态到应用可用性； 从服务器、网络、中间件、数据库到应用访问链路； 从传统架构到云原生架构；
但最终无论怎样发展，我们运维的核心目标却始终如一，即为业务服务。
问题
监控平台的运行过程中，我们通常面临着以下几个问题：
告警集中泛滥 告警数据分散在各监控子系统 监控和业务分离
其中监控和业务分离一直是我们所忽略的问题，随着架构和业务规模不断发展，一般情况下的多维度监控虽然可以在业务应用可用性方面发挥重要的作用，但是无法做到和业务流程进行有效关联。此时就需要更懂或者更了解业务的相关人员进一步判断，这无疑大大延长了故障时间，严重影响了我们的SLA。
需求
对于上述问题，我们虽然一直践行着多维度监控的理念，从业务架构中收集各种维度的监控指标数据约达20多万条，但都是离散的，无法有效的串联起来帮我们更精准的定位问题。
因此我们对于监控平台又提出了几个新的需求：
监控面向业务流程，让业务流程更好的发挥串联作用； 从无序的监控中，提取不同的业务监控场景； 通过图形+数据+业务流程，为场景提供可视化监控；
总之，我们想要监控更贴近业务流程，通过图形化数据展示能够更直观的定位业务流程中出问题的节点。
解决方案
由于监控平台数据可能存放在各种数据库、ES、Prometheus、Zabbix等多个监控子系统中，因此我们利用Grafana多数据源及丰富的插件等特性来满足图形可视化的需求。既然图形和数据我们都有了，现在只缺少一套完整的业务流程来将它们结合起来，来完成图形化展示的最后一步。
基于以上现状的分析，形成了我们最终的两种解决方案：
Grafana + Diagram Grafana + FlowCharting
其中Grafana对接各种监控子系统，而插件Diagram 或 FlowCharting 则可以根据业务流程生成图形，通过正则匹配从各种数据源中提取数据，从而在图形展示。
Diagram
Diagram通过利用 mermaid.js 库来创建流程图、序列图和甘特图的方法。
可以使用 Mermaid JS 语法定义图表； 公制系列用于为形状/节点的文本或背景着色； 系列的目标或“别名”与图表节点的 ID； 进行比较以找到匹配项，然后将样式应用于形状； 组合可用于聚合单个节点的多个系列，每个系列都有自定义阈值；
其中组合是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虽然在功能上满足了我们的需求，但是在细节方面还是有不足：
Diagram对于简单图形展示比较友好，一旦我们的业务流程复杂，随着关键业务节点增多，会导致图形无法放大展示，导致整个图形无法查看； mermaid 虽然绘图简单，一旦业务发生变更，还是有一定维护工作量的且非常不友好； 阈值是全局的，无法针对每个metric设置单独的阈值；
FlowCharting
FlowCharting可显示复杂的图表，需借助在线图形库 draw.io 来创建多种类型的图表：
技术架构架构（Legacy、Cloud、Azure、AWS、GCP、Kubernetes、Terraform） 图表（网络、电力、流量） 工业过程 有机计划 平面图 UML 计划 工作流（Jenkins、Ansible Tower、OpenShift）
FlowChating可提供实时数据并在流程图中定义数据与图形进行交互，具体功能如下：
监控状态和性能； 与图表交互； 根据数据或状态更改显示的对象； 添加指向对象的链接； 充分利用变量来修改形状、颜色、链接、下载路径等； 支持匹配和替换的正则表达式；
通过Draw绘出的网络拓扑图，结合FlowCharting的数据交互，进行下图展示：
与Diagram相比，Draw能够更方面的按业务流程进行绘图并方便维护，而FlowCharting则能够灵活的对各个metric设置阈值。
遗憾
Diagram、FlowCharting都可以非常全面的满足我们对于图形+数据+业务流程的可视化监控，但是在使用前需要我们做好以下两点工作：
源数据的完整性 这意味着我们仍要持续的进行多维度的监控指标的收集，不断丰富业务流程对关键指标的依赖。
多数据源无法集中合并展示 受限于Grafana的Dashboard的数据源单一性，即无法在一个Dashboard中关联多个数据源进行集中展示。
以上第一点是一个长期性的工作，也是一个非常重要的基础性工作；而第二点还需要我们持续探索，找到突破点。
总结
有了这套解决方案后，剩下的问题就在于我们要了解、熟悉业务流程，这可不是一件简单的事情，需要我们在日常工作中与业务、开发、测试多沟通、多总结，还要兼顾到业务流程变更等各个环节。只有了解业务，才能更好的为业务服务。
通过不断的梳理和完成，我们就可以图形化展示各种业务流程，不仅能够更快的定位问题，其直观的可视化展示更可以帮助团队相关人员更快的上手并适应工作，对团队的发展进步非常有帮助。
想到此，我不禁觉得可视化业务流程监控，不仅是解决方案，更是我们最终的运维之道！