Open-falcon在汽车之家的应用与实践

总篇125篇 2021年第16篇前言本文主要讲述了小米的监控系统open-falcon在之家的应用和实践，通过本文可以了解到open-falcon在之家的应用场景与改进过程，给与广大读友们类似需求的一些解决思路。Open-falcon在汽车之家的应用与实践基础监控方案对比监控系统是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供详实的数据用于追查定位问题，这一点对于公司的研发体系来说至关重要。监控系统业界有很多杰出的开源监控系统。早期很多公司一直使用zabbix，不过随着业务的快速发展，以及互联网公司特有的一些需求，zabbix系统在性能、扩展性、和用户的使用效率方面，已经无法支撑了。之家从互联网公司的需求出发，从SRE、SA、DEVS的使用经验和反馈出发，对比了业界一些成熟主流的开源基础监控方案：安装复杂度数据采集支持数据储存难度告警支持Zabbix中低高高Prometheuss低高高中Open-falcon高中低中对比三种监控数据的各个特征指标，能够得出结论open-falcon不是功能最强大的，但是是使用最简单便捷的。特别是数据存储方面不用担心数据量一直增加而出现的磁盘问题，节省运维成本。同时考虑目前公司的服务器规模，功能需求不复杂以及可能需要的告警扩展，open-falcon都能够满足需求。OpenFalcon的架构概述OpenFalcon是由小米的运维团队开源的一款企业级、高可用、可扩展的开源监控解决方案，在众多开源爱好者的支持下，功能越来越丰富，文档更加的完善，OpenFalcon已经成为国内最流行的监控系统之一。Openfalcon是采取了前后端分离的架构，后端用Go语言开发，前端用Python开发。编译后的后端程序运行时，不再需要Go语言环境，直接将可执行文件拷贝到某台机器上面运行就可以了，而前端是需要python环境。当机器数量比较大的时候，一般会预先将Agent安装到机器上(物理机标准化装机时安装，虚拟机可以封装到镜像中，私有云或者公有云都支持主要都是网络问题)。当Agent运行时就会上报数据。A) Agent负责数据的采集，比如cpu.idle、load.1min、disk.io.util等等，每隔60秒push给Transfer。agent与Transfer建立了长连接，数据发送速度比较快，agent提供了一个http接口/v1/push用于接收用户手工push的一些数据，然后通过长连接迅速转发给Transfer。agent是需要部署到所有要被监控的机器上，agent本身资源消耗很少，不用担心。小米开源的Agent只包含Linux，汽车之家开源了Windows的Agent?(Windows-Agent)。B) Transfer负责数据的转发。它接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。C) Judge判断是否触发告警，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会把metric上报给judge，metric数据在judge内存中维护。在有metric到来时，根据配置的strategy和expression判断是否触发报警阈值。D) Alarm模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取event，持久化到Mysql，并将event放到Redis的待发送队列或待合并队列。开启goroutine调用对应的接口异步发送。E) Graph是存储绘图数据的组件，接收transfer使用rpc调用上报的监控数据，在内存中维护，同时以rrd文件的形式落盘，同时处理query组件的查询请求、返回绘图数据。F) Query负责数据存储和数据查询；G) HBS负责数据缓存，增加其他系统的调用速度；H) Dashboard是面向用户的查询界面。在这里，用户可以看到push到graph中的所有数据，并查看其趋势图。我们做了什么？原生的open-falcon监控的数据大多以列表的形式进行数据管理，并且并没有与资产管理系统打通。为了适应护航平台新的CMDB系统，支持对服务数据进行监控和告警。我们对open-falcon做了二次开发，实现基于服务树的动态监控系统。我们重写了dashboard和hbs组件,融入护航系统平台，使监控对象来源于CMDB的服务树，目的是资产和监控数据打通，方便监控维护和告警配置，不用人为维护主机组和配置告警模板，减少人为数据干预，更加能保证数据的准确性。并且基于树结构管理监控模板，便于对监控继承和独立快速配置。基于服务树的动态监控模板管理：1) 基于服务树，动态管理服务监控数据，模板支持继承和独立两种方式。树节点的增减，服务节点自动向上寻找待绑定的模板。新创建的模板自动继承父模板的告警策略，订阅配置和插件路径。2）告警对象不再是基于服务器，而是可以基于服务也可以基于主机，甚至容器的节点。增强了监控对象的范围。我们公司会有这样的场景，一个节点下的机器，不同的监控项会有不同的关注者，通用的监控指标和特殊的指标在触发告警的时候需要通知不通的关注人，所以我们开发了支持基于单个告警监控项订阅配置，单个策略项触发告警可以不用通知模板订阅人，而是单独通知策略订阅人，完成在同一个模板下，不同的告警项可以通知到各自的关注人。3）我们开发了监控的自愈功能，打通了我们的另一个产品《场景化运维》，当告警被触发以后，就可以携带着告警对象的信息运行预先设定好的一个场景，一个场景可以包含多个编排好的任务，任务的内容是通过salt运行命令，脚本或者执行callback等方式达到自愈的目的，实现告警-处理的自动化。另外，告警触发以后，在自愈延迟的时间范围内，用户还可以取消本次自愈场景，使告警处理更加灵活。4）一些自定义的插件或者push的数据一般只有在出现异常的时候才会上报信息，基于这个需求，我们每一个的告警项都可以设置nodata的值，方便运维和研发开发相关的告警插件和脚本。但是官方也建议了，不要设置的过多nodata，否则性能会受到影响。5）我们重写了alarm组件，支持公司内部的钉钉、短信、电话等告警方式，对接之家内部的通知接口，报警触达方式多样化，更有效提升维护效率。6) 对告警支持全局屏蔽，支持基于服务树进行告警屏蔽，告警项进行告警屏蔽。还可以根据资产在CMDB的状态进行告警屏蔽，在资产的整个生命周期中，当资产的状态处于非正常状态时，比如装机、下线、重装、报修等等，此时触发的告警并不会通知给告警订阅人，这样在一个资产的整个生命周期内，完全没有人工操作，实现告警的全自动的通知和维护。7) 因为之家机器和系统的种类比较多，open-falcon的agent偶尔出现误报的情况，我们发现通常是由于系统时间错误和服务假死引起的。对于这个问题，我们做了一个通用性的处理：每5分钟做一次巡检和根据巡检结果为失败时进行的自愈，主要是针对系统时间的校验和更正同时进行服务状态的重新启动，此功能上线后，agent连通率有了显著的提高。8) 针对上述组件（除agent外）均做了双活/主备，除了judge,graph和nodata其他所有组件均可以做不同机房的双活部署，这三个组件做了主备切换功能，比如当judge和graph的主机出现问题，无法再提供服务时候，会修改transfer与query组件的配置文件切换到备用judge与graph上，确保监控高可用的自愈能力。未来的预期之家监控依赖于open-falcon-v0.1，上线之后虽然针对服务树、hbs、alarm、nodata等进行了二次开发。但是整体组件已经多年没有升级和更新，下一步可能会考虑将open-falcon升级为nightingale进一步提升查询效率，增加某些模块的故障自动摘除能力。在硬件监控方面，由于服务器机型和种类繁多，带外管理不能完全满足需求。因此还是需要open-falcon提供一些硬件监控功能，虽然现在也提供了一些插件的支持，但是种类单一，一般只有硬盘，内存等少数的几个硬件指标。HWcheck虽然监控的指标种类很多，但受到厂商机型的限制。下一步可能需要跟服务器厂商沟通，自研硬件监控的agent。作者简介张朋汽车之家-智能数据中心负责之家护航运维平台的建设与维护工作，致力于为公司打造自动化运维平台。阅读更多hadoop任务常见的OOM问题及解决方案浅谈WEB漏洞之SQL注入修复实践汽车之家：基于 Flink + Iceberg 的湖仓一体架构实践