互联网应用中离不开监控系统，那么为什么会有监控系统呢？
互联网公司产品通常是通过软件、网站、App或其他数字化方式提供服务的，这类产品在使用过程中可能会面临一系列风险和挑战。
比如网络故障或稳定性问题，由于网络故障、硬件故障或配置错误等原因，可能会导致访问不稳定或宕机，进而影响用户的体验。还有像是性能瓶颈和延迟，当用户访问量增加时，可能会对服务器产生超过负荷或达到带宽上限的压力，导致网页或其他平台响应速度变慢，影响用户体验和满意度。还有数据安全性问题，不法分子可能通过攻击防火墙、病毒、恶意软件等途径获取数据或进行恶意操作，在一定程度上破坏了数据的安全性。所以互联网公司需要在开发、测试、发布、运维等不同阶段对产品进行监控，以便及时发现问题并采取相应措施。
监控系统能帮助我们干什么？
-
实时监控系统性能和服务质量，确保系统稳定性，及时发现和解决故障。
-
监控用户行为和数据流量，进一步优化服务质量，提高用户体验。
-
提前发现并预测端到端的IT操作风险，避免数据安全性问题和资金损失。
-
监控系统的架构、代码和服务，提高系统构建和部署的质量，优化资源和运维成本
什么是系统可用性指标？
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越多代表全年服务可用时间越长服务更可靠，停机时间越短，但往往存在网络/机房问题，应用更新发版导致服务不可用
-
大厂多数业务4个9是刚需，5个9是目标，6个9是理想
-
业界用多少个9衡量系统的可用性
-
基本可用：2个9，一年中大概停机时间小于88小时
-
较高可用：3个9，一年中大概停机时间小于9小时
-
高可用：4个9 即 99.99%，一年中大概停机时间小于53分钟
-
极高可用：5个9，一年中大概停机时间小于5分钟
-
互联网公司常见监控分层
互联网公司监控和指标很多，按照顺序分层归类，这些指标不是绝对的，应该根据企业的业务和系统对应合适的选择。对于不同的监视重点，还应根据需求包括不同级别的指标。主要关注底层基础设施的状态和事件，以确保服务器、网络、CPU和存储设备等运行正常，提供稳定的资源支持。
（1）系统和网络层
主要关注底层基础设施的状态和事件，以确保服务器、网络、CPU和存储设备等运行正常，提供稳定的资源支持。
- 操心系统常见指标
CPU利用率：服务器上CPU主要的核心使用率情况。
实时负载：系统上所有进程的数目，计算干活的进程数，以及等待队列的进程数，也就是当前的机器的实时压力情况。
内存使用率：服务器内存使用情况，包括已使用、空闲等情况。
网络带宽利用率：服务器网络使用度，包括网卡、负载均衡、网络连接等的带宽使用情况。
硬盘I/O读写速度：磁盘读写速率。
硬盘容量：服务器硬盘容量使用情况，包括已使用、空闲等情况。
进程使用率：检查系统进程情况，包括进程执行状态、占用集群资源等情况。
端口连接状态：检查系统端口连接的状态。
错误日志记录：记录系统产生的错误日志，包括错误类型、时间、处理结果等情况。
响应时间：服务器响应请求的时间
- 网络常见指标
带宽利用率：网络带宽利用率评估，包括上传和下载比率。
包丢失率：测量包在传输中丢失的数量和百分比。
延迟时间：从发送请求到得到响应且完成处理信息所需的时间。
网络流量：流经网络的实时数据量和数据流量。
网络错误率：网络传输中发生的错误数量和百分比。
连接数：网络连接总数。
网络响应时间：网络请求响应时间。
网络拥塞状态：系统可用资源数量和使用率。
传输速度：网络传输速率，包括平均速率和实时速率。
（2）应用层（业务应用程序、中间件应用程序等）
关注整体服务的状态和运行质量，能够及时预测系统运行瓶颈，保证产品的高效和用户体验。
请求响应时间：从请求到获得响应的整个时间。
错误率：应用程序产生错误的请求占总数的百分比。
CPU使用率：应用程序当前使用的处理器资源百分比。
线程实例数：当前在应用程序中运行的线程实例数量。
平均程序执行时间：应用程序各模块的平均执行时间。
堆内存使用率：应用程序中Java虚拟机（JVM）分配的内存占用的百分比。
平均延迟时间：从请求到响应开始的时间差。
垃圾回收时间：在JVM中收集不再使用的内存对象所需的时间。
响应代码：HTTP请求成功或失败代码。
（3）业务层
重点关注业务运营的分析和结果，通过监控平台运营情况和各种配置，获取更多业务数据。及时发现行业发展趋势，指引业务方向，实现全方位监控、预测和干预。
GMV销售额：项目特定时间内总的销售额。
日活、月活：日活跃用户数、月活跃用户数
客单价：平均每个订单的金额
支付成功率：成功支付订单和总订单的比率
订单量：每次交易中的订单数量。
购物车转化率：加入购物车商品与实际付款之间的比率。
转化率：网站访客转化为潜在客户（注册、订阅、购买等）的百分比。
用户留存率：每月活跃用户数量与上月活跃用户数量的比率。
退款率：以退货所得的金额与总交易金额之间的比率。
每次交易的平均时间：从访问网站到交易结束的总时间。
每个访问的平均时间：用户在网站上花费的总时间除以有效付款数量。
启动错误率：应用程序在第一次启动时无法正确启动的次数。
平均执行时间：任务执行所需的平均时间。
异常数量：系统产生的错误、崩溃、死锁等数量。
页面加载时间和速度：网页从请求到加载的时间和速度。
点击率：网站广告点击率。
OK，我们了解了监控的一些大致概念，下面我们来介绍一下业界监控的主流框架。
监控系统的架构模式push推和pull拉两种模式。
Pull模式：可以根据需要定时获取数据，避免数据的多余传输，节约网络带宽和存储空间。也可以根据需要通过请求的方式，选定性地获取部分数据。它适用于对被监控对象的稳定性要求不高的场景。Pull模式核心消耗在监控系统侧，应用侧的代价较低。但是由于需要定时发送请求获取数据，对于需要实时响应的业务，Pull模式的数据传输速度难以达到。Pull模式需要能够处理推送事件的应用程序，因此需要有较高的成本和复杂性。
Push模式：该模式下被监控对象可以主动推送数据，监控客户端不需要发送请求，因此避免了网络负载。对于需要实时响应数据的业务，Push模式具有更高的传输效率和更佳的实时性。Push模式适用于稳定的网络环境，可以实现实时数据的快速传输但是Push模式核心消耗在推送和Push Agent端，监控系统侧的消耗相比Pull要小。被监控对象需要主动发送数据，因此不适用于对被监控对象要求较高的场景，如需要严格控制被监控对象的数据流量。
公司内部的监控系统来说，应该同时具备Pull和Push的能力才是比较合适的。
下面我们来看一下主流监控告警框架的对比
Zabbix（支持 pull/push 两种模式）：基于C语言开发, 是一种基于服务器-客户端体系结构开发的企业级监控软件。它允许监控各种网络服务，服务器资源和硬件。
优点是用户友好，易于部署和设置，具有插件式框架，可以灵活地满足不同的监控需求。它提供了丰富的图形化监控数据，具有高扩展性，用户可以轻松添加自定义功能。
缺点是功能强大，使用比较笨重，Zabbix的安装和部署需要更多的时间和资源。对于复杂的IT架构，Zabbix的配置难度较大,响应时间不够实时，对于实时性要求较高的应用场景可能不够理想。
Open-Falcon（push模式）：它是一种分布式、高性能的监控解决方案，它被用于大型的高可用性系统和广泛的云计算环境。
优点是轻量级，可以部署在物理机和虚拟机上，部署和配置足够简单。支持查询优化，支持多种数据源输入，具有简单和易于使用的图形化界面。
缺点是国内使用量较小，社区不够活跃。对于某些复杂的IT架构，Open-Falcon在准备和安装方面可能存在困难，针对不同需求经验丰富的开发人员需代码调整。
Prometheus（Pull模式）：go语言开发, 是可扩展的开源监控系统，用于收集存储多维度的时间序列数据。支持PromQL查询语言和提供的图形化展示工具，可视化和告警这些功能交由Grafana和Alertmanager等第三方产品来实现，拓展性强。功能上的简洁，作为一个轻量级的后起之秀，在性能和展示方面优势比较明显，对容器监控支持的非常好。
优点是可扩展性强，支持水平扩展，满足大规模监控需求。支持灵活的查询和查询语言，提供了丰富的查询函数和操作符。可以从不同的数据源收集数据，支持多维度数据聚合。可以轻松集成Alertmanager实现告警。
缺点是存储机制不够灵活，大规模数据的存储和处理存在压力，对运维工程师的技术水平要求较高。
OK，本文主要是简单介绍下了对于监控系统的一些业务需要，以及主流监控框架的简介，那么接下来我们主要是准对Prometheus进行学习。
好的，那我们下期见，记得三连➕关注哦！
