运维思索：系统监控体系

Posted 2021-04-25 木讷大叔爱运维

读完需 6 分钟

 速读需 3 分钟 

各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。

因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。

本次分享的是确立一套运维监控体系，构建可持续成长的监控平台。

系统监控现状及问题

1.如何监控？

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

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

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

2.如何告警？

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

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

3.如何处理？

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

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

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

平台化监控思路转变

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

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

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

PaaS属性

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

1

监控iPaaS层

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

2

监控aPaaS层

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

总结大体布局如下：

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

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

1. 集成不同的监控工具，一定程度上实现了监控数据之前的共享和融合；

2. 业务和应用无法有效关联，导致告警在一定程度上是脱离业务的，需要运维人员自行脑图总结；

3. 由于不同工具的接入，平台层和场景层如何联动，需要运维人员统一API接入；

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

总结

了解过蓝鲸的小伙伴，可能对以上内容比较熟悉，但重点是我们如何站在巨人的肩膀上来看清我们的不足，从什么角度去思考问题。

以上的平台化监控架构可以为我们构建系统监控体系提供了思路，剩下的就是我们如何从细节性问题入手，利用技术手段去解决问题了。