运维、监控、AIOps的几个重要观点

监控是整个运维乃至整个产品生命周期中最重要的一环，通过配置合理的告警机制，采集准确的监控指标，来提前或者尽早发现问题，解决问题，进而保证产品的稳定，提升用户的体验。『分布式实验室』特约记者艾尔斯兰（下文称艾尔）采访了Nightingale核心开发者秦晓辉，就什么推动监控系统更新，可观测性三大模块怎么关联，以及Nightingale的定位做了交流。

Nightingale是一款先进的开源云原生监控分析系统，采用All-In-One的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。

艾尔：过去10多年以来，比如Zabbix、Open-Falcon、Prometheus、Nightingale等主流使用的监控系统一步一步变化和发展，作为监控领域资深开发者，你认为行业内的哪些变化在推动着监控系统或着运维支撑平台的迭代和更新？

秦晓辉：行业内最大的变化，有这么几点：

指标数量大幅增长：微服务的流行，要监控的服务数量大幅增长，是之前指标数量十倍都不止，而广大研发工程师，也越来越重视应用可观测性的能力建设，更愿意在服务中埋点

指标生命周期变短：云原生的流行，让容器创建、销毁变得非常频繁，原来的物理机、虚拟机时代，监控系统更多的是资产管理视角来看待监控对象，云原生之后，资产视角已经不合适

指标维度更为丰富：老一代监控系统更多的是关注机器、交换机、中间件的监控，每个监控对象用一个唯一标识来区分，没有指标维度的设计，而现在，按照不同维度的聚合已经成为基本需求，每个指标动辄几个、十几个标签

所以，对时序库的要求一下子拔高了很多，产品体验上，也逐渐从资产管理式的监控过渡到了关注应用和业务，引入了灵活的查询聚合语法，确实是一个长足进步。

艾尔：当系统出现问题的时候为了快速定位，我们往往需要不同维度的监控数据按照时间轴垂直关联，Nightingale后续版本有没有相关功能考虑？

秦晓辉：按照时间轴垂直关联，现在的Nightingale版本已经支持了，我们提供两种视图：一个是监控大盘，一个是快捷视图，可以选择某个时间段，查看这个时间段内多个指标，便于排查定位问题。另外，我们还在活跃告警方面，提供了聚合视图，不但可以基于时间轴聚合，也支持自定义聚合标签，比如查看最近1小时内所有云平台的、Ceph产品线的活跃告警事件，算是Nightingale的一个小创新。

艾尔：系统可观测行方面，监控指标/日志/链路跟踪是三大不同模块，为了达到更好了解系统现状和定位问题，我们往往需要这三模块数据相互关联，您在过去工作当中怎么解决相关问题？以及Nightingale有没有考虑相关工作？

秦晓辉：这个问题非常好，可观测性三大支柱，指标/日志/链路追踪，如何做关联，整体来看，典型的手段有三个，一个是时间维度的关联，一个是标签维度的关联，最后一个是数据层面的关联。

时间维度的关联，大家比较容易理解，每一条指标、日志、链路信息，上报的时候都带上时间戳，那我们就可以查看某一时刻相关的数据了。

标签维度的关联，是重点，即为不同的数据附上相同的标签，通常需要在采集器上做。比如我司（快猫星云，我们近期创业的公司）近期开源了一款采集器：Categraf，其目标就是all-in-one，既可以采集指标、日志，也可以接收链路追踪数据，数据都是从一个采集器上流经。

故而，采集器就可以自动附上一些通用指标，最典型的就是所在机器的标识，作为标签附到监控数据上，当然，用户也可以自定义标签，比如监控Tomcat、Categraf既可以采集Tomcat的指标，也可以采集Tomcat的日志，我们可以为这两类Tomcat数据都附上source=tomcat，service=svr-xx，region=idc-yy的标签，未来就可以通过这些标签做到关联查询。

至于数据层面的关联，典型的是TraceID，链路追踪数据都会有一个TraceID，日志中也可以打印TraceID，这样未来查询的时候，就可以用一条TraceID关联查询到相关的所有span和日志。

艾尔：运维人员负责系统日常运维和维护，但是运维人员工作量和成果怎么量化一直是个难点，从运维支撑平台的角度出发，在系统层面上有哪些更有效量化运维人员产出的设计和方法？

秦晓辉：运维人员也有多个不同的工作方向，这里拿两个方向举例，一个是稳定性建设，一个是日常事务性支撑。

首先说稳定性建设，从平台角度来看，既可以管理稳定性目标，也可以量化稳定性建设过程，比如我们可以建立SLO度量平台，来度量各个产品的SLO达成情况，定义SLO相关的SLI，并在平台上自动计算SLI和SLO数据，这些数据优秀，就表示相关人员的稳定性建设有成效。

