|
本文作为监控告警产品的专题系列的第二篇文章，主要讨论的是IAAS层的监控(服务器状态与性能、网络设备状态与性能、网络流量分析等等)，从前文所述的监控类型来说，IAAS层一般来说属于基础监控层面
庖丁解牛 IaaS IaaS、PaaS、SaaS这三个概念想必大家是耳熟能详了，其实就是云计算的三个分层，Infrastructure-as-a-Service(IaaS)基础设施即服务，Platform-as-a- Service(PaaS)平台即服务，Software-as-a-Service(SaaS)软件即服务。
IaaS层其实就是一些显性可见的资源对象，如运维小伙伴经常接触的服务器、网络设备与存储设备等等。用一座大厦类比的话IAAS层就好比是负责了最基础的水电通信等能力。上层的服务都是依赖于IaaS层，假定IaaS层管理不好，那么PaaS与SaaS的高效与可控管理其实也是非常难了，甚至可以说空谈了。IaaSI层的不稳定会直接导致企业对外的服务质量大打折扣。笔者以前在负责手机QQ业务运维的时候，名下有4k多的机器，如果没有一套高效与可度量的管理平台，光凭人肉去管理4K多的机器，那基本和噩梦差不多了。 IaaS的监控 对于IaaS层的监控，本质来说就是监控组成IaaS层的各个资源对象，那么资源对象代表什么呢? 例如物理服务器、交换机、一条专线与一个公网IP等等都是一个个资源对象。通常来说对于资源对象的监控可以分为以下4个维度。
状态的监控：通指设备的的状态，如设备的存活状态、网络设备的端口状态、电源、风扇状态等。 性能监控：通指设备内存大小，端口流量包量、CPU利用率 等等 质量监控：通指设备的丢包率、错包率、网络访问的延时等等 容量监控：通指设备的负载使用率、专线带宽使用率、网络设备的负载使用率、服务器的负载使用率等等。 监控产品的分层结构 对于绝大多数主流商用或者开源监控告警产品来说，一般都是采用这种类似的分层方式，当然这里是一种高度抽象后的产品分层架构。
位于最底层的就是数据采集，采集到的原始数据是监控的最初的输入。 数据采集 通常来说企业级的监控系统应该是支持多种采集方式与多种采集对象的，例如可以用Agent主动上报、也要能支持SNMP、Xflow、IPMI等多种协议。而针对于IaaS层具体支持的采集对象应该不少于 物理服务器、操作系统指标(linux&windows)、网络设备、网络内会话信息、物理专线、网络出口等等。不同的采集对象采用的采集方式也是不同的，例如 服务器系统指标可以用Agent上报、网络设备状态、流量、包量可以用SNMP采集等，具体采用哪种采集方式要看业务场景与所需场景的数据量与类别而定。织云同样也是支持多种采集方式与多种采集对象。 在大数据的时代背景下，数据采集这部分建议针对某一个具体的对象尽量采集的大而全，可能有些数据暂时看采集上来没有直接用途，但是随着数据量级与数据间关联性的变化，对大量的原始数据，清洗、分析、加工后便能催生更多的数据消费场景。 基础概念 监控告警是对某一个具化的对象做采集、存储、分析、展示、告警、处理的过程。
为了便于读者对于后文与后续系列文章的理解，这里笔者先集中描述一下设计织云监控告警平台时应用的一些概念。对于监控告警织云的理念是先纳管对象在监控对象，这也是海量运维的最佳实践。 告警(监控)对象 定义：CMDB中管理的一个具体资源对象或者是一个自定义逻辑CI 示例：一台物理服务器、一个三级业务、一个TDSQL实例，这些均是对象 备注：对象与对象之间也有是关联、包含、继承等关系 告警(监控)指标 定义：一个或多个特性id(或特性间的四则运算产生的结果)的集合 示例：CPU使用率、内存使用率均是特性id; 而 例如 成功率=(成功的请求总数/总请求数)*100 这个就是多个特性id的四则运算。 备注：并不是所有监控指标都可以用来做有效的告警指标，这部分是按需所用。 告警(监控)类型 定义：确定了一部分的告警对象的告警指标采取一类的算法计算 示例：单机性能告警(就包含了多个针对于服务器这个对象的监控告警指标，如 cpu使用率、内存使用率、应用程序内容使用量等) 告警规则 定义：告警对象+告警指标+告警产生条件+告警通知收敛规则(阈值、发生次数、统计时长等等)，应用于告警策略 示例：例如对某台交换机创建了，cpu使用率>80时的告警规则 告警策略 定义：告警对象+告警类型+告警规则(可多个) 对应一个告警策略 示例：对一个三级业务下的全量服务器创建了一条基础告警策略，下图中的每一条都是一个告警规则， (责任编辑：admin) |
