WEB监控体系之设备负载监控(来自深空老大)

第一次写和工做密切相关的文章,却无从下手,胡乱写起,纯当总结。

设备负载监控属于硬件级的基础监控,比设备基础监控粒度要粗一些,属于设备基础监控上一层的硬件监控,适合于数量较大、具备集群特性的硬件综合指标监控。固然,其监控数据来源仍为单机设备基础信息。php

单机基础硬件指标大概包括CPU使用率、内存使用率、磁盘I/O、磁盘空间使用率、网卡出入包量、网卡出入流量、平均负载等。那么各类业务逻辑可能对这些指标都会有所侧重,例如WEB服务器比较侧重CPU、包量、流量,而DB比较侧重磁盘I/O、CPU使用率,CACHE则更关注内存使用率、CPU使用率等。对于数量庞大、类型不一的服务器,不可能关注到这么细致的数据信息,因此必须在几个维度进行汇总以便更好实现服务器管理。算法

那么设备负载监控系统的设计目标是什么呢?大概总结有如下几点:
一、减小管理单元,提升维护效率;
二、方便查看业务整体负载情况;
三、尽快发现高负载设备以便及时增长设备缓解业务压力;
四、减小空闲设备量,提升设备复用率,下降设备成本;
五、发现负载均衡方面的问题服务器

要实现以上几个目标,首先须要将服务器分门别类。如WEB、DB、CACHE、业务逻辑等。上面提到,这些设备应该具有集群特性,其大概形式以下:
负载均衡

集群示意图

集群示意图运维


如上图所示,除灰色部分外,该集群拥有4台同样的设备,每台设备上均安装有一、二、3三种软件,这样这些设备的正常运行情况应该基本一致。当该集群呈现负载较繁忙的情况的时候,能够比较容易复制1-4号设备以增长一台同样的5号设备来下降业务负载。而当该集群负载较空闲的时候,能够将第4号软件部署于该集群下以充分利用设备性能。

在该集群负载均衡的情况下,单机的负载情况表现出来的特征,应该就是该集群的负载特征,经过管理集群便可映射到管理单机设备,假设有1000台设备,每一个集群50台,那么只须要管理20个集群便可,管理单元明显减小。性能

在现实状况下,其实没法达到百分百负载均衡,因此仍是须要一些算法计算集群的指标。最基本的算法就是MAX、MIN、AVG了。这三个基本能够处理90%以上状况。我曾经设计过比较复杂的公式支持,后来发现基本上用不上。固然算法越粗暴偏差越大。如使用MAX计算CPU使用率,那么假如该集群下某台设备因为特殊缘由CPU一直占用较高,那么表如今集群上的CPU使用率也会较高,而实际状况可能这个集群相对空闲。而使用AVG求平均数值,那么一些异常设备将会被淹没不能及时发现,因此这里须要根据业务特性作一些权衡和取舍。固然不建议使用更复杂的算法,由于配置维护成本比较高,并且数值计算结果不直观。优化

为了修正个别设备引发集群高负载的问题,引入了高负载设备数的指标。假如该集群负载较高且高负载设备数也高于某个比例(如50%)则认为该负载值准确描述集群压力情况。spa

接下来看看实际指标的计算方法。设计

首先是负载值的定义。考虑到单机指标太多,业务复杂,因此一概是用百分比来反映负载情况。如10%负载、80%负载、200%负载等。这样单位统一直观。而不须要去考虑具体单位和具体数值。以CPU使用率为例,假设当CPU使用率为80%的时候,负载为100%,那么将80定义为CPU使用率的基准值,当CPU使用率为40%的时候,计算出来的负载为50%,而当CPU使用率为100%时,计算出来的负载为125%。一样其余指标须要定义一些基准值作为负载100%的值。例如百M网卡定义80M为100%负载等。code

这样单机全部基础指标都可以使用百分比表示,CPU使用率、内存使用率、磁盘I/O、磁盘空间使用率、网卡出入包量、网卡出入流量等均换算成负载比例,根据设备所属类型(WEB、DB、CACHE、逻辑等)设计权重结合计算公式获得单机负载值,如:

单机负载 = AVG(CPU使用率*权重/CPU使用率基准,出流量*权重/出流量基准…);

实际上单机负载的做用只在于计算高负载设备数。由于这样的计算方式累加到集群中的负载值偏差会偏大。为了修正这一问题,引入集群指标负载的概念,即:集群的CPU使用率负载、集群流量负载等,因为同一集群的各项指标较相近,这样将同类型指标进行叠加,减小偏差,其公式以下:

集群CPU使用率负载 = AVG(设备1CPU使用率/CPU使用率基准,设备2CPU使用率/CPU使用率基准,…);

从业务结构上看,会有以下关系图:

逻辑结构示意图

逻辑结构示意图

以上为现阶段使用的计算关系图,还有另一种偏差较大的关系图以下:

单机管理关系图

单机管理关系图


