当前位置: 澳门新濠3559 > 操作系统 > 正文

澳门新濠3559每次收到之后你可以立即评估影响的

时间:2019-11-28 21:09来源:操作系统
故事的开头是这样的: 告警的本质 没有多少系统的告警是设计得当的。良好的告警设计是一项非常困难的工作。如何知道你收到的告警是糟糕的?多少次你收到了告警之后,立即就关

故事的开头是这样的:

告警的本质

没有多少系统的告警是设计得当的。良好的告警设计是一项非常困难的工作。如何知道你收到的告警是糟糕的?多少次你收到了告警之后,立即就关掉了的?是不是成天被这些然而并没有什么卵用的东西给淹没?最常见的告警设置:cpu使用率超过90%,然后告警。这种设置在大部分场合下是没有办法提供高质量的告警的。

高质量的告警应该是这样的:每次收到之后你可以立即评估影响的范围,并且每一个告警需要你做出分级响应。所谓每个告警都应该是,actionable的。

告警的实质可以用下图表明:

澳门新濠3559 1

服务器的设计应该是以这样的无人值守为目的的。假设所有的运维全部放假了,服务也能7*24自动运转。

澳门新濠3559 2

告警的实质就是“把人当服务用”。在一些事情还没有办法做到程序化执行的时候,用告警通知人的方式去干预系统达到修正的目的。一次告警就像一次服务调用一样。如果告警了,但是收到告警的人并不需要做任何处理,那么这就是一种DDoS攻击,攻击的是运维的幸福生活。

很多时候,告警通知人去干的事情是真的可以被自动化掉的。比如服务器挂了,换一台上来。在小一点的系统里,可能就是停机一会,人工来处理换一台冷备的机器上去。大一点的系统,因为服务器多了,天天都挂可不行,必须是热备的,系统自动切换到备机。再大一点的系统,因为切换实在太频繁了,故障机的退库,备机的保有都变成了一种管理负担,那么可以和其他的运维流程打通变成完全自动化的系统。只是因为业务处理不同阶段,选择不同的实现策略而已。业务量小,拿血肉当机器用,有的时候更经济而已。当然对于那个被当成机器人来用的哥们来说,生活确实有点不公平。

来源:

redis默认是单线程运行的,为了充分利用机器的cpu,正常情况下一台服务器上会装多个实例。如果通过top命令监控机器的cpu的话,监控值很笼统,不能精确到单redis实例的cpu使用率监控。而且centos 7.0通过top监控整体cpu的使用率并不准确。所以需要使用其它方式监控cpu。

一天我正在吃饭,突然就收到了服务器告警(cpu high load),吓的我饭也没吃好,只吃了三碗就回去处理故障了,我在监控上看到了这样子的图:

告警对象

告警对象可以分为两种:

  • 业务规则监控
  • 系统可靠性监控

对于业务规则监控可以举一个游戏的例子。比如DNF的游戏角色在一定装备的情况下,单次打击的伤害输出应该是有一个上限,如果超过了就说明有作弊的情况。又比如斗地主游戏里一个人的连胜场次是有一定上限的,每天的胜率是有一定上限,如果超出平均值太多就可能是作弊。业务规则监控的不是硬件,也不是软件是否工作正常。而是软件是否按照业务规则实现的,是否有漏洞。也可以理解为对“正确性”的监控。

系统可靠性监控是最常见的监控形式,比如发现是不是服务器挂掉了,服务是不是过载了等等。对于大部分后台服务,系统可以抽象建模成这个样子:

澳门新濠3559 3

对于这样的系统可以采集什么指标?

  • 请求数,请求到达速率
  • 正常响应数,正常响应占比
  • 错误响应数,错误响应占比
  • 响应延时
  • 队列长度,排队时间

实际的情况是,几乎任何系统都不是孤立运行的。而是这样的:

澳门新濠3559 4

一个DB会依赖于底层的cpu,内存,磁盘等资源。一个Http服务会依赖于底层的DB服务。一个应用会依赖于数个底层的RPC服务。于是又多了几个指标

  • 资源A的调用量(比如CPU使用率)
  • 资源B的调用量(比如内存分配和释放)
  • 资源C的调用量(比如网络发送包量)
  • ...

这种层次结构,一般来说简单来说可以分为四层:

  • 产品策略和营销:它们决定了根本的请求到达的速率
  • 应用层(更粗俗一点可以叫web层):最上层的胶水
  • 服务层:db,各种RPC服务,以及层层嵌套的服务
  • 硬件层:cpu,内存,磁盘,网络

澳门新濠3559 5

因为这样的一个依赖层次。上一层对下一层的资源消耗量变成了下一层的请求数。比如Http服务消耗了多少DB的资源,就对应了DB服务需要处理多少请求数。DB繁忙与否取决于Http服务请求,Http服务请求繁忙与否取决于多少人打开客户端,多少人打开客户端又取决于产品策略和营销活动。这种层次结构决定了单纯跟踪一个指标,比如绝对请求数,很难说明这一层的服务是否出现了故障。