对于稳定性建设过程，我们也可以建立平台来度量和辅助。比如监控规则配置的是否完备、告警事件是否过多、上线过程是否严格遵从军规、预案是否定期做了演练、预案是否在每次故障中都发挥了作用（即预案有效率）等等。

之前在前司我们做的类似平台称为健康分度量系统，有监控健康分、预案健康分、变更健康分等，各产品线有榜单，以此督促推进各产品线改造。分数的高低，一定程度上是可以说明相关人员的工作量和有效程度的。

另一个是日常事务性支撑工作，可以建设工作台工单类的系统，张三今年总共处理了多少工单，每个工单的50分位处理时长是多少，需求方的满意度评价分数是多少，重复类工作的时长是否在逐渐变短（比如通过建立工具来缩减），自动化工单的占比是否在逐步提高等等，均可以在这么一个平台上量化。

艾尔：告警灵敏度和噪音一直是比较严重的问题，告警噪音不但增加无效的运维工作同时也会干扰有效运维工作的顺利进行，在真实工作环境中怎么找到一个运维工作压力和系统可靠性之间的平衡点？

秦晓辉：这里有几个手段可以多管齐下。

一是告警分级管理，定义北极星指标（这是最重要的手段之一，我们甚至专门做了一个管理北极星指标的产品），所谓的北极星指标，是反映业务健康度的最重要指标，通常和营收挂钩，和终端用户的关键体验挂钩。

比如交易类的系统，订单量就是一个典型的北极星指标，这类指标是公司管理层最关注的指标，可以看做是实时BI数据，需要高优保障。而某个机器的CPU飙高了，可能也是个告警事件，但是未必会对北极星指标造成影响，特别是现在微服务多实例部署，某个实例有问题，通常不会对整体服务有影响，这类的告警就是低优告警，可以无需太过紧张，放到工作队列中逐步处理即可。

其次要有最佳实践和量化手段，最佳实践是有方法论可以参考的，比如Google提出的四个黄金指标，USE和RED原则，可以指导我们重点关注什么样的指标，给什么样的指标配置告警。而量化手段，上一个问题的回复中已有提及，我们得知道哪些告警发的最多，哪些人收的最多，哪些告警规则里没有关联预案链接，逐步的去治理，当然，最好能写入相关人员的KPI，推动起来会更为容易。

艾尔：Nightingale的定位可不可以理解为prometheus-stack的统一WebUI，解决Prometheus/Alertmanager/Grafana比较割裂并易用性较低的问题。可能是因为从性能和功能角度考虑，目前个人感觉Nightingale整体架构比较复杂，后续有没有针对中小企业小规模测试环境或针对个人开发者的简化版本，保留UI易用功能的同时架构上简化降低部署和后续运维成本相关的计划？

秦晓辉：Nightingale的定位，姑且可以看做是Prometheus的企业级版本，假设有个团队，自己搭建了一套Prometheus，给自己团队的几个人来用，用Prometheus+Grafana+AlertManager，其实是够用的（当然，这里暂不考虑团队里的这几个人的学习成本）。

那如果这个团队想要建立更大的影响力，想要把这套监控能力推广到全公司，就需要有一套有权限管理的UI，毕竟不能让每个人都来修改yaml文件。而Nightingale不但提供了这个Ul，还有很多附加能力，比如更多告警规则的特性、告警自愈贯通、告警事件的聚合查看视图、历史存档、新增一些除了大盘之外的快速查看视角等等。

另外，我们近期也推出了采集器Categraf，和Nightingale无缝集成，在采集器上落地最佳实践和经验沉淀，在Nightingale里内置告警规则、监控大盘等，省去大家去网络上各种查找的精力，欢迎大家一起来共建，功在当代，利在千秋。

对于架构复杂度的问题，可能是受到了我们官方文档的架构图的影响，哈哈。实际上，那个架构图是画的最复杂的情况，如果只是小规模使用，可以部署单机版本，只需要部署n9e-server和n9e-webapi两个模块，以及依赖的相关开源组件即可。我们提供了docker-compose方式帮助大家一键部署，也提供了依赖的开源组件的一键部署脚本，欢迎大家尝试。当然，我们也会持续优化，争取在未来继续降低部署复杂度，让个人开发者也能轻松尝试。

艾尔：AIOps作为多年前提出来的新概念，但是业界一直没有比较成功的实际生产场景中落地的案例，您觉得主要问题出现在什么地方？您如何看AIOps的未来发展前景？

