Hsukk
作者Hsukk2020-10-15 15:11
其它, HRBB

企业级监控管理平台建设实践分享

字数 2740阅读 2070评论 1赞 8

背景概述

监控是IT运维体系中的重要组成部分,作为运维和安全生产保障的生命线必不可少。运维的安全生产保障,主要以“监、管、控、防”为核心,其中“监”则主要指监控。随着科技革命的进行,大数据、微服务、云计算等新技术和架构的应用应运而生,传统的技术框架满足不了日益变化的业务需求和移动互联网的不断挑战。主动开展架构转型,建立开放、弹性、高效、安全的新一代应用系统势在必行。监控平台也随着市场需求向分布式、微服务、易扩展、松耦合的方向发展。集中处理能力,纯化采集能力,处理层服务化,功能松耦合,层级解耦,灵活Scale Up 和 Scale Out,从而实现企业级统一监控管理、统一处理、统一告警、统一展现的一体化监控管理平台。

建设原则

集中监控
在一体化运维体系中,监控平台贯穿所有环节,可以对生产系统涉及的各种环境的实时运行状况进行监控,监控平台事件驱动的特性也为一体化运维体系起到驱动的作用。为了提高投入效率,减少重复投入,建立集中监控平台实现统一展示、统一管理是迫切需要的。集中监控也能够同时实现两地三中心建设,具备灵活的扩展性,支持运维数据分析等功能。

分层监控
当前并没有哪一个监控工具可以覆盖所有生产系统的运行指标,不同的专业线条需要不同的监控工具,因此需要不断完善沉淀监控工具。另外监控平台从WEB、APP、到DB均采用了多中心双活分布式架构部署,但为了保证监控覆盖能力,部分重要的环节仍建议不仅限一套监控工具。

  1. 基础设施层:包括运营商网络专线、机房(机房内的设施,比如制冷、安防等)。基础设施层的监控分为状态、性能、质量、容量、架构等几个层面。
  2. 网络层:包括存储、网络设备等的可用性状态、IO等。
  3. 系统层:包括系统、服务器的可用性、性能消耗等。
  4. 数据库层:主要是指数据库的使用情况。
  5. 中间件层:主要针对中间件的使用情况。
  6. 应用服务层:主要是针对应用服务可用性、应用运行状态、应用性能、链路跟踪等方面。

自主构建:去商业化,自主构建

我们基于开源产品自主研发,提供从底层基础架构到上层应用的多维立体化的监控能力,以及事件发现、处理、跟踪、分析、关闭等一体化管理能力。平台围绕“集中监控、集中管理、智能分析、统一展现”的建设思路,基于Kafka、Flink等大数据框架及流式处理架构,以开源产品为核心自研的分布式事件处理引擎,实现灵活且全面的数据采集和高效的数据处理能力;引入机器学习算法引擎,支撑动态基线、容量预测、事件关联分析及数据价值挖掘等能力;采用微服务架构、容器的管理发布,实现灵活的平台伸缩和高效的开发交付能力。

监控工具

 基础监控类

基础监控类
 

 链路工具类

链路工具类
 

监控指标

指标分类
1、基础架构层
环境动力:暖通系统(如空调、机房环境、漏水)、电力系统(如配电柜)、安防系统(如消防、门禁)等。
安全设备:防火墙、入侵检测、防病毒等。
2、系统网络层
存储设备:磁盘阵列、虚拟带库、物理磁带库、SAN、NAS等。
网络设备:路由器、网络交换机、多层交换机、负载均衡设备。
3、系统层
虚拟化:虚拟网络资源、虚拟主机、虚拟存储资源、容器等。
服务器:大中小型机、X86服务器。
4、数据库层
数据库:ORACLE、MYSQL、SQL SERVER等。
其它系统软件:备份软件 。
5、中间件层
中间件:WEBLOGIC、TOMCAT、REDIS、NGNIX等 。
6、应用服务层
服务可用性:服务状态、日志刷新、端口监听、网络连通性等。