有这么多层次,每层又有很多指标可以采集。那么应该采集什么指标,用什么告警策略去告警呢?最前面已经提到了告警必须是actionable的,但是实际情况下只有这种纲领性要求仍然是不好操作的。至少可以提几点不应该做的事情:

  • 不应该用采集的难度决定你使用什么指标去告警。很多情况下cpu使用率可能是最好采集的,但是未必是最值得告警的。
  • 不要给运维他们想要的告警,而是要做“真正”想要的告警。大部分情况下,人们告诉你的是一个解决方案。运维告诉你它需要对db进程的cpu使用率超过x%的时候告警,它给你的是一个他认为最优的解决方案。但是他真正想要的是知道db服务是否有异常,cpu使用率超过x%未必是最好的告诉你服务是否出现异常的指标。

盲目地采集那些容易获取的指标,并随意地设定阈值告警是大部分糟糕的告警质量的根源。

这篇文章主要介绍了shell脚本监控系统负载、CPU和内存使用情况,本文分别给出监控服务器系统负载情况、监控系统cpu使用情况、、监控系统内存情况、监控系统交换分区swap使用情况的脚本,需要的朋友可以参考下

进入redis实例

澳门新濠3559 6

监控的指标和策略

那到底应该采集什么指标呢?我认为大部分的系统可靠性监控不外乎三个目标:

  • is the work getting done?系统是否在持续完成其设定的工作。
  • is the user having good experience?用户体验是否好。
  • where is the problem/bottleneck?问题或者瓶颈在哪里。

其中最核心最关键的是第一个问题,is the work getting done。对于数据库来说,我们可以采集:

  • cpu 使用率
  • 网络带宽大小
  • db请求数
  • db响应数
  • db错误响应数
  • db请求延迟

显然要回答一个db是否完成了其指定的工作,更应该关注的指标是这两个:

  • db请求数的绝对量
  • db正确响应相对请求数的占比

这两个指标相对于采集什么cpu使用率更能说明问题。不仅仅是db,各个层次的服务都可以用请求量和正确响应占比来反映其工作状况。比如http请求数(对比http正确响应数),比如app打开次数(对比服务端记录的在线人数)等等。

为什么cpu使用率不能说明问题?大部分时候,我们并不关心cpu本身,而关心使用cpu为资源的服务。所以cpu使用率只是一种资源的请求数而已。与请求数相关的一个概念是saturation(上限),当上限达到的时候,处理开始排队,延迟开始变长,错误率开始升高。那么cpu使用率是不是能够说明上限呢?cpu使用率的上限以100%记,那么90%开始告警不是很合理吗?毕竟cpu 100%了几乎可以等同于db无法正常处理请求了。

这种利用底层资源调用量,评估其是否达到上限的做法有两个根本缺陷:

  • 你无法知道上层服务可以把底层资源利用到什么程度
  • 底层资源的 saturation 未必可以容易度量

具体来说,db是不是可以真的100%利用cpu是位置的。假如请求里锁,或者sleep,那么也许cpu永远也无法达到100%。90%可能就是极限了。而且现代的cpu是多核的,如果请求处理只能利用单核,处理在多个核之间跳跃,对于一个核来说永远也不会一直保持100%。

对于cpu可能其上限真的有一个100%的值。但是对于很多非硬件的服务,比如你是一个登陆服务,依赖于一个db。那么这个db每秒可以处理的不同sql组合数是很难度量的,绝非和磁盘一样有一个mb/s的极限绝对值可以做为对比。

而且度量底层资源的使用还有一个缺陷是你无法枚举出所有依赖的资源的。所以与其这么绕弯子地通过底层资源来间接监控上层服务是否正常,还不如直接测量work是不是getting done呢。

对于第二个问题,is the user having good experience?可以采集的指标为

  • 平均排队时间,平均总响应延迟
  • 99/95/90 percentile的排队时间,99/95/90 percentile的响应延迟

这里的用户不一定是指人或者玩家,可能是上一层的服务调用方,另外一个系统。

第三个问题就是所谓的故障定位。要是人工来做的话,最常见的做法是收到了告警,然后登陆CRT,开始敲各种命令查找原因。对于系统来说,最合适的做法不是出了问题再去执行一堆命令,而是:

  1. 每个层次都对自己做告警
  2. 顶层服务出了告警触发自动定位程序
  3. 按照服务的依赖关系和大致的时间范围,定位到告警之间的关联,从而找到出问题或者瓶颈的地方

当然实际情况是很复杂的。很多原因和结果是互为因果的。两个告警是两个现象,还是一个原因一个现象实际上很难说得清楚。

从告警算法的角度来讲,对成功请求率,或者平均响应延迟做告警是非常容易的。静态阈值大家看不起,觉得简单。但是大部分告警用静态阈值就可以解决问题。

