从DevOps视角来谈对运维监控平台的需求
对于基于开源工具链来构建DevOps能力支撑平台，我在前面多篇文章都有谈到，从整体研发过程全生命周期来看分为了开发态，运行态和运维态。
在开发态重点是提供一个快速开发或低代码开发平台，同时集成相应的微服务开发框架，封装后端技术组件，前端组件等。而在运维态重点是需要实现持续交付后的应用的在线实时监控和运维。
因此整个DevOps平台需要集成一个外部的运维监控平台，当然在项目实施中，我们本身也集成了Zibbix来实现资源监控，集成Prometheus来实现Kubernetes集群和容器监控，集成ELK来实现日志采集和监控分析，包括集成一些开源的服务链监控工具来实现基础的APM能力等。
那么实际的问题也比较明显，即：
我们往往需要跨多个开源工具或平台，来实现不同层面的监控，预警和运维，同时不同开源工具底层的基础CMDB元数据信息仍然是不能相互共享。
从这个意义上来讲，构建一个一体化的云原生监控运维平台本身是有意义的，即使这个平台本身也是基于底层开源工具进行集成。也正是基于这个原因，最近我们开始和一些监控运维平台解决方案厂家进行技术交流和沟通。
因此这篇文章作为一些关键交流内容的一些总结和记录。
对于监控平台，大部分人的第一印象仍然是类似Zibbix实现的资源层各种硬件基础设施，虚拟机，中间件的各个性能指标的监控能力。
在云原生和DevOps下，整体的需求变化主要体现在如下。
其一是形成覆盖应用-服务-资源三层的全链路监控能力。监控的不仅仅是资源，而是包括了应用和服务。拓扑也不仅仅局限在资源拓扑，而是需要基于应用的逻辑拓扑。
比如当前有一个CRM应用，在逻辑拓扑我们希望快速地看到这个CRM应用对应的负载均衡，中间件集群，数据库，缓存技术服务等各个资源。缓存技术服务可能是整个PaaS平台公有的云平台服务能力，但是无所谓，关键是要看到基于CRM应用视角的完整拓扑。
同时构建应用《---》资源间的双向追溯链条。即应用监控到问题，可以快速的定位到具体的资源或技术服务，而资源出现问题也可以快速的分析影响到哪些业务系统。这个在传统的资源监控和CMDB配置库定义中是不包含了，而现在需要包含。
其二是实现云原生下的和DevOps平台，容器云的集成和协同能力。即监控的最小单元已经从虚拟机变成了Kubernetes集群和容器。
传统的监控物理机和虚拟机往往是固定的，因此很容易在资源上面安装各种Agent插件来实现性能数据采集。而云原生下容器本身是动态变化的，而是存在容器逃逸现象。因此更加需要监控插件等能力在通过Kubernetes动态创建和部署容器的时候自动下发。类似Prometheus的Exporter插件，我们可以在容器实例自动化创建和部署的时候动态下发。
整个监控能力对于应用开发者来说完全是黑盒不可见，这些能力类似Mesh网格方式，都是在后续CI/CD过程中动态增加进去的。
其三是一体化监控平台。简单来说底层可以集成多种监控，日志采集，服务链等工具，但是前台是要提供一体化的监控运维能力。这个一体化又包含了几个关键的内容：
首先是共享一套CMDB配置元数据，这个配置信息不仅仅是资源层元数据，还包括了服务层和应用层元数据，同时能够构建应用-服务-资源间的关联映射关系。实现前面谈到的能够从单独的应用视角快速地看到逻辑拓扑架构。
其次是上层的管理平台各个能力之间要打通。比如你服务链路追踪的时候用的SkyWalking的能力，但是能够快速的赚取到具体的中间件服务或资源上面。再比如APM里面常谈到的，当应用某个功能出现性能问题的时候，你能够快速的追溯到具体的出问题的资源，或者具体的错误日志上面。
下面进一步基于业务场景来分析下详细的关键需求点。
1.实时监控告警
这个重点是在告警规则的定义，主要告警规则可以是多个KPI指标的组合规则，同时KPI指标本身还要支持灵活的单位时间间隔定义。比如在CPU利用率持续5分钟高于90%等。一个简单的组合规则如下：
在CPU利用率持续5分钟>90% And JVM内存利用率持续5分钟>80%
告警本身支持邮件，短信，微信等各种实时通知方式。同时告警本身有等级，对于严重告警需要和ITSM的事件管理做集成，即触发一条事件或问题工单。
2.快速故障定位
传统的IT网管或监控平台实际上资源运维和应用运维两个角色是完全分离的。运维人员只需要关心硬件资源是否有故障，而并不关心性能是否有问题。资源本身是有问题的，具体问题定位也是应用开发人员来处理。
简单来说应用运维和资源运维是分离的。
在前面很多DevOps文章我都谈到一个关键点，以后高学历的资源运维人员逐步会被自动化技术全部替代。而真正需要的是应用运维人员。
即通过应用发现的故障或性能问题能够快速的追溯并定位到具体的资源，并根据错误日志信息等快速的进行资源恢复。或者说通过资源故障能够快速的进行影响分析，确定相关的影响面和恢复方法。
也正是这个原因，监控运维平台必须集成日志监控能力，或者集成ELK等开源日志监控工具等。在DevOps和容器化下日志是一个关键内容，两个原因。
其一是容器本身生命周期是动态的，日志不能存储在容器内，而是应该单独集中化存储，因此在容器存活状态下需要快速采集日志并进行存储。其二是任何故障或问题的定义，都涉及到需要基于关键字快速地查询和分析日志，这个也不适合不断地来回切换管理工具来进行。
集成日志能力并不复杂，但是当前一些监控运维平台往往并没有将该点作为一个关键需求进行处理，略感意外。
3.和纳管资源的松耦合
注意当整个容器云平台和监控运维平台进行集成的时候，必须是一种松耦合的关系。包括性能指标采集和监控，在前面也谈到侵入式和非侵入式两种模式。
在APM层面，往往存在一定的侵入式方式，比如安装Agent代理，或者在JVM启动的时候需要启动监控代理服务等。而对于资源层的监控，最好是做到完全无侵入方式。
如果是一种侵入方式。
那么这个过程对于应用程序开发者来说也应该完全透明不可见，即在DevOps进行自动化部署的时候进行代理的下发和采集程序的植入。类似前面谈到的用Prometheus进行容器集群监控，那么Exporter插件本身也应该在DevOps的CI/CD过程中自动化完成。
4.是否一定要覆盖APM和服务链路监控能力
简单来讲，一体化监控运维平台如果能够覆盖APM和服务链路监控能力是最佳的，即真正实现了完整的从应用层到服务，到资源的全链路追溯能力。但是当前做运维监控的厂商很少将APM做得很完善，同样APM的厂商一般也需要去集成另外的IT资源监控工具。
如果集成APM，那么也完全可以做到在DevOps过程中自动化下发或启动代理插件。但是这种方式本身对应用的侵入，容易导致后续应用开发和运维边界不清或扯皮的情况发生。
我们举个简单场景说明下。
比如当用户反馈CRM系统的客户订单提交功能很慢，基于APM思路实际可以快速的追溯到这个提交功能经过了哪些微服务，或调用了哪些API服务接口。即快速的定义到具体是哪里慢，比如发现是数据库Sql操作很慢。
这个时候就需要快速地进入到对应的数据库资源，先分析判断当前数据库资源本身负荷是否正常，比如CPU利用率，内存负荷等。同时还需要提供日志采集功能，能够看到具体的Sql语句写作进行问题分析。
也就是或应用，服务，资源三者之间存在勾稽关系并相互影响。
通过分析你可能会发现实际是数据库在运行一个大数据量处理的Job程序，导致了资源利用率上升而影响到CRM业务操作。当然也可能是SQL本身查询就慢，需要进行Sql语句的优化等。如果从服务链路分析角度，你还可能发现并不是订单提交功能本身慢，而是该功能调用了外部的一个预算检查API接口，这调用这个API接口导致了大量的时间消耗。
不管是以上哪种分析，都需要应用，服务和资源三者之间的联动，同时从简单的API性能指标监控到最终的日志采集和分析，才能够完成整个分析和故障定位过程。
如果到AIOps层面，那么至少还需要实现监控运维平台能够自动帮助你分析和定位问题，比如给出最可能的三个原因，按优先级排序。你只需要进行验证和确认即可。
