系统监控体系

1 系统监控现状及问题

1.1 如何监控？

硬件、基础状态、应用、业务，监控对象多而且杂，如何能够全部覆盖？

企业内部的各种监控工具，我们应该如何管理？

监控工具之间的信息孤岛如何处理？

1.2 如何告警?

告警太多，如何沉淀有效告警？

告警泛滥，如何进行收敛，避免告警的狂轰滥炸？

1.3 如何处理?

告警处理无记录，和企业运维流程脱节，怎样形成知识沉淀？-----所谓的知识库，线下整理不及时，增加工作负担。

告警处理纯靠手动，每个月都在重复处理相同故障，如何避免？-----手动处理效率不高，牵扯太多的精力。

以上问题是在建设监控系统时面临的一些问题，以前我总是想用一个监控产品来实现所有的需求，避免我们在多个产品间来回切换，看来有点舍本逐末。

2 平台化监控思路转变

首先，我们先从监控的本质出发：监控系统的目的是为了及时发现问题，解决问题，直至预测问题，不是为了整合系统。

其次，随着公司技术栈的不断升级，业务系统的架构也在不断演进，而原来传统监控可能就不能够满足监控需求。此时就需要不断补充监控手段，例如Grafana、Prometheus、ELK，实现图形化监控、容器监控、日志监控。因此监控平台一定是多种监控产品并存，而运维需要构建可持续成长的监控平台。

最后，在认清以上监控治理的现状后，我们需要实现监控建设的思路转变：由产品化思路向平台化思路转变。即：由要找一个大而全的监控产品，囊括全部的监控诉求转变为需要一个具备功能生长性的监控平台，来承载核心监控诉求，并能统一集成外部的各种监控产品，服务于业务监控的目标。

3 PaaS属性

构建功能可持续成长的监控平台，关键在于监控平台需要具备paas属性:

3.1 监控 iPaaS层

监控平台层，负责提供面向各类监控对象的基本的监控采集、存储、分析和告警的能力和工具；同时需要提供paas集成能力，能够对接和集成外部监控工具和系统。

3.2 监控aPaaS层

监控场景工具层，通过调用平台层的监控能力和监控工具，面向具体的应用和业务，提供组装式的、复合的监控场景工具，例如：统一告警中心、监控可视化、故障自愈等。

大体布局如下:

从这套监控架构来看，相信很多小伙伴都已经实现到了iPaaS（监控平台层）级别的监控，往往忽视了aPaaS（监控场景层）的多样性需求，如统一告警中心、故障自愈等的需求。而我们建立监控系统就是通过场景去发现问题、解决问题、甚至是预测问题。

虽然以上统一监控完成了监控由产品到平台的转变，也同样存在以下优缺点:

1. 集成不同的监控工具，一定程度上实现了监控数据之前的共享和融合；
2. 业务和应用无法有效关联，导致告警在一定程度上是脱离业务的，需要运维人员自行脑图总结；
3. 由于不同工具的接入，平台层和场景层如何联动，需要运维人员统一API接入；

看到这，小伙伴会想：为什么问题都是会不期而至呢？因为这些就是我们平时会忽略的细节问题。如果我们能集中资源从细节入手，那么我们可能就会得到意想不到的收获！

原创: 木讷大叔爱运维