在没有nagios监控软件的情况下,只要服务器能上互联网,就可通过发邮件的方式来提醒管理员系统负载与CPU占用的使用情况。
一、安装linux下面的一个邮件客户端msmtp软件(类似于一个foxmail的工具)
1、下载安装:

澳门新濠3559每次收到之后你可以立即评估影响的范围,吃饭那段时间cpu一下子就剩下50%了。代码如下:

127.0.0.1:36379> info cpu
# CPU
used_cpu_sys:2187.88
used_cpu_user:1842.28
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

看见了吧,吃饭那段时间cpu一下子就剩下50%了。。。。

理论与现实

那告警要不要高难度的算法?我的观点是采集到了正确的指标,是不需要复杂算法的,就是静态阈值都可以搞得定。但是至少有三种场合需要算法:

  • 无法直接采集到错误数:需要对错误日志的自动分类
  • 无法直接采集到请求成功率:需要对请求数或响应数的绝对值做异常检测
  • 只有总数,无法采集到其中的每个细分构成项的占比:需要对参与的factor进行算法拟合

其实这三项都是一个主题的,当你无法直接获取到告警所需的指标的时候,事情会变得复杂很多。有一个比喻是:最近NASA宣布的地球孪生兄弟Kepler 452b。如果我们的探测器可以跑到1400光年之外,发现他将是非常容易的事情。正式因为直接获得数据非常困难,所以科学家才需要根据行星阻挡恒星时引起的亮度变化(所谓掩星法)来发现这些遥远的星球。

采集所需的指标的困难可能是几方面的因素。一种原因是采集本身是非常消耗资源的事情。比如获取每个mysql查询所消耗的cpu。跟踪每个请求处理过程是不可能的。这个时候就需要算法的帮助了,可以仔细看一下vividcortex的视频:

更多情况是采集指标困难是D/O分离造成的沟通问题,运维需要的指标需要开发去埋点,而开发埋点的地方又需要运维去做告警。很多时候退而求其次就会造成,有什么指标就用什么指标的状况。比如虽然没有请求响应的错误数,但是错误基本上都会有错误日志记录,根据错误日志滚动的快慢可以大致知道是不是出了问题。这就引入了一个非常困难的日志分类问题,什么日志代表了正常,什么日志代表了异常,异常又非了哪些类型?这个方面算法做得好的是summo logic公司: 。为什么这种opsdev(嘲讽devops那)公司如此热衷于算法?对于他们来说好处是显而易见的,客户需要做的改动越少,接入成本越低,客户面就越广。但是拿机器算法去挖掘海量日志真的是回答:is the work getting done?的最佳手段?显然不是。这就是大炮打蚊子。日志的存在是用于解决问题,而不是有了海量日志了,如何用好“它们”变成了问题本身。

第三类情况是没有办法采集到请求成功率,只能对绝对的处理成功的量。只有这类数据要告警,就无法做简单的静态阈值了。对于延迟,一般可以定一个业务上可以接受的延迟上限。对于成功率,也可以定一个可接受的成功率上限。但是对于绝对的处理量,是没有办法简单地比较一个静态阈值就可以判断是正常还是异常的。

在讨论如何实现之前,再强调两点:

  • 处理成功的量不是度量is work getting done的最佳指标。费事费力去搞算法,不如直接把成功率指标给采集了。
  • 处理成功的量,还取决于请求数。而请求数根本上是取决于上层服务了。你是一个dba,发现db的每秒处理的请求数陡降了。这说明是db故障了?还是app故障了?都有可能……最最上层是产品和营销。你发现一个业务的注册量相对前几天变少了,这个是不是说明注册服务出问题了?也需是产品太烂了,游戏根本没有人来玩。也可能是营销手段的营销,不送金币了,玩家没积极性了。
# tar jxvf msmtp-1.4.16.tar.bz2
# cd msmtp-1.4.16
# ./configure --prefix=/usr/local/msmtp
# make && make install

其中:

 

异常检测

只有请求数,没有参考的上限值(saturation),也没有成功率,没有失败率,怎么检测异常?

澳门新濠3559 7

上图的黄线是昨天的值,绿线是今天的值,大部分服务监控的曲线图都长这样。可以得出四个思路:

  • 曲线平滑:故障一般是对近期趋势的一个破坏,视觉上来说就是不平滑
  • 绝对值的时间周期性:两条曲线几乎重合
  • 波动的时间周期性:假设两个曲线不重合,在相同时间点的波动趋势和振幅也是类似的
  • 有一个长度可观的坑:当曲线开始回升到历史范围的时候,一般可以确认这个时间段是真的故障了

从这四种直觉展开,可以得出各种或复杂或简单的算法。下面要讲的算法都是非常简单的,无需很高深的数学知识。

2、创建msmtp配置文件和日志文件(host为邮件域名,邮件用户名fuquanjun,密码fuquanjun)
代码如下:

