监控系统MRD模板

监控系统MRD项目背景部署系统和监控系统的重要性无需多言。目前小米采用的监控系统主要是zabbix+perfcounter。机器量上来之后，zabbix很难承载，而且易用性巨差，没有很好的与我米内部系统（比如部署系统）相结合，监控项和策略管理麻烦，耗费巨大人力。为了以后更好的支撑我米各个产品线迅猛发展，新的监控系统迫在眉睫。新的监控系统应该能够承载大规模机器的报警能力，同时方便用户使用。大家都懂的，不再赘述。名词解释监控项（moni_item）：包含metric（比如cpu.idle/t/t/io.util/t/qps）+采集方法+采集和汇报频率采集项模板（metric_template）：定义了一批metric报警策略模板（strategy_template）：定义了一批监控项的报警策略，内容包括监控项，阈值，触发报警的阈值持续次数，报警接收人，同一个问题的最多报警次数host_group就是一个机器列表的集合instance_group就是一个实例的集合，解释下这里的实例，比如xae上部署一个mi-download服务，可以有多个instance，说的就是这种类型的实例；和现在部署系统的job类似功能概述本节讲述监控系统大方向上应该提供哪些功能。快速配置：包括监控项和报警策略的快速配置，以此传达用户的监控需求收集数据：能够按照用户指定的频率收集不同的监控数据数据存储：要长久存储监控数据，用于挖掘分析分析并报警：如果监控数据达到策略中配置的阈值，要能报出警展示数据：对收集到的监控数据，可以通过一些图表做展示提供api：让普通用户可以通过api对监控数据做CRUD与其他系统整合：主要是部署系统/xbox功能详述快速配置典型的配置方式分两种：web页面方式web方式不可编程，但是操作方便，最大的好处是可以继承和覆盖模板，这点非常赞~把default改动了，所有的子配置模板都会同时改动，如果不想受父模板影响，就在自己的模板文件中覆盖，方便！api方式提供api更可编程，但是复杂度增加，操作起来不太容易，我就想为一台机器添加一个cpu.idle的监控，还得让我写脚本，写配置，这个有点太麻烦咱们可以两种方式都提供，先做web方式，再做api方式那么web页面方式应该如何描述用户的需求呢？这个问题先放一下，先举几个例子看看用户需求到底是什么？对公司所有机器添加基础监控项，比如cpu.idle/io.util对我们dba所有部署有mysql的机器添加网卡流量监控对所有挂载nfs的机器监控是否掉盘对部署xbox这个服务的机器添加qps监控对所有xae的机器添加8080端口存活监控，但是其中有一台冷备机，要排除这个机器对miliao所有新上架的机器添加基础监控，这部分机器没有上服务，报警接收人统一配置给xx吧对所有做了raid的机器添加xxx监控OK，上面是以普通用户的口吻在叙述需求，我们可以对这些需求做分类，还要注意所加监控的机器的范围。属于机器监控，范围是公司所有机器属于机器监控，范围是dba节点下所有部署mysql的机器属于服务监控，范围是所有nfs-client实例，或者描述为机器监控，范围是部署nfs-client的所有机器，因为一个机器只会部署一个nfs-client属于服务监控，范围是所有xbox实例属于服务监控，范围是所有部署了这个服务的实例或机器，但是要刨除其中的特例属于机器监控，范围是miliao的所有备机属于机器监控，范围是机器硬件配置中做了raid的机器。这个list之前没有阐述什么是机器监控什么是服务监控，看完这个list你应该可以有个认识了，咱们可以这么归纳：机器监控：监控实体是单台机器，但是添加监控的时候一般是给出一个机器的集合，为这个集合绑定模板。服务监控：监控实体是实例，添加监控的时候一般会给出一个实例的集合，而实例的集合通常就是服务了；如果一台机器只部署一个实例，也可以把监控实体勉强看做机器，此时可以用一个机器集合来描述监控项和策略模板。OK，现在我们有了两个监控实体，一个是机器，一个实例，我们的系统就是围绕这两个实体展开。配置这块要解决的问题，就是让用户通过某种配置方式传达一些信息给系统，告诉系统要对哪些实体做监控，阈值是什么，如何报警。但是因为监控实体（机器/实例）这个粒度太小，我们不可能一个实体一个实体的配置，所以，首先应该有个对实体的聚合！机器的聚合：通过上面的list可以看出，聚合方式多种多样，有根据机器硬件配置的，有根据服务树节点的，有根据服务部署情况的，有根据机器用途的，对这个机器的集合，我们需要抽象一个概念出来，在这里叫做：机器集合（host_group）。可是，服务树本来不就是用来筛选机器的么？我们真的要引入host_group这个概念么？要的，原因有二：1、监控系统不能依赖服务树，如果服务树挂了，监控系统就不能用了，这个不可以忍。监控系统是优先级更高的系统。监控系统所需功能只是服务树的一个子集，在内部自己简单实现一下即可。2、如果用服务树来筛选机器，模板就要绑定在服务树tag节点上，如果节点上下调整就会非常麻烦，容易让用户困惑所以要引入host_group！实例的聚合：本来觉得实例的聚合应该就是service，实际一个service下面还细分了job，所以说，同一种类型的instance的聚合还是单独抽象为instance_group。有了host_group和instance_group了，即有了监控实体的聚合了，接下来所述的模板就是跟这个聚合单位绑定的。那为啥要有模板的概念呢？比如host_group1和host_group2都希望添加metric1、metric2、metric3这三个监控项，就可以把metric1、metric2、metric3做成一个采集项模板，然后拿这个模板与host_group1和host_group2分别绑定一下即可。重申一下监控项的概念，用DDD建模，监控项是一个很重要的domainmodel（领域实体），它包含的属性有：metric（比如cpu.idle/t/qps/t）+采集方法+采集汇报频率机器监控中的监控项是全局唯一的，用metric这个字符串来作为identity，即，整个监控系统里只会有一个叫cpu.idle的监控项，只会有一个叫t的监控项实例的监控项与机器监控项有很大区别，后面叙述。采集模板（metric_template）是监控项的集合，比如[cpu.idle,t,qps,t]。一个host_group可以绑定多个metric_template，所以，一个host就绑定了多个metric_template，多个metric_template求并集，就是这个host应该添加的监控项host_group下的机器发生了变化，需要外界其他系统来告诉监控系统，然后监控系统-对减少的机器，去掉绑定的模板，新增的机器重新绑定模板；初期就是人工来做，后期可以让部署系统和xbox来调用监控系统的接口。还剩最后一个概念：监控策略模板strategy_template，用于描述各个监控项的阈值和报警方式，比如：metric=cpu.idle,val<0.2,host=lg-miui-xae-app01.bj,receiver=qinxiaohui,max_send=3instance_group=xbox,metric=qps,max(val)>10000,receiver=qinxiaohui,max_send=3第一个配置很显然是个机器监控，表示说lg-miui-xae-app01.bj这台机器的cpu.idle如果<0.2就报警；第二个是个实例监控，而且是同时对多个实例的监控值做了处理，表示xbox这个instance_group（instance_group大部分等价于job）的所有实例的最大qps>10000就报警。机器监控和实例监控的报警策略可以用相似的方式描述：）但是，实例监控的监控项与机器监控的监控项有非常大的区别。机器监控的监控项中包含metric+采集方法+采集汇报频率，这个全局唯一，应用到某个机器上就可以跑，但是实例监控的采集方法几乎是每个实例都不同……因为采集的pullerurl不同，采集频率也会因为实例本身不同而不同，太频繁了甚至可能会影响服务。所以对于监控项的配置，实例监控需要单独做！分两种情况：pull/pushpush方式，监控项不需要做任何配置，用户直接调用监控系统api，push上来的数据大致为：metric=qps,endpoint=ip:port,timestamp=?,val=?,instance_group=?metric=t,endpoint=ip:port,timestamp=?,val=?,instance_group=?pull方式，由监控系统去主动拉取，故而需要用户提前在系统中配置好拉取方式和频率由于各个服务的实例监控的拉取方式和频率很难相同，所以实例监控中可以不要采集项模板的继承/覆盖功能。疑问：metric_template仅仅是metric的列表，strategy_template不但有metric还有其他各项信息，那这两个模板可以合并么？甲方认为不可以：因为一个监控项可能会有多个策略。比如cpu.idle<0.3邮件报警，<0.1短信报警，而且有的监控项只是希望收集数据，不做报警处理乙方认为可以：不需要报警，就给表达式部分和报警接收人部分留空即可；一个监控项多个策略不是妨碍合并的原因！只是，如果干掉metric_template之后，我们只能从strategy_template获取metric集合，而且可能要去重，但是对于用户来说，就绑定了一个模板，会省事！我们按照业务流程走一遍：首先在监控系统中创建一个host_group_for_base_monitor，绑定的模板就是那些基础监控项，如果公司只有一个备机池，那么只需要一个这样的host_group，如果备机是各个部门自己维护的，就需要多个这样的host_group。新机器上架，sa安装操作系统以及各类基础环境，同时安装监控的agent，这部分机器还没有上服务，但是这部分机器应该添加基础监控项，所以备机管理员要去监控系统把这些机器添加到host_group_for_base_monitor中。由于监控系统的host_group与服务树没有什么直接关系，故而，备机管理员可以在xbox中随便挂载这些机器以达到自己的管理需求。这些机器上服务了，要在监控系统中创建一个新的host_group来绑定一些与服务相关的机器监控。举个例子，比如之前提到的探测nfs是否掉盘的监控。自然，与这个host_group绑定的相关监控会应用到下面所有的机器上。如果这个服务要对各个instance做监控，需要在监控系统创建一个instance_group（这个与服务树的job级别的tagString有很好的对应关系，推荐直接使用job的tagString作为instance_group的标识字符串），为其绑定strategy_template，如果是pull方式，还需要配置拉取方式。服务下线，重新回备机池，把服务相关的host_group删除，把instance_group删除，相应的监控就会自动删除机器下架，删除所有关联的数据上面所述的所有人工操作都可以通过与其他系统结合做成自动化的来优化收集数据维持之前所讨论的数据格式不变，metric+维度机器监控push给transfer的数据样例metric=cpu.idle,host=lg-miui-xae-app01.bj,timestamp=?,val=?,host_group=?metric=t,host=lg-miui-xae-app02.bj,timestamp=?,val=?,host_group=?实例监控push给transfer的数据样例metric=qps,endpoint=ip:port,timestamp=?,val=?,instance_group=?metric=t,endpoint=ip:port,timestamp=?,val=?,instance_group=?监控数据来源（发送终端）分三种：监控agent：主要收集机器监控数据，比如cpu.idle,memory.usage等pull-worker：主要收集实例监控数据，循环调用用户的pull接口实例本身：实例自己可以push监控数据给监控api数据存储要有一个仓储永久存储所有数据，方便做挖掘，嗯，hbase要有一个仓储存储打点数据来做图表展示，嗯，mysql，注意分库分表要有一个地方存储counter，及时报出警，内存！本文档只叙述数据存储需求，不涉及具体存储细节分析并报警支持四种报警：单机器的，比如某个机器的网卡流量多机的，比如5台机器，宕机2台之后报警单实例，比如endpoint=1:8080的qps>10000报警多实例，比如instance_group=xbox的所有实例avg(qps)>5000报警报警描述方式应该趋于统一，比如：host=lg-xae-api.bj,metric=cpu.idle,val<0.3,receiver=user-group1:mail,max_send=3host_gro