上图设备负载计算主要用于单机负载管理上,实际从单机负载直接计算集群负载的偏差会较大,因此通常会采用前一种计算逻辑。不过视图2还能较为直观反映某一集群的负载均衡问题。

实际上负载监控的做用远远高于其起初设计目标。随着业务的增加,能够看到集群负载也随之增加,虽然有波动,可是经过计算后仍会随着业务增加表现出增加趋势,那么系统就能够根据近一段时间内的负载增加情况,结合业务实际增加情况,预测出将来该集群所要达到的负载值,当超过一个临界值的时候(如80%负载),能够有计划的实行扩容操做(增长设备),而不是等到业务忽然呈现高负荷、稳定性下降的时候,才紧急进行设备扩充。

关于负载预测,我在以前有提到过,我是使用线性回归方法计算的,其中最小二乘法计算公式以下:

最小二乘法公式

最小二乘法公式


下面代码简单枚举历史10个点来计算该设备负载增加率:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//Y坐标值表示设备历史负载
$y = array (52.09, 52.4, 53.29, 54.22, 55.15, 55.83, 56.89, 56.98, 57.55, 57.8);
  
//X坐标值表示顺序天数
$x = array (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
  
//计算X和Y均值
$ax = array_sum ( $x )/ count ( $x );
$ay = array_sum ( $y )/ count ( $y );
  
//计算斜率公式中的分母(em)和分子(ez)
$em = 0;
$ez = 0;
for ( $i = 0; $i < count ( $x ); $i ++) {
     //分母求和
     $em += (( $x [ $i ] - $ax ) * ( $y [ $i ] - $ay ));
     //分子求和
     $ez += pow(( $x [ $i ] - $ax ), 2);
}
  
//斜率0.69
echo $em / $ez ;
  
//第十一个点预测负载值58.34
echo $em / $ez * 10 + $ay - ( $em / $ez )* $ax ;

理想情况下,将负载维持到一个稳定的值,使得设备使用率达到最高,且业务稳定正常,是一个长期的调整过程,经过不断的增减设备--增长设备以下降负载,减小设备以提升设备使用率,下降设备成本。这是一个多方面的协调工做,不是一个负载监控系统能解决的,可是负载监控提供基础的数据支持,可大大提升业务稳定性,减小突发故障,从而提升业务可用性。这里基本须要一些辅助功能的支持:
一、经过每日高、低负载设备数累计季度总高、低负载设备数来考核运维人员,以便及时处理高、低负载设备,将集群负载维持在一个相对稳定的范围,并消除明显的负载不均衡情况;
二、每日处理重点业务高负载设备,或者负载异常设备,提升业务稳定性。一般负载异常每每能反应软件故障,如CPU使用率一直100%而流量很是低,则多是软件BUG致使,及时推进开发人员处理软件BUG或者优化软件以提升设备使用率和增长业务可用性;
三、定时、有计划的(如一个月一次)对高负载集群进行设备扩充,能大大下降临时扩充设备的维护成本,并减小临时资源池设备量以下降设备成本;
四、定时对低负载集群进行合并、下线,减小集群数从而减小管理单元,并增长设备利用率以下降设备成本;
五、系统建设初期还会涉及到覆盖率问题,及时分享业务的负载监控覆盖率,推进业务运维接入,以便能实现100%覆盖,以提升监控能力。

那么,在系统建设过程当中还会碰到哪些问题呢?可能基础数据准确性是个比较重要的问题。因为单机设备硬件基础指标在一天内波动可能会比较大,因此须要对一天所采集到的基础数据进行处理,如消峰、去毛刺,将一些明显异常点去除,取一个较高点作为采集结果数据,以避免获得一些高得恐怖的负载值。负载监控在实时性要求上并无特别的高,对于长期优化目标来看,只须要按天粒度便可,固然因为其计算的合理性,逐渐提升其监控及时性,如按小时监控粒度,以便能更及时的了解到业务运行情况,这种状况通常用在业务放量、新业务上线、设备扩充后的负载实时监控上,以便做出更快的反应。

另外在集群的划分、归属、分类、合并、共享上,也就是基础配置、关系数据上须要比较细致的维护,目标是作到尽量的标准化,各个集群既要功能单一独立,在横向上具备强的可扩充性(图1横向),又要可以提供公用以提升设备复用率,如多个集群的合并(图1纵向)。这个涉及到各个业务逻辑的设计,推进业务逻辑按照这种方向进行部署,这样在自动扩容上能达到更好的效果。当集群负载达到必定的数值,会自动调度设备缓冲池里的设备,根据已有的集群内设备的软件配置,自动初始化并接入业务运营,以达到设备自动调度扩充的能力。

负载监控做为一个长期性和及时性兼顾的监控系统,不只在提升业务长期稳定性上发挥重要做用,更在预算、成本优化上提供了很是有力的数据支持,并且在将来自动调度扩容的可行性上给出了明朗的答案,是一个衔接业务监控和基础硬件监控的重要基础监控系统。

相关文章
相关标签/搜索