⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处民工哥技术之路「民工哥技术之路」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前面介绍了企业级监控概述及发展等相关的知识点，今天我将详细的为大家介绍如何做好企业监控系统运维相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发朋友圈支持一波！！！

互联网应用中离不开监控系统，那么为什么会有监控系统呢？

互联网公司产品通常是通过软件、网站、App或其他数字化方式提供服务的，这类产品在使用过程中可能会面临一系列风险和挑战。

比如网络故障或稳定性问题，由于网络故障、硬件故障或配置错误等原因，可能会导致访问不稳定或宕机，进而影响用户的体验。还有像是性能瓶颈和延迟，当用户访问量增加时，可能会对服务器产生超过负荷或达到带宽上限的压力，导致网页或其他平台响应速度变慢，影响用户体验和满意度。还有数据安全性问题，不法分子可能通过攻击防火墙、病毒、恶意软件等途径获取数据或进行恶意操作，在一定程度上破坏了数据的安全性。所以互联网公司需要在开发、测试、发布、运维等不同阶段对产品进行监控，以便及时发现问题并采取相应措施。

下面我们就来探讨一下，在企业实际运维监控过程需要做哪些？需要了解哪些？

监控目标

每个人由于所在的行业、公司、业务、岗位不同，对监控的理解也不尽相同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

对系统不间断的实时监控：实际上是对系统不间断的实时监控(这就是监控)；
实时反馈系统当前状态：我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障。
保证服务可靠性安全性：我们监控的目的就是要保证系统、服务、业务正常运行
保证业务持续稳定运行：如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

监控方法

了解监控对象：我们要监控的对象你是否了解呢？比如CPU到底是如何工作的？
性能基准指标：我们要监控这个东西的什么属性？比如CPU的使用率、负载、用户态、内核态、上下文切换。
报警阈值定义：怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高，用户态、内核态分别跑多少算高？
故障处理流程：收到了故障报警，我们怎么处理呢？有什么更高效的处理流程吗？

监控核心

发现问题：当系统发生故障报警，我们会收到故障报警的信息。
定位问题：故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析。比如一台服务器连不上，我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等，我们就需要去分析故障具体原因。
解决问题：当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。
总结问题：当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。

监控流程

数据采集：通过对系统、硬件、网络、业务等进行数据采集；
数据存储：存储在数据库服务；
数据分析：当我们事后需要复盘分析故障时，监控平台可以提供图形以及时间等相关信息，方便我们确定故障所在；
数据展示：Web界面展示、(移动APP、java_php开发一个Web界面也可以)；
监控报警：电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）；
报警处理：当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急，等。根据故障的级别，配合相关的人员进行快速处理。

监控指标

上面了解了监控方法、目标，可能有人会疑惑，我们具体要监控些什么东西，在这里我进行了分类整理，包含硬件监控、应用监系统监控、网络监控、流量分析、日志监控、安全监控、API监控、性能监控、业务监控。

硬件监控

早期我们通过机房巡检的方式，查看硬件设备灯光闪烁情况判断是否故障，这样非常浪费人力，并且是重复性无技术含量的工作，大家懂得。

系统监控

中小型企业基本全是Linux服务器，那么我们肯定是要监控起系统资源的使用情况，系统监控是监控体系的基础。监控主要对象：

操心系统常见指标

CPU利用率  #服务器上CPU主要的核心使用率情况。
实时负载  #系统上所有进程的数目，计算干活的进程数，以及等待队列的进程数，也就是当前的机器的实时压力情况。
内存使用率  #服务器内存使用情况，包括已使用、空闲等情况。
网络带宽利用率  #服务器网络使用度，包括网卡、负载均衡、网络连接等的带宽使用情况。
硬盘I/O读写速度  #磁盘读写速率。
硬盘容量  #服务器硬盘容量使用情况，包括已使用、空闲等情况。
进程使用率  #检查系统进程情况，包括进程执行状态、占用集群资源等情况。
端口连接状态  #检查系统端口连接的状态。
错误日志记录  #记录系统产生的错误日志，包括错误类型、时间、处理结果等情况。
响应时间  #服务器响应请求的时间

