对于网络设备的syslog告警来说，同样也会面临不同的厂商、设备类型与设备型号日志标准不统一，所以对于网络设备syslog监控告警来说，首先是将众多的网络设备进行逻辑分组，以便于在一个分组内的设备均可以响应同一个告警关键字，并且这个分组粒度建议较细，这样才能保障告警关键字的有效性与独立性。在这里根据多年的运维经验，建议syslog告警的分组模型由四个维度组成厂商+类型+型号+用途，例如 CISCO+交换机+EX43000-24T+内网接入层交换机，通过这个公式就描述出一个设备的逻辑分组。

　　服务器

　　对于服务器的监控同样也是从状态、性能与容量这几个维度入手。虽然SNMP也可以用于服务器监控，但相对于agent主动上报指标与数据会少很多。服务器的状态监控主要包含 服务器是否ping的通、agent上报是否超时与电源运行状态等等。对于性能与容量这两类维度，主要依赖当前OS的数据捕获，一般来说对于服务器监控来说在通用场景下主要关注cpu、内存、流量与包量这四个指标即可，但是别的指标也建议尽量捕获。 单个监控对象的数据丰富了会有如下好处。

　　避免对象的监控盲点

　　不同的监控数据点可以部分对应出该服务器所承载的业务特性指标，例如存储类业务也会关注 disk_total_read、svctm_time_max、await_time_max等等系统指标

　　生产的数据足够丰富能够催生出更加丰富的运维数据消费场景。

　　服务器监控相对是很标准的监控模型，针对于物理服务器与虚拟机都有共性指标。这部分主要做到采集的数据丰富与上报的准确性(算法准确)。

　　后续文章主题预告

　　数据银行CMDB的建设

　　形态各异的公有云组件通用监控模型建设之路

　　总结

　　IAAS层的监控从IAAS层的组成这个维度来说，可以分为一个个独立的资源对象来分类监控，针对每一类对象可以分别从状态、性能、容量、质量这几个维度描述，将不同的数据综合为开发与运维的统一视角。监控告警产品的建设是任重而道远的过程，坑也非常多。要考虑多种因素，技术后台能力只是其中的一部分。例如在DevOps的文化下，需要从更高的层面来统一视角(开发视角&运维视角)避免将监控做成”开发的监控”与”运维的监控”。也需要更多的考虑监控产品使用的双态(用户态&系统态)与不同的权限(行业属性)如何分类设计。