运维思索：系统监控体系 ｜ 8月更文挑战

简述

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

所以接下来一段时间，我可能会陆续分享运维过程当中对一些问题的思考，但愿给你们带来必定的启发。

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

系统监控现状及问题

1.如何监控？

硬件、基础状态、应用、业务，监控对象多并且杂，如何可以所有覆盖？ 企业内部的各类监控工具，咱们应该如何管理？ 监控工具之间的信息孤岛如何处理？

2.如何告警？

告警太多，如何沉淀有效告警？ 告警泛滥，如何进行收敛，避免告警的狂轰滥炸？

3.如何处理？

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

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

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

平台化监控思路转变

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

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

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

PaaS属性

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

1. 监控iPaaS层

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

2. 监控aPaaS层

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

总结大致布局以下：

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

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

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

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

总结

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

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