针对系统监控就必须要了解这个系统可用性的指标。

什么是系统可用性指标？

SLA 衡量一个系统可用性有多高，目标系统 7 x 24 小时不间断服务，云厂商在宣传自己产品SLA时多少个9。

时间维度：系统可以正常使用时间与总时间之比（全年为例子）1年 = 365天 = 8760小时。

99.9 = 8760 0.1% = 8760 0.001 = 8.76小时。
99.99 = 8760 0.0001 = 0.876小时 = 0.876 60 = 52.6分钟。
99.999 = 8760 0.00001 = 0.0876小时 = 0.0876 60 = 5.26分钟。

请求次数维度：请求总次数和失败的占比(1000次请求为例子，相对简单)

系统可用性99%：表示1000个请求中允许1000 * (1- 99%) = 10个请求出错。
系统可用性99.9%：表示1000个请求中允许1000 * (1- 99.9%) = 1个请求出错。
9 越多代表全年服务可用时间越长服务更可靠，停机时间越短，但往往存在网络/机房问题，应用更新发版导致服务不可用。
- 基本可用：2个9，一年中大概停机时间小于88小时
- 较高可用：3个9，一年中大概停机时间小于9小时
- 高可用：4个9 即 99.99%，一年中大概停机时间小于53分钟
- 极高可用：5个9，一年中大概停机时间小于5分钟
- 大厂多数业务4个9是刚需，5个9是目标，6个9是理想
- 业界用多少个9衡量系统的可用性

应用监控

需要登陆到服务器上查看服务器运行了哪些服务，这些也都需要监控起来。

应用服务监控也是监控体系中比较重要的内容，例如：LVS、HAProxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、RabbitMQ等。

网络监控

时刻掌握各地到机房的网络状态也是必须的。

网络监控是我们构建监控平台是必须要考虑的，尤其是针对有多个机房的场景，各个机房之间的网络状态，机房和全国各地的网络状态都是我们需要重点关注的对象。

网络常见指标

带宽利用率  #网络带宽利用率评估，包括上传和下载比率。
包丢失率  #测量包在传输中丢失的数量和百分比。
延迟时间  #从发送请求到得到响应且完成处理信息所需的时间。
网络流量  #流经网络的实时数据量和数据流量。
网络错误率  #网络传输中发生的错误数量和百分比。
连接数  #网络连接总数。
网络响应时间  #网络请求响应时间。
网络拥塞状态  #系统可用资源数量和使用率。
传输速度  #网络传输速率，包括平均速率和实时速率。

日志监控

通常情况下，随着系统的运行，操作系统会产生系统日志，应用程序会产生应用程序的访问日志、错误日志，运行日志，网络日志，我们可以使用ELK来进行日志监控。对于日志监控来说，最见的需求就是收集、存储、查询、展示。

安全监控

虽然Linux开源的安全产品不少，比如四层iptables，七层WEB防护Nginx+Lua实现WAF，最后将相关的日志都收至ELkstack，通过图形化进行不同的攻击类型展示。

如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防DDOS，避免出现故障导致down机一天。如果是系统，那么权限、密码、备份、恢复等基础方案要做好。Web同时也可以使用Nginx+Lua来实现一个Web层面的防火墙。当然也可以使用集成好的OpenResty。

API监控

由于API变得越来越重要，很显然我们也需要这样的数据来分辨我们提供的 API是否能够正常运作。

监控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的请求。可用性、正确性、响应时间为三大重性能指标。

性能监控

全面监控网页性能，DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等。

业务应用程序、中间件应用程序常见监控指标

关注整体服务的状态和运行质量，能够及时预测系统运行瓶颈，保证产品的高效和用户体验。