秦晓辉：这也是一个好问题，我说一下个人理解，AIOps是很有前景的，但是有两个前提，一个是建立完备、规范的数据，二是找到合适的场景。有些人说要用AIOps干掉现在的运维人员，这无疑是天方夜谭。

我们现在创立的公司，做了很多帮助用户建立完备的监控数据体系的事情，坦白讲，在当下的国内环境，绝大部分公司，都没有很完备的监控数据，比如上面提到的北极星实时BI指标，大部分公司就没有，而如果没有完备的数据，又何谈AI？其次是数据没有规范，没有贯通，即：从源头上来看，没有良好的用于训练算法的物料，所以也就不会有很好的AI的效果。

第二点是场景，目前来看，AIOps在智能告警这个场景，是相对成熟有效的，如果大家想要尝试AIOps，建议从这点开始切入。刚才我们讲到数据的建立其实现在各个公司做的并不好，为什么却说智能告警又相对成熟有效，这是因为，智能告警依赖的数据是相对完备的。

很多用统计学算法来告警的做法，都是针对单个series（监控时间线，就是监控大盘上的一条折线图表示的监控数据），没有额外的依赖，所以这个路子是可以走通的，前几天我们做了一场直播，讲解了如何在Nightingale中开启智能告警的能力，就是因为我们自己实践觉得效果还是不错的。

嘉宾介绍：

秦晓辉，山东人，毕业于山东大学，Open-Falcon、Nightingale、Categraf核心研发，快猫星云联合创始人。

特约记者：

艾尔斯兰，17年北京大学计算机科学技术专业毕业，目前任职商汤科技资深开发工程师，毕业后一直在从事云原生相关工作。

运维、监控、AIOps的几个重要观点相关推荐

运维监控系统实战笔记(day3)
内容来自"极客时间" 架构概述:一个监控系统的典型架构是什么样的? 监控系统的典型架构: 秦老师把本节的内容总结得很好,现摘抄如下: 采集器:用于收集监控数据,业界有不少开源解决方 ...
Open-falcon运维监控系统——微信接口二次开发
1.Open-falcon运维监控系统简介 OpenFalcon是一款由小米运维团队从互联网公司的需求出发, 根据多年的运维经验,结合市面上使用的一些运维监控系统的使用经验和反馈,开发的一套企业级.高 ...
企业运维监控平台架构设计与实现
课程介绍本课程主要介绍了企业常见的运维监控平台的构建思路和常用软件,讲述了cacti.nagios.zabbix.ganglia.webnagios等常用监控软件的差异和优劣,并深入介绍了通过gan ...
基于Linux+Nagios+Centreon+Nagvis等构建海量运维监控系统
参考书目:<海量运维监控系统规划与部署基于Linux+Nagios+Centreon+Nagvis等> 付哲著系统环境规划: 基于阿里云centos6.8镜像升级到centos6.9, ...
优化Linux内核参数/etc/sysctl.conf sysctl 《高性能Linux服务器构建实战：运维监控、性能调优与集群应用》...
优化Linux内核参数/etc/sysctl.conf sysctl <高性能Linux服务器构建实战:运维监控.性能调优与集群应用> http://book.51cto.com/ar ...
DataWorks OpenAPI企业开发实战-运维监控大屏
简介:本文将会介绍如何通过使用DataWorks OpenAPI.DataWorks开放元数据.DataWorks开放事件消息三大利器搭建企业自己的DataWorks运维大屏.其中DataWorks ...
Lnmp搭建zabbix运维监控系统
使用目的? 在公司项目中需要做一个日志监控,最开始选择的是efk,但是efk的资料相对较少并且之前对这几个产品都没接触过,使用起来难度.于是选择了zabbix作为项目的运维监控系统. zabbix能做 ...
Lunx运维监控_shark巨菜_基础篇
Lunx运维监控_shark巨菜_基础篇一.监控重要性单单从"监控"两个字来谈,范围之广可以涵盖我们生活的方方面面,我们生活和工作中处处可见视频监控的摄像机:机房中的电压电流监 ...
转：运维监控系统-监控项及指标的梳理
转自: 运维监控系统-监控项及指标的梳理_程序员杂谈-CSDN博客_运维监控指标综合监控功能工具综合监控工具完成对被管对象的集中监控.集中维护和集中管理,被管对象包括网络设备.服务器.PC设备.数据 ...
mongodb 监控权限_运维监控产品分析篇
开源运维监控系统篇 1.zabbix 用户群:85%以上的泛互联网企业. 优点:支持多平台的企业级分布式开源监控软件安装部署简单,多种数据采集插件灵活集成功能强大,可实现复杂多条件告警, 自带画图 ...

运维、监控、AIOps的几个重要观点

运维、监控、AIOps的几个重要观点相关推荐

最新文章

热门文章