写在前面:所有告警处理流程都是先止损,再定位,要通告。
1. cpu.busy过高告警处理sop
(1)常见原因1:如果进程启动时间与故障发生时间一致,可以判定为服务启动导致
ps -o pid,lstart,cmd -p pid #查询进程的启动时间
实例:
登陆机器,输入ps -ef |grep java命令,找到对应的进程ID,然后输入ps -o pid,lstart,cmd -p 进程ID
解决办法:需观察一段时间(3min-5min)
(2)常见原因2:排查产生cpu idle异常的进程原因
通过top命令,查找目前占用cpu最大的进程;再次排查进程下相关线程的使用情况,top -Hp pid,找到CPU利用率最高的线
(3)常见原因3:排查虚拟机是否因超售,导致cpu steal问题(容器不存在该指标)
登陆跳板机:输入“gethost 机器域名”,就可以找到该机器对应的宿主机。
CPU steal是指在虚拟化环境中的一种现象,它指的是物理主机上的CPU资源被其他虚拟机抢占使用的时间。在虚拟化环境中,每个虚拟机都被分配了一定的CPU时间片,当物理主机上的CPU资源被其他虚拟机占用时,当前虚拟机在使用CPU资源时就会受到限制,这种限制就被称为CPU steal。
CPU steal通常是由于物理主机上的资源分配不均导致的,当物理主机上的虚拟机数量较多或者负载较高时,CPU steal的发生就会增加。CPU steal的存在可能会对虚拟机的性能产生负面影响,特别是对于需要大量CPU资源的应用程序。
监控和管理CPU steal对于保证虚拟化环境的性能和可靠性非常重要。管理员可以通过监控CPU steal来发现资源分配不均或者虚拟机负载过高的情况,并做出相应的调整,以提高系统的性能和稳定性。
2、coredump
coredump是指在程序运行时发生错误或异常导致程序崩溃时,操作系统将程序的内存状态保存到一个文件中,这个文件被称为core dump。这个文件包含了程序崩溃时的堆栈信息、内存状态和寄存器的值等,可以用于后续的调试和分析。通过分析core dump文件,开发人员可以确定程序崩溃的原因,并修复错误或异常。从core dump文件中,可以了解到程序在崩溃时的运行状态,从而有助于开发人员更好地理解问题的本质。在Unix和Linux操作系统中,可以使用调试工具如gdb来分析core dump文件: gdb java core文件。
备注:
如果coredump为单机的情况,和RD确认后禁用单机进行排查。 如果coredump为集群多台,临时下线一台进行排查。 |
3、cpu load告警
指标定义:
|
(1)常见原因1:如果进程启动时间与故障发生时间一致,可以判定为服务启动导致
解决办法:需观察一段时间(3min-5min)
(2)常见原因2:排查系统是否存在多个业务进程同时运行造成cpu负载升高
步骤一:排查容器或虚拟机运行程序个数
vmstat 1 5 # 动态显示进程,每一秒显示一次,只显示5次,自动结束
步骤二:排查是否存在异常进程
top命令
解决办法:联系相关服务负责人反馈是否存在服务部署不合理问题,是否需要扩容相关容器或虚拟机配置:提升CPU个数;
(3)常见原因3:因内存不足造成多个进程处于D状态,引起负载较高。
步骤一:排查是否存在多个D状态进程
top命令
步骤二:排查造成进程D状态原因
通过top命令查看服务器内存使用情况,内存使用过高导致其他进程不能正常使用内存,进入等待状态,从而导致cpu load上升。
top #进入后shift+M
解决办法:通过jmap等性能分析工具判断内存是否存在泄漏、优化代码;对机器内存进行升级,并联系相关服务负责人进行代码优化。
(4)常见原因4: 磁盘IO使用率过高,引起负载较高。
解决办法: 出现disk.io.util持续高于90%,需要进行容器迁移,再进行宿主机层面磁盘硬件排查;
4、icmp.ping.alive告警处理SOP
指标定义:【icmp.ping.alive】值为1:表示机器可以ping通;值为0:表示机器不能ping通(异常状态);无法ping通时,可以理解为机器宕机。
(1)常见原因1:宿主机层面的故障,查看同宿主机其他容器也有该问题---故障时段所有容器都出现监控指标异常,则可以认为是宿主机维度的故障。
如果是宿主机故障 需要迁移机器至好的宿主机中
(2)常见原因2:单机问题,同一宿主机上其他容器正常
解决方法:对单机进行重启
(3)验收环节:
(i)重启机器:重启后检查 icmp.ping.alive 监控指标是否恢复正常,检查节点是否正常承接业务流量
(ii)机器迁移:检查新机器 icmp.ping.alive 指标是否正常,是否正常承接业务流量,故障机器是否被自动下线
(4)回滚环节
重启、迁移机器均不可回滚
5、 jvm.fullgc.count告警处理SOP
适用场景:线上出现 jvm.fullgc.count告警,或fullgc触发间隔低于预期
适用环境:JDK 1.8
指标定义:
|
指标解释
(1)jvm.memory.nonheap.used.percent是一个指标,用于表示Java虚拟机(JVM)中非堆内存已使用的百分比。
非堆内存是JVM中除了堆内存以外的内存区域,用于存储JVM自身的数据结构和运行时数据。非堆内存包括方法区、直接内存等。
当jvm.memory.nonheap.used.percent接近100%时,表示非堆内存已经接近或达到了其最大容量,可能会导致OutOfMemoryError异常。此时,可以考虑增加非堆内存的大小,以避免内存溢出问题。
(2)jvm.memory.metaspace.used.percent是一个指标,用于表示Java虚拟机(JVM)中元空间(Metaspace)已使用的百分比。
元空间是JVM用于存储类元数据的区域,包括类的结构信息、常量池、方法信息等。与传统的永久代不同,元空间的大小是动态的,不再受限于固定的永久代大小。
当jvm.memory.metaspace.used.percent接近100%时,表示元空间已经接近或达到了其最大容量,可能会导致OutOfMemoryError异常。此时,可以考虑增加元空间的大小,以避免内存溢出问题。
(3)-XX:CMSInitiatingOccupancyFraction=60:设置CMS(Concurrent Mark Sweep)垃圾回收器的触发阈值。当老年代的占用达到该阈值时,将触发CMS垃圾回收。
常见原因1:Metaspace区占满导致Full GC
解决办法:
现象:jvm.memory.metaspace.used.percent接近100%,jvm.fullgc.count在短时间陡增。在GC日中可以查看到“Metadata GC Threshold”字样。
原因:Metaspace区被占满并且无法释放空间,导致不断Full GC。
解决办法:先扩大Metaspace内存上限,再通过分析类直方图定位根因。该问题常见于反射、字节码增强等技术的使用。!!!执行操作前务必先摘除服务流量!!!
通过参数"-XX:MaxMetaspaceSize="重新定义Metaspace上限,重启服务。
在Metaspace增长过程中多次执行以下命令,对比查看哪些包中的Class加载较多,基本可以定位问题:jmap -histo ${PID} | awk '{print$4}'| sed 's/\(.*\)[\._]\(.*\)/\1/g'| sort | uniq -c | sort -nrk1
总结 先扩大Metaspace缓解问题,再通过分析类加载定位根因
常见原因2:CMS GC频繁触发
解决办法:
现象:CMS GC一分钟内触发了多次,并且触发原因并不全是因为Old区占用达到-XX:CMSInitiatingOccupancyFraction所设阈值(默认92%),且CMS GC连续触发过程中Survivor区处于较高占用率。
原因:Young GC出现晋升失败(promotion failed),提前触发CMS GC。如果Old区由于剩余空间太小或者碎片太多无法容量晋升对象,则会反复引起CMS GC。
解决办法:
(1)降低CMS GC触发阈值(-XX:CMSInitiatingOccupancyFraction),确保每次Young GC对象晋升均有足够空间。
(2)增大Survivor区,足够容纳所有存活对象,避免因Survivor区不足导致晋升规模变大。
总结 避免出现Young GC晋升失败
常见原因3:分代配置不合理,导致Old区占用率增长过快,Full GC触发间隔低于预期
总结 延长Young GC发生间隔,尽量避免无效对象晋升
常见原因4:大量无效对象晋升,导致Old区占用率增长过快,Full GC触发间隔低于预期
原因:在分代配置合理的情况下,该现象说明Old区存在大量缓存对象,且缓存失效周期远超过15次Young GC的周期。
解决办法:对比Old区的class histogram,找出主要增长的对象
常见原因5:显式System.gc-----尽量避免在代码中显式调用System.gc()方法