请求响应时间  #从请求到获得响应的整个时间。
错误率  #应用程序产生错误的请求占总数的百分比。
CPU使用率  #应用程序当前使用的处理器资源百分比。
线程实例数  #当前在应用程序中运行的线程实例数量。
平均程序执行时间  #应用程序各模块的平均执行时间。
堆内存使用率  #应用程序中Java虚拟机（JVM）分配的内存占用的百分比。
平均延迟时间  #从请求到响应开始的时间差。
垃圾回收时间  #在JVM中收集不再使用的内存对象所需的时间。
响应代码  #HTTP请求成功或失败代码。

业务监控

没有业务指标监控的监控平台，不是一个完善的监控平台，通常在我们的监控系统中，必须将我们重要的业务指标进行监控，并设置阈值进行告警通知。

比如电商行业：每分钟产生多少订单、每分钟注册多少用户、每天有多少活跃用户、每天有多少推广活动、推广活动引入多少用户、推广活动引入多少流量、推广活动引入多少利润等。

重点关注业务运营的分析和结果，通过监控平台运营情况和各种配置，获取更多业务数据。及时发现行业发展趋势，指引业务方向，实现全方位监控、预测和干预。

常见的业务监控指标

GMV销售额  #项目特定时间内总的销售额。
日活、月活  #日活跃用户数、月活跃用户数
客单价  #平均每个订单的金额
支付成功率  #成功支付订单和总订单的比率
订单量  #每次交易中的订单数量。
购物车转化率  #加入购物车商品与实际付款之间的比率。
转化率  #网站访客转化为潜在客户（注册、订阅、购买等）的百分比。
用户留存率  #每月活跃用户数量与上月活跃用户数量的比率。
退款率  #以退货所得的金额与总交易金额之间的比率。
每次交易的平均时间  #从访问网站到交易结束的总时间。
每个访问的平均时间  #用户在网站上花费的总时间除以有效付款数量。
启动错误率  #应用程序在第一次启动时无法正确启动的次数。
平均执行时间  #任务执行所需的平均时间。
异常数量  #系统产生的错误、崩溃、死锁等数量。
页面加载时间和速度  #网页从请求到加载的时间和速度。
点击率  #网站广告点击率。

监控报警

报警方式

故障报警通知的方式有很多种，当然最常用的还是短信和邮件。

报警处理

一般报警后故障如何处理，首先我们可以通过告警升级机制先自动处理，比如Nginx服务down了，可以设置告警升级自动启动Nginx。

但是如果一般业务出现了严重故障，我们通常根据故障的级别、业务，来指派不同的运维人员进行处理。

当然不同业务形态、不同架构、不同服务可能采用的方式都不同，这个没有一个固定的模式套用。

监控系统的架构模式

Pull模式

可以根据需要定时获取数据，避免数据的多余传输，节约网络带宽和存储空间。也可以根据需要通过请求的方式，选定性地获取部分数据。它适用于对被监控对象的稳定性要求不高的场景。Pull模式核心消耗在监控系统侧，应用侧的代价较低。但是由于需要定时发送请求获取数据，对于需要实时响应的业务，Pull模式的数据传输速度难以达到。Pull模式需要能够处理推送事件的应用程序，因此需要有较高的成本和复杂性。

Push模式

该模式下被监控对象可以主动推送数据，监控客户端不需要发送请求，因此避免了网络负载。对于需要实时响应数据的业务，Push模式具有更高的传输效率和更佳的实时性。Push模式适用于稳定的网络环境，可以实现实时数据的快速传输但是Push模式核心消耗在推送和Push Agent端，监控系统侧的消耗相比Pull要小。被监控对象需要主动发送数据，因此不适用于对被监控对象要求较高的场景，如需要严格控制被监控对象的数据流量。

芋道源码 —— 纯源码解析博客

构建企业级监控平台系列（二）：如何做好企业监控系统运维管理？