写在前面：所有告警处理流程都是先止损，再定位，要通告。
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()方法
扫一扫
894
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
