共计 4380 个字符，预计需要花费 11 分钟才能阅读完成。
监控是整个运维乃至整个产品生命周期中最重要的一环，通过配置正当的告警机制，采集精确的监控指标，来提前或者尽早发现问题，解决问题，进而保障产品的稳固，晋升用户的体验。『分布式实验室』特约记者艾尔斯兰（下文称艾尔）采访了 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 年北京大学计算机科学技术业余毕业，目前任职商汤科技资深开发工程师，毕业后始终在从事云原生相干工作。