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

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

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

互联网公司产品通常是通过软件、网站、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要小。被监控对象需要主动发送数据，因此不适用于对被监控对象要求较高的场景，如需要严格控制被监控对象的数据流量。

公司内部的监控系统来说，应该同时具备Pull和Push的能力才是比较合适的。

更多关于企业级监控平台系列的学习文章，请参阅：构建企业级监控平台，本系列持续更新中。

参考文章：https://blog.csdn.net/weixin_47533244/article /details/131628981 https://blog.csdn.net/weixin_43215948 /article/details/108444738