指标分级
有监控指标,就需要针对监控指标定义阈值,监控阈值的设立需要有分级机制。对于升级,是指当一个预警长时间未处理时,需要有一个上升机制,转化为告警,以督办运维人员完成监控事件的处理。分级与上升需通过流程管理加以落实。

监控报警消息级别分为以下5种类型:

平台介绍

平台总体架构

平台分四层:工具层-预处理层-服务处理层-展示管理层
1、工具层:自研采集器+开源采集工具(Zabbix、Prometheus、Sw等),若有工具更新或新的工具接入时,只需定制相关驱动器即可。
2、 预处理层: 平台对采集工具的驱动管理、对采集数据的规则预处理等。
3、 服务处理层: 自研统一事件处理引擎(下文介绍)、标准化后端、拓扑引擎、智能告警引擎等。
4、 展现层: 统一告警查询管理、统一性能展示、统一监控配置中心、平台配置管理、报表中心等。

新一代企业级事件处理引擎 

为了解决商业套件Tivoli OMNIbus的性能问题和架构问题,并实现自主可控的目的,经过充分的调研和设计,我们开发了新一代分布式事件处理引擎,可以完美地替代OMNIbus产品,并提供高并发、分布式、可容错的事件处理机制,可以应对偶发性的告警风暴。另外,值得一提的是“APP应用商店”模式使定制化开发更灵活、功能更强大,你可以用Java、Scala编写复杂处理逻辑,发布成APP,热部署到事件处理引擎中,APP可编排、调度、协同工作,同时也可随时将APP卸载。
 总体架构

总体架构

 特色优势

特色优势

 实现效果

实现效果

持续优化

减少误报
和ITSM对接,实现监控事件自动派发工单,在ITSM进行统一事件管理;
结合ITSM变更工单,通过CMDB资源关系模型数据,自动化识别变更影响,进行监控维护期配置,减少变更窗口报警外发。

减少漏报
监控评价功能,可以量化监控覆盖情况,进而实现找出非标准监控项、整改不适用监控项、丰富监控标准的目的,借助监控评价主动反馈机制,闭环评价流程,以评促改!

监控评价包括1个标准,1个档案,3个度量指标:

  • 监控标准库是依据;
  • 监控档案库是实际值;
  • 度量指标包括监控覆盖度、标准化率、超额布控率,是评价结果。根据实际情况设置加权系数,计算监控得分。

监控系统建设的目标是完善监控能力,持续优化是必不可少的环节,减少误报的同时,尽量将漏报数量降为0。可以结合丰富的分析类报表,每周、每月进行周期性地分析、优化,特别是对于非监控发现的故障要进行专项分析;告警关联压缩可以杜绝“狼来了”的假象;统一事件处理引擎结合CMDB资源关系模型,实现告警关联,以便故障快速定位;另外,还需要提升监控的自动化能力和智能监控能力,监控标准服务化、监控工具箱、自动化平台等功能结合,完善自动化监控上下线、自动排障、故障自愈的能力。

作者团队介绍:
光大科技有限公司智能云计算部智能化平台团队监控平台项目组,致力于光大集团统一监控管理平台的建设,全面支撑传统架构和容器云分布式架构下的监控管理,探索研究智能化监控,推动分布式架构下的大数据、人工智能技术为基础的实时监控技术。我们团队在分布式、大数据、人工智能领域拥有多名经验丰富的技术专家,将不定期与大家分享原创技术文章和相关实践经验,期待与大家共同探讨和进步。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

8

添加新评论1 条评论

#he7yong研发工程师, Canway
2020-10-16 11:38
来自真实项目经验的总结,非常好!感谢分享!
Ctrl+Enter 发表

日志分析平台选型优先顺序调研

发表您的选型观点,参与即得50金币。