运维咖啡吧

追求技术的道路上,我从不曾停下脚步

多云监控告警系统的优势

前一篇文章基于多云构建监控告警系统讲了我们是如何构建多云监控告警的,监控告警系统的基础数据来源于云上,也就是说我们监控系统里所有用到的基础数据云上都有,既然如此,为什么不直接去云控制台上查看,而是要构建自己的监控告警系统呢?这篇文章我们就来聊下这个话题

之所以会基于多云构建我们自己的监控告警系统,有两个大的前提,其一是我们接入的云厂商比较多,同时单个云厂商下还会有多个不同的账号存在,云上资源就分布在众多不同的云账号下,其二就是因为业务关系我们绝大部分监控都直接使用了云厂商提供的云监控。根据个人的使用体验以及对同事们使用多云的观察和反馈来看,个人觉得我们自研的多云监控系统至少具有如下几点优势:统一平台、简化操作、优化展示、权限隔离、多云融合

统一平台

在全球化的业务背景下,我们使用了多个云厂商的资源,同一云厂商还有多个不同地区/功能/项目区分的账号,监控查看往往需要在不同云平台不同云账号之间来回切换,繁琐且麻烦。我看到小伙伴们想要同时查看同一云平台多个不同云账号上的资源监控情况,会同时打开多个不同的浏览器,为此还专门安装了几个不同的浏览器,而我们统一了监控平台之后,就不需要再登录云控制台去查看监控了,也就不存在多个账号切换的情况,更不需要再开多个浏览器了,一个系统查看所有资源监控情况,这带来了极大的方便

同样的,对于告警信息我们也做到了统一,将多云告警集中在统一的系统里做展示,告警大盘可以清晰的看到当前系统的整体运行状况,增强运维对项目的整体把控能力。对于告警,不仅能够查看告警信息,还能查看和修改告警策略,项目维护流程也更加简单高效

简化操作

云上监控位于不同云平台下,我们知道每个云平台对于监控的定义和操作都不同,甚至是同一云平台下不同云服务之间监控的查看路径和展示方式都不同,且云资源监控查看路径冗长,非常不便。我们的监控系统隐藏了云厂商与云资源的监控差异,同时简化资源监控查看操作,提供统一的监控入口和路径,使用起来更方便。以一个云主机的监控查询为例,可以简单对比下之前通过云控制台查看与现在通过我们自己的监控系统查看之间的差异

我们的监控系统操作步骤数,以及每一步所使用的时间都要优于云上监控,提升使用便捷性

优化展示

云上资源监控图表样式杂乱,不同云厂商不同云资源的监控图表展示样式都不统一,这些不统一不仅存在不同云厂商之间,甚至是统一云厂商的不同云资源之间图表展示样式都不一样,我们不仅对监控的查看路径做了优化,也对监控图表的样式做到了统一

不仅统一了图表展示样式,图表的检索方式也做到了统一,展示顺序也做了优化,大家普遍关注的重点指标靠前放,一屏之内重要指标的变化情况尽收眼底,同时页面与图表的加载速度也做了优化,云上监控页面复杂,动辄上百个请求,而我们除了并发加载外,仅加载必要的资源,做到了最小化请求,图表展示速度甚至比直接控制台查看还要快

权限隔离

云平台上的权限配置非常复杂,对于细粒度的资源权限隔离几乎无从下手,而我们的业务又比较复杂,所运维的项目不仅可能来自于不同的部门,甚至还有可能来自于不同的公司,所以云控制台的权限是不授权给研发,这就造成了一旦研发需要查询云上资源的监控,就需要运维在中间支持。我们的监控系统天生的支持以项目为维度进行资源隔离,授权粒度也比较灵活,可以直接授权给研发自己查看,这样大大提升了沟通效率,加速了问题的处理

以一次复杂问题的排查为例,通过我们的监控系统大大降低了沟通成本,加快了问题的修复速度

多云融合

以上说的几点优势,很大程度上都依赖我们监控系统与多云系统的深度融合,这也是我们自研监控系统的最大优势,多云+监控几乎是天生一对,多云为监控提供基础数据,监控为多云提供最重要的应用场景。借助于多云可以方便的以项目为维度查找资源的监控数据,而无需再考虑资源位于哪个云厂商的哪个云账号下,这样复杂的多云也变得透明。同时在告警中,借助与多云系统也可以直接定位告警资源所属的项目,加快告警的响应速度

更为重要的是借助于多云系统的服务树,可以方便快速的自动生成以项目服务/角色为维度的监控大盘,而无需再在云上进行繁琐的监控Dashboard配置。监控大盘下的资源也会随着云资源的生命周期变动而自动变更,使用非常方便,以往可能需要至少数小时的监控Dashboard配置,通过监控系统也就分分钟生成

基于多云和监控的融合,很方便的生成监控报表,为项目日常运营也提供了重要的支持,或许正是得益于方便的监控大盘构建,查看项目监控大盘已然成为很多小伙伴的习惯,真的做成了有用又好用的系统