logo

走近监控系统的神经中枢

作者:沐小媛2019.10.27 06:27浏览量:4892

简介:作者简介 四金 百度高级研发工程师 负责百度智能运维(Noah)监控平台的设计和研发工作,在监控系统的配置管理方向

作者简介

四金    百度高级研发工程师

 

负责百度智能运维(Noah)监控平台的设计和研发工作,在监控系统的配置管理方向有广泛实践经验。

 

干货概览

随着软件系统的发展,监控目标场景越来越广泛,对监控系统的能力要求也越来越高。对于监控系统来说,从能力上看基本可以划分为数据采集数据计算、数据存储、异常检测、报警处理以及监控可视化六块。为了更好应对大规模、复杂化的监控业务场景,我们不仅仅需要在具体监控能力上做深、做强,还需要建立对应机制来统筹这些能力一起良好协作。今天的这篇文章就为大家介绍监控系统的神经中枢——配置管理与分发系统,让我们一起揭开它神秘的面纱吧! 

需求

在业务系统发展的初期,由于场景简单,对监控的需求也比较简单,比如仅采集默认的机器监控数据,不需要进行进程、日志等监控能力。同时监控的规模也相对较小,用户的配置数量一般在百或千级别,这时只需定期读取数据库中的配置就可以很好的工作。

随着业务系统的快速发展,业务体量越来越大,业务复杂度越来越高,对监控的需求也越来越高。传统的简单读取数据库配置在业务扩展性性能上遇到了挑战。

1支持不同类型的配置管理

监控指标采集、计算、报警等方面的配置种类越来越多。如物理机的机器资源类指标、应用程序的进程和日志指标的采集配置、站点的连通性采集配置、服务器的宕机检测任务配置、多个实例间指标的计算任务配置、指标数据的异常检测配置、告警信息发送配置等。

2支持不同场景的配置分发

  • 高并发配置下载场景:监控系统中每个物理机部署一个Agent用于对部署在该机器上的应用程序相关指标进行采集。Agent需要下载与主机关联的采集配置,在大规模的监控系统中,Agent的数量达到百万级别,采集配置的更新周期为10s,配置分发系统需要应对高并发查询的压力。

  • 一致性配置下载场景:为了应对高可用、大规模的数据计算及报警场景,各个子系统往往使用集群化部署。以报警集群为例,同一机器的数据可能会由报警集群的不同实例进行判断,若配置在集群内不一致,那么报警系统的行为就会变得不可预期。

3支持故障快速恢复

配置分发系统作为监控的枢纽,关联的模块比较多,系统故障会影响采集、计算、报警子系统工作的正确性以及用户新加监控配置不生效,所以需要相应的方案来保障监控系统的快速恢复或重建能力,来保障监控系统的可用。

图1  配置管理&分发系统交互流程图

方案

梳理完问题、需求,接下来就要针对这些问题进行相应的改造升级。下面我们从技术的角度介绍下如何解决这些问题吧!

一、支持配置可扩展性

复杂的监控能力意味着监控系统的配置种类灵活多样。如果直接将配置分发模型与业务模型对接,意味着业务上的每次改动都需要配置下发系统进行对应的变更。那么如何统一配置的多样性,做到配置下发对上层业务透明呢?答案是:归类+抽象

  1. 将不同的配置按照“目录”进行分类管理,实现统一的配置管理需求。

  2. 文件作为载体,所有配置都以文件的形式进行管理。不同的文件内容格式代表着不同类型的配置,原有格式的升级以及新类型的添加统一抽象为文件处理,增强了系统的扩展能力。

  3. 通过代码管理系统管理文件的方式,实现变更历史追踪。通过对文件系统的定时备份与构建快速故障恢复机制提升系统的可用性与可靠性。

图2  配置归类&抽象

在归类方面,由于不同的能力需要的配置形式不同,我们以此为依据进行分类。对应到实现中则通过目录表达分类的含义,通过子目录来表达配置的层级与归属等关系。这里我们将配置目录的层级分为监控功能层级->用户层级->应用层级三层,在应用目录下将具体配置(如进程监控配置、日志监控配置)写入文件中。

二、确保一致下发

通过对配置管理方式的抽象与归类整理,配置的一致性下发可以通过构建配置文件内容的一致性机制解决。我们使用“版本”作为文件内容一致性机制的核心。当用户变更配置时,配置管理系统会生成一个全局唯一的版本描述此次配置变更操作,版本中包含此次变更操作对应的配置文件变更详情。

配置下发时,在各个子系统会定期检测配置版本差异并更新本地配置至最新版本,从而保证配置在每个更新周期内保持一致。

三、应对高并发压力

大规模的压力则主要体现在采集Agent的配置下发部分。由于Agent只需拿到部署主机所需的监控配置,因此将配置文件按照监控的最小单元进行拆分,并按照规范进行打包。

图3  Agent配置拆分&下载流程

当前的业务部署往往采用混布方式,同一主机中会部署多个不同类型的应用程序。为了支持这种监控场景,主机上部署的采集Agent会查找主机上部署的应用并下载对应的多个应用配置。当业务规模增大时,物理机增多,配置下载请求也会成倍增长,因配置存储的Server端很容易达到性能瓶颈。通过可水平扩展的静态文件下载服务来应对高并发下载压力,通过ETag方式检测文件是否变更,只针对变更的配置文件才进行传输以减少下载流量,最终满足了百万级主机、千万级实例的配置下发需求。

四、故障快速恢复

考虑到配置在监控系统中的重要程度,为了保障业务的可用性,就需要构建监控系统的快速故障恢复机制。

同时,由于监控系统配置集中管理,随着系统的发展,配置的体积也在不断增长,配置文件体积达到数十GB级别,并且全部由小文件组成,文件个数也达到了数百万级别。为了减轻系统压力,在系统中加入“快照”机制,每隔一段时间便生成当前全量配置的快照,当出现大量更新时,先通过“快照”减少更新量,再通过对应同步机制进行少量的文件更新。

总  结

经过不断的努力和多次改造,目前的配置管理及分发可以满足监控系统的需求。由于能够灵活管理多种配置,并且快速、一致地送至各个系统。在面对故障场景时候,也可以及时撤回配置,避免更大的损失。然而随着监控业务的发展,系统架构的变迁,起着中枢作用的配置管理与分发系统将会面临新的挑战。路漫漫其修远兮,吾将上下而求索!

相关文章推荐

发表评论