used_cpu_user:redis进程指令在用户态所消耗的cpu时间,该值为累计值(秒)
used_cpu_sys:redis进程指令在核心态所消耗的cpu时间,该值为累计值(秒)

然后再进系统看看top有没有什么异常:

基于曲线的平滑性的检测

这种检测的根据是在一个最近的时间窗口,比如1个小时。曲线会遵循某种趋势,而新的数据点打破了这种趋势,使得曲线不光滑了。也就是说,这种检测利用的是时间序列的temporal dependency,T对于T-1有很强的趋势依赖性。业务逻辑上来说,8:00 有很多人登陆,8:01 也有很多人来登陆的概率是很高的,因为吸引人来登陆的因素是有很强的惯性的。但是7.1很多人来登陆,8.1也有很多人来登陆的惯性就要差很多。

基于近期趋势做告警,就需要对曲线的趋势进行拟合。拟合有两种方式,moving average 或者 regression。这两种拟合方式有不同的bias(倾向)。

澳门新濠3559 8

这就是一种moving average的算法图,叫做exponentially weighted moving average。它的计算非常简单

澳门新濠3559 9

x是实际值,s是ewma计算出来的平均值。也就是下一点的平均值是由上一点的平均值,加上当前点的实际值修正而来。这个修正的比例,就取决月这个alpha的decay factor的大小。视觉上来说就是ewma曲线是否紧跟实际曲线,也就是平滑程度。

澳门新濠3559 10

