本文主要是介绍快看！一张思维导图，包罗最全监控体系建设要点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
近年来，随着计算机技术的飞速发展，以及行业信息的共享，传统企业的运维己不再固步自封，日新月异的计算技术发展推动着企业云平台的建设，云平台的计算能力为大数据分析提供了基础，而云平台与大数据分析又将推动运维人工智能的发展。
放眼云、大数据、人工智能的运维发展方向的同时，作为运维的生命线，安全生产保障的生命线仍需强调。作为传统企业的安全生产保障，主要以“监、管、控”为核心，其中“监”则主要指的是监控。
本文将把笔者在工作过程中积累的监控体系建设知识进行总结，梳理成体系，思维导图如下：
监控体系分层
概述
传统企业的运维经过多年的积累，往往己沉淀下来不少监控工具，有不同专业条的工具，如基础设施、硬件、软件、安全等；也有不同类型的工具，如基于日志、数据库、中间件、操作系统、网络报文等。对于这些工具，我们采用以下方式处理：
建立集中监控平台：在一体化运维体系中，监控平台贯穿所有环节，它起到了生产系统涉及的软硬件环境实时运行状况的“监”，监控平台事件驱动的特性也为一体化运维体系起到神经网络驱动的作用，进而进行了“控”，另外，监控平台优质的运维数据可以作为运维大数据分析的数据源，实现运维数据采集的角色。为了提高投入效率，减少重复投入，需要建立集中监控平台实现统一展示、统一管理，支持两地三中心建设，具备灵活的扩展性，支持运维大数据分析。
原有的监控工具保留为主：当前并没有哪一个监控工具可以覆盖所有生产系统的运行指标，己沉淀下来的监控工具往往是当前生产系统深度定制的工具，具有存在价值。另外，虽然监控平台从WEB、APP、到DB均采用了多中心双活分布式架构部署，但为了保证监控覆盖能力，部份重要的环节仍建议不仅限一套监控工具。
各专业条线对各条线的监控负责：各专业条线是最清楚自己需要什么监控的团队，各专业条线对监控覆盖率负责，监控平台的建设方负责平台体系的建设，提供基础技术支撑。
工具间整合：不同的专业条线、不同的分析技术可以有不同的监控工具，采用这种多点开花的建设方式更有助于监控面与深度的完善，所有的工具最终需要进行标准化的整合。
基于上面4个处理思路，为防止监控建设失控，减少重复建设、明确主要的建设目标，我们需要对监控工具进行体系化管理，体系化管理首先要做的就是进行监控体系分层。
分层方式
相信每家企业对于监控分层体系都会有各自的划分方式，以下是以专业条线方式分层：
基础设施层：包括运营商专线、机房（机房内的设施，比如制冷、安防等）、网络设备，基础设施层的监控分为状态、性能、质量、容量、架构、流量分析等几个层面。
系统服务器层：包括系统服务器、存储等服务器的可用性状态。
系统及网络服务层：主要是指操作系统、系统软件、网络软件的使用情况。
应用服务层：主要是针对应用服务可用性、应用营业状态、应用性能、应用交易量分析几方面。
客户体验层：包括两块，一是客户访问速度；二是功能是否正常，具体指的是全部、局部、个别用户或终端访问情况，不仅包括业务系统是否能访问，访问的速度是否快，还包括业务逻辑的验证功能是否正常。
各层职责
基础设施
- 状态监控：包括机房供电、空调、网络设备的软硬件状态，如设备状态等；
- 性能监控：包括设备的性能情况，比如CPU、内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等；
- 网络监控：包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等；
- 容量监控：包括设备负载使用率、专线带宽使用率、出口流量分布等；
由于基础设施硬件往往己有设备健康性的检测机制，建议向这类厂商提要求，将设备的运行事件主动送到监控平台整合。
服务器层
- 存储：包括存储设备，以及设备上的硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误；
- 服务器上的内存（内存缺失、内存配置错误、内存不可用、内存校验）、网卡（网卡速率；电源：电源电压、电源模块是否失效）、风扇（风扇转速等）、Raid卡（Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略）；
- 虚拟机：vcenter等
- 容器：Docker等
存储、物理设备、虚拟机等建议参考基础设施层由厂商主动汇总事件到监控平台，由于容器方面的监控工具并不多，则需根据实际情况选择是否借鉴开源的工具进行自研。
系统服务层
系统服务层的数据主要包括操作系统、中间件、数据库，以及其它开源分布式中间件等工具，这方面包括很多，以操作系统为例，包括：CPU（CPU整体使用率、CPU各核使用率、CPU Load负载）、内存（应用内存、整体内存、Swap等）、磁盘IO（读写速率、IOPS、平均等待延时、平均服务延时等）、网络IO（流量、包量、错包、丢包）、连接（各种状态的TCP连接数等）、进程端口存活、文件句柄数、进程数、内网探测延时、丢包率等。
在分析系统服务层的数据消费情况时，可以通过分析系统性能情况，客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。可以根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。
这一层的工具主要采用引入成熟工具或自研的方式，可选的空间比较大，只要覆盖面够广、支持灵活的二次定制开发，应该问题都不大，建设过程中，我认为中间件与数据库两块是值得让DBA、中间件管理员深度挖掘监控指标覆盖面。
另外，在互联网分布式架构的推动下，传统企业也逐步使用一些分布式中间件，比如分布式数据库中间件，内存数据库、消息队列等。由于对于这类开源中间件，传统企业在技术上弱于互联网企业，且监控工具并不多，需要重点投入资源进行相关监控指标的开发。
应用服务层
- 服务可用性监控：如服务、端口是否存在，是否假死等；
- 应用营业状态监控：指应用的状态是否满足业务开业状态；
- 应用性能：应用处理能力，比如交易量、成功率、失败率、响应率、耗时；
- 应用交易：比如交易主动埋点、交易流水、ESB等；
应用服务层监控可扩展的面与深入的度都有很大空间，以下是部分应用监控点：
这篇关于快看！一张思维导图，包罗最全监控体系建设要点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