有了平均值之后可以计算方差,方差乘以一定的倍数可以得出对于振幅的容忍范围。比较实际的值是否超出了这个范围就可以知道是否可以告警了。超出了上界,可能是突然用户量突然激增了。超出了下届,可能是营销活动结束了,用户快速离开,也可能是光纤断了,玩家掉线了。想要了解更多关于ewma的算法细节:关注Baron Schwartz(http://www.slideshare.net/vividcortex/statistical-anomaly-detection-fo...)

moving average认为曲线是趋向于历史的,如果曲线的势头是上升,那么它认为下一个点应该是开始下降的。regression认为曲线是趋向于未来的,如果曲线的势头是上升,那么它认为下一个点应该是保持这个上升势头。还有更复杂的模型是综合了moving average和regression的。无论是哪种算法,用过去10分钟预测下10分钟是不可能精确的。如果这种预测可以精确,那么股神早就诞生了。使用moving average,可能会掩盖故障产生的下降(因为其bias是下降)。如果使用regression,那么又有可能把没有上升得那么快当成故障了(因为其bias是上升)。

这种基于近期趋势计算方差的算法还有一个缺陷是当前面几个点振动很大的时候,方差值会被搞大。后面的故障就被掩盖了,使得连续的故障点无法被检测到。其实也就是算法对于什么是正常是没有概念的,它认为过去的历史就是正常。如果过去几分钟处于故障中,那么故障的曲线就是正常。

实际使用中发现这种基于曲线平滑度的算法的优点有

  • 依赖的数据少,只需要近期的历史,不依赖于周期性
  • 非常敏感,历史如果波动很小,方差就很小,容忍的波动范围也会非常小

缺点也是显著的

  • 过于敏感,容易误报。因为方差会随着异常点的引入而变大,所以很难使用连续三点才告警这样的策略
  • 业务曲线可能自身有规律性的陡增和陡降

最佳的使用方式是不用一根曲线做告警。结合几条相关的曲线,如果同时出现平滑度破坏的情况,而且与业务规律的趋势相背离(比如在线人数降低,登陆请求数增高)则可以认定为业务出现故障。

# vim /root/.msmtprc
account default 
host xxxxx.com 
from fuquanjun@xxxx.com 
auth login 
user fuquanjun 
password fuquanjun 
logfile ~/.msmtp.log
# chmod 600 /root/.msmtprc
# touch ~/.msmtp.log

used_cpu_sys_children:redis后台进程指令在用户态所消耗的cpu时间,该值为累计值(秒)

澳门新濠3559 11

基于绝对值的时间周期性

澳门新濠3559 12

上图中不同的颜色代表了不同日期的曲线。很多监控曲线都有这样以一天为周期的周期性(早上4点最低,晚上11点最高之类的)。一种利用时间周期性的最简单的算法

min(14 days history) * 0.6

对历史14天的曲线取最小值。怎么个取最小值的方法?对于12:05分,有14天对应的点,取最小值。对于12:06分,有14天对应的点,取最小值。这样可以得出一条一天的曲线。然后对这个曲线整体乘以0.6。如果几天的曲线低于这条参考线则告警。

这其实是一种静态阈值告警的升级版,动态阈值告警。过去静态阈值是一个根据历史经验拍脑袋的产物。用这个算法,其实是把同时间点的历史值做为依据,计算出一个最不可能的下界。同时阈值不是唯一的一个,而是每个时间点有一个。如果1分钟一个点,一天中就有1440个下界阈值。

实际使用中0.6当然还是要酌情调整的。而且一个严重的问题是如果14天历史中有停机发布或者故障,那么最小值会受到影响。也就是说不能把历史当成正常,而是要把历史剔除掉异常值之后再进行计算。一个务实的近似的做法是取第二小的值。

为了让告警更加精确,可以累积计算实际曲线和参考曲线的差值之和。也就是相对于参考曲线下跌的面积。这个面积超过一定的值则告警。对于深度下跌,则累积几个点就可以告警。对于浅度下跌,那么多累几个点也可以告警出来。翻译成人话就是,一下在跌了很多,则很有可能是故障了。或者连续好久都偏离正常值,那么也很有可能是出问题了。

优点:

  • 计算简单
  • 可以确保发现大的故障,出了告警一定是大问题,可以直接打电话

缺点:

  • 依赖周期性的历史数据,计算量大,而且无法对新接入的曲线告警
  • 非常不敏感,小波动无法发现

3、mutt安装配置:(一般linux下有默认安装mutt)
如果没有安装,则使用yum安装
代码如下:

used_cpu_sys_children:redis后台进程指令在核心态所消耗的cpu时间,该值为累计值(秒)

 

基于振幅的时间周期性

澳门新濠3559 13

有些时候曲线是有周期性,但是两个周期的曲线相叠加是不重合的。比如上图这样的,曲线整体的趋势是网上的。两个周期的曲线一叠加,一个会比另外一个高出一头。对于这种情况,利用绝对值告警就会有问题。

比如今天是10.1日,放假第一天。过去14天的历史曲线必然会比今天的曲线低很多。那么今天出了一个小故障,曲线下跌了,相对于过去14天的曲线仍然是高很多的。这样的故障如何能够检测得出来?一个直觉的说法是,两个曲线虽然不一样高,但是“长得差不多”。那么怎么利用这种“长得差不多”呢?那就是振幅了。

与其用x(t)的值,不如用x(t) - x(t-1)的值,也就是把绝对值变成变化速度。可以直接利用这个速度值,也可以是 x(t) - x(t-1) 再除以 x(t-1),也就是一个速度相对于绝对值的比率。比如t时刻的在线900人,t-1时刻的在线是1000人,那么可以计算出掉线人数是10%。这个掉线比率在历史同时刻是高还是低?那么就和前面一样处理了。

实际使用中有两个技巧:可以是x(t) - x(t-1),也可以是x(t) - x(t-5)等值。跨度越大,越可以检测出一些缓慢下降的情况。

另外一个技巧是可以计算x(t) -x(t-2),以及x(t+1) - x(t-1),如果两个值都异常则认为是真的异常,可以避免一个点的数据缺陷问题。

优点:

  • 比绝对值要敏感
  • 利用了时间周期性,规避了业务曲线自身的周期性陡降

缺点:

  • 要求原曲线是光滑的
  • 周期性陡降的时间点必须重合,否则误警
  • 按百分比计算容易在低峰时期误警
  • 陡降不一定代表故障,由上层服务波动引起的冲高再回落的情况时有发生

这种异常告警算法是比较优秀的。缺点也很多。所以可以进行一些修补凑合用。为了避免低峰时期,基于振幅百分比容易误警,可以加入绝对振幅的下限。业务上来说,就是小波动如果相对比率大,但是绝对影响范围小也是没关系的。对于冲高回落的问题,可以判断一下冲高的情况,对于冲高之后屏蔽一段时间。

yum -y install mutt
# vim /root/.muttrc
set sendmail="/usr/local/msmtp/bin/msmtp" 
set use_from=yes 
set realname="moniter" 
set from=fuquanjun@xxx.com 
set envelope_from=yes 
set rfc2047_parameters=yes 
set charset="utf-8"

redis进程单cpu的消耗率可以通过如下公式计算:

 

基于曲线回升的异常判断

澳门新濠3559 14

澳门新濠3559 15

当我们看见图2的时候比图1更确认是故障了。为什么?因为图2中有一个明显的回升。算法其实和人眼一样。如果多等几个时间点,发现曲线回升了可以更很准确地判断“曾经”有一个故障。但是这种基于回升的异常检测是没有多少“告警”意义上的机制的。告警的作用就是让人参与干预,去帮助曲线回升。如果曲线已经开始回升,再告警不是事后诸葛了吗?

这种检测的意义在于机器复制告警的确认。当我们需要统计误警率,漏警率的时候。用另外一种视角的算法重新跑一遍可以统计出很多原算法的问题。同时也可以用半自动化的方式建立一个历史故障的样本库。这个样本库可以变成更复杂的机器学习算法的训练集。

4、邮件发送测试(-s邮件标题,-a表加附件)
代码如下:

((used_cpu_sys_now-used_cpu_sys_before)/(now-before))*100

 

总结

Key take away

  • 高质量的告警是actionable的
  • 不应该用采集的难度决定你使用什么指标去告警
  • 不要别人做什么告警,你就做什么,要做“真正”有用的告警:特别是cpu使用率告警
  • is work getting done:请求数 + 成功率
  • is the user having good experience:响应延迟
  • 只要采集对了指标,大部分时候告警不需要复杂算法
  • 基于算法的异常检测:算法不难,实在必要也是可以做到的

原文 

# echo "邮件内容123456" | mutt -s "邮件标题测试邮件" -a /scripts/test.txt fuquanjun@xxxx.com

可以通过下面的方式计算告警值:
(used_cpu_sys_now-used_cpu_sys_before)/(now-before)<0.9

 

出现下面报错信息:
代码如下:

其中

当时圈圈时的值是很高的,所以就引入了AWS stolen CPU

msmtp: account default not found: no configuration file available

used_cpu_sys_now:now时间点的used_cpu_sys值

翻译过来就是,aws偷了我们的cpu.....

发送信件出错,子进程已退出 78 ()。
无法发送此信件。
解决方法:
单独使用msmtp发送测试:/usr/local/msmtp/bin/msmtp -S 发现是配置文件没找到
代码如下:

used_cpu_sys_before:before时间点的used_cpu_sys值

通俗的讲:

msmtp: account default not found: no configuration file available

假如aws给实例分配了100个资源,但是这些资源有时候被hypervisor用于处理其它任务,从实例角度来讲,资源被占用,cpu使用率升高。但是从aws的cloudwatch来讲,它允许实例使用100个资源,但实际上此实例并没有使用那么多。结果就是我们自定义的监控告警,而cloudwatch监控是正常的。

查看当前的配置文件路径:/usr/local/msmtp/bin/msmtp -P
代码如下:

 

ignoring system configuration file/work/target/etc/msmtprc: No such file or directory
ignoring user configuration file /root/.msmtprc: No such file ordirectory
falling back to default account
msmtp: account default not found: no configuration file available

反正aws也不地道啊,我不管,这就是超卖了,怎么解决?把实例stop & start了,这样实例可能会在新的物理机上启动,问题暂时解决。

故将/usr/local/etc/msmtprc 复制为/root/.msmtprc
查看一下mutt文件安装目录情况
代码如下:

我在想要不要提工单给aws,大牛说不用了,小型实例就这德行,传说中的便宜没好货。

rpm -ql mutt

故将/etc/Muttrc 复制为/root/.muttrc即可发送邮件。
二、监控服务器系统负载情况:
1、用uptime命令查看当前负载情况(1分钟,5分钟,15分钟平均负载情况)在苹果公司的Mac电脑上也适用
代码如下:

# uptime
15:43:59 up 186 days, 20:04, 1 user, load average: 0.01, 0.02, 0.00

"load average"意思分别是1分钟、5分钟、15分钟内系统的平均负荷。
(1) 主要观察"15分钟系统负荷",将它作为电脑正常运行的指标。
(2) 如果15分钟内,(系统负荷除以CPU核心数目之后的)平均负荷大于1.0,表明问题持续存在,不是暂时现象。
(3) 当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。
(4) 当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。
(5) 当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。
假设你的电脑只有1个CPU。如果你的电脑装了2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。
2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的电脑,可接受的系统负荷最大为n.0。
2、查看服务器cpu的总核数
代码如下:

# grep -c 'model name' /proc/cpuinfo 或者 cat /proc/cpuinfo

3、截取服务器1分钟、5分钟、15分钟的负载情况
代码如下:

# uptime | awk '{print $8,$9,$10,$11,$12}'
load average: 0.01, 0.02, 0.00

4、查看截取15分钟的平均负载
代码如下:

# uptime | awk '{print $12}' (用 '{print $12}' 这个获取的不够准确,如果都用awk取第12个字段的话,结果有可能为空了。而用$NF表输出最后一段的内容)
# uptime | awk '{print $NF}'

5、编写系统负载监控的脚本文件:
代码如下:

# vim /scripts/load-check.sh
[code]
#!/bin/bash 
#使用uptime命令监控linux系统负载变化 

#取系统当前时间(以追加的方式写入文件>>) 
date >> /scripts/datetime-load.txt 

#提取服务器1分钟、5分钟、15分钟的负载情况 
uptime | awk '{print $8,$9,$10,$11,$12}' >> /scripts/load.txt 

#逐行连接上面的时间和负载相关行数据(每次重新写入文件>) 
paste /scripts/datetime-load.txt /scripts/load.txt > /scripts/load_day.txt
# chmod a+x /scripts/load-check.sh

6、编写系统负载结果文件邮件发送脚本:
代码如下:

# vim /scripts/sendmail-load.sh
#!/bin/bash 
#把系统负载监控生成的load_day.txt文件通过邮件发送给用户 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#提取当前日期 
today=`date -d "0 day" +%Y年%m月%d日` 

#发送系统负载监控结果邮件 
echo "这是$IP服务器$today的系统负载监控报告,请下载附件。" | mutt -s "$IP服务器$today的系统负载监控报告" -a /scripts/load_day.txt fuquanjun@xxx.com
# chmod a+x /scripts/sendmail-load.sh

7、编写系统负载监控的脚本文件:
代码如下:

# vim /scripts/load-warning.sh
#!/bin/bash 
#使用uptime命令监控linux系统负载变化 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#抓取cpu的总核数 
cpu_num=`grep -c 'model name' /proc/cpuinfo` 

#抓取当前系统15分钟的平均负载值 
load_15=`uptime | awk '{print $NF}'` 

#计算当前系统单个核心15分钟的平均负载值,结果小于1.0时前面个位数补0。 
average_load=`echo "scale=2;a=$load_15/$cpu_num;if(length(a)==scale(a)) print 0;print a" | bc` 

#取上面平均负载值的个位整数 
average_int=`echo $average_load | cut -f 1 -d "."` 

#设置系统单个核心15分钟的平均负载的告警值为0.70(即使用超过70%的时候告警)。 
load_warn=0.70 

#当单个核心15分钟的平均负载值大于等于1.0(即个位整数大于0) ,直接发邮件告警;如果小于1.0则进行二次比较 
if (($average_int > 0)); then 
  echo "$IP服务器15分钟的系统平均负载为$average_load,超过警戒值1.0,请立即处理!!!" | mutt -s "$IP 服务器系统负载严重告警!!!" fuquanjun@xxx.com 
  else 
#当前系统15分钟平均负载值与告警值进行比较(当大于告警值0.70时会返回1,小于时会返回0 ) 
load_now=`expr $average_load > $load_warn` 

#如果系统单个核心15分钟的平均负载值大于告警值0.70(返回值为1),则发邮件给管理员 
  if (($load_now == 1)); then 
    echo "$IP服务器15分钟的系统平均负载达到 $average_load,超过警戒值0.70,请及时处理。" | mutt -s "$IP 服务器系统负载告警" fuquanjun@xxx.com
  fi 
fi
# chmod a+x /scripts/load-warning.sh

三、监控服务器系统cpu占用情况:
1、使用top命令查看linux系统cpu使用情况:
代码如下:

# top -b -n 1 | grep Cpu (-b -n 1 表只需要1次的输出结果)
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

2、查看截取空闲cpu的百分比数值命令(只取整数部分):
代码如下:

# top -b -n 1 | grep Cpu | awk '{print $5}' | cut -f 1 -d "."

3、编写cpu监控的脚本文件:
代码如下:

# vim /scripts/cpu-check.sh
#!/bin/bash 
#使用top命令监控linux系统cpu变化 

#取系统当前时间(以追加的方式写入文件>>) 
date >> /scripts/datetime-cpu.txt 

#抓取当前cpu的值(以追加的方式写入文件>>) 
top -b -n 1 | grep Cpu >> /scripts/cpu-now.txt 

#逐行连接上面的时间和cpu相关行数据(每次重新写入文件>) 
paste /scripts/datetime-cpu.txt /scripts/cpu-now.txt > /scripts/cpu.txt
# chmod a+x /scripts/cpu-check.sh

4、查看CPU监控的结果文件:
代码如下:

# cat /scripts/cpu.txt

5、编写cpu结果文件邮件发送脚本:
代码如下:

# vim /scripts/sendmail-cpu.sh
#!/bin/bash 
#把生成的cpu.txt文件通过邮件发送给用户 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#提取当前日期 
today=`date -d "0 day" +%Y年%m月%d日` 

#发送cpu监控结果邮件 
echo "这是$IP服务器$today的cpu监控报告,请下载附件。" | mutt -s "$IP服务器$today的CPU监控报告" -a /scripts/cpu.txt fuquanjun@xxx.com
# chmod a+x /scripts/sendmail-cpu.sh

四、监控系统cpu的情况,当使用超过80%的时候发告警邮件:
代码如下:

# vim /scripts/cpu-warning.sh
#!/bin/bash 
#监控系统cpu的情况脚本程序 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#取当前空闲cpu百份比值(只取整数部分) 
cpu_idle=`top -b -n 1 | grep Cpu | awk '{print $5}' | cut -f 1 -d "."` 

#设置空闲cpu的告警值为20%,如果当前cpu使用超过80%(即剩余小于20%),立即发邮件告警 
if (($cpu_idle < 20)); then 
  echo "$IP服务器cpu剩余$cpu_idle%,使用率已经超过80%,请及时处理。" | mutt -s "$IP 服务器CPU告警" fuquanjun@xxx.com 
fi
# chmod a+x /scripts/cpu-warning.sh

五、使用free命令监控系统内存:
1、使用free命令查看linux系统内存使用情况:(以M为单位)
代码如下:

# free -m 
total used free shared buffers cached
Mem: 3952 3414 538 0 168 484
-/+ buffers/cache: 2760 1191
Swap: 8191 86 8105

2、查看截取剩余内存free的数值命令:
(1) 物理内存free值: # free -m | grep Mem | awk '{print $4}'
(2) 缓冲区的free值: # free -m | grep - | awk '{print $4}'
(3) Swap分区free值: # free -m | grep Swap | awk '{print $4}'
3、编写内存监控的脚本文件:
代码如下:

# vim /scripts/free-mem.sh
#!/bin/bash 
#使用free命令监控linux系统内存变化 

#取系统当前时间(以追加的方式写入文件>>) 
date >> /scripts/date-time.txt 

#抓取物理内存free值(以追加的方式写入文件>>) 
echo Mem-free: `free -m | grep Mem | awk '{print $4}'`M >> /scripts/mem-free.txt 

#抓取缓冲区的free值(以追加的方式写入文件>>) 
echo buffers/cache-free: `free -m | grep - | awk '{print $4}'`M >> /scripts/buffers-free.txt 

#抓取Swap分区free值(以追加的方式写入文件>>) 
echo Swap-free: `free -m | grep Swap | awk '{print $4}'`M >> /scripts/swap-free.txt 

#逐行连接上面的时间和内存相关行数据(每次重新写入文件>) 
paste /scripts/date-time.txt /scripts/mem-free.txt /scripts/buffers-free.txt /scripts/swap-free.txt >

/scripts/freemem.txt
# chmod a+x /scripts/free-mem.sh

4、查看内存监控的结果文件:
代码如下:

# cat /scripts/freemem.txt

5、编写free结果文件邮件发送脚本:
代码如下:

# vim /scripts/sendmail-mem.sh
#!/bin/bash 
#把生成的freemem.txt文件通过邮件发送给用户 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#提取当前日期时间 
today=`date -d "0 day" +%Y年%m月%d日` 

#发送内存监控结果邮件 
echo "这是$IP服务器$today的内存监控报告,请下载附件。" | mutt -s "$IP服务器$today内存监控报告" -a /scripts/freemem.txt

fuquanjun@xxx.com
# chmod a+x /scripts/sendmail-mem.sh

六、监控系统交换分区swap的情况,当使用超过80%的时候发告警邮件:
代码如下:

# vim /scripts/swap-warning.sh
#!/bin/bash 

#提取本服务器的IP地址信息 
IP=`ifconfig eth0 | grep "inet addr" | cut -f 2 -d ":" | cut -f 1 -d " "` 

#系统分配的交换分区总量 
swap_total=`free -m | grep Swap | awk '{print $2}'` 

#当前剩余的交换分区free大小 
swap_free=`free -m | grep Swap | awk '{print $4}'` 

#当前已使用的交换分区used大小 
swap_used=`free -m | grep Swap | awk '{print $3}'` 


if (($swap_used != 0)); then 

#如果交换分区已被使用,则计算当前剩余交换分区free所占总量的百分比,用小数来表示,要在小数点前面补一个整数位0 
swap_per=0`echo "scale=2;$swap_free/$swap_total" | bc` 

#设置交换分区的告警值为20%(即使用超过80%的时候告警)。 
swap_warn=0.20 

#当前剩余交换分区百分比与告警值进行比较(当大于告警值(即剩余20%以上)时会返回1,小于(即剩余不足20%)时会返回0 ) 
swap_now=`expr $swap_per > $swap_warn` 

#如果当前交换分区使用超过80%(即剩余小于20%,上面的返回值等于0),立即发邮件告警 
if (($swap_now == 0)); then 
echo "$IP服务器swap交换分区只剩下 $swap_free M 未使用,剩余不足20%,使用率已经超过80%,请及时处理。" | mutt -s "$IP 服务器内存告警" fuquanjun@xxx.com 
fi 
fi
# chmod a+x /scripts/swap-warning.sh

七、加入任务计划:系统负载与CPU占用率每十分钟检测一次,有告警则立即发邮件(十分钟发一次),负载与CPU检测结果邮件每天早上8点发

一次。

代码如下:

# crontab -e
*/10 * * * * /scripts/load-check.sh > /dev/null 2>&1
*/10 * * * * /scripts/load-warning.sh 
0 8 * * * /scripts/sendmail-load.sh 

*/10 * * * * /scripts/cpu-check.sh 
*/10 * * * * /scripts/cpu-warning.sh 
0 8 * * * /scripts/sendmail-cpu.sh

*/10 * * * * /scripts/free-mem.sh 
*/10 * * * * /scripts/swap-warning.sh 
0 8 * * * /scripts/sendmail-mem.sh
# service crond restart

编辑:操作系统 本文来源:澳门新濠3559每次收到之后你可以立即评估影响的

关键词: