尧图网站建设 
排障时如何保留有效证据JVM 发生 OOM、CPU 饱和或长时间停顿时恢复服务和保留证据都重要。直接重启可能缩短影响却会清除容器内日志、线程状态和临时文件为了抓全量 Dump 而长时间阻塞进程也可能扩大故障。团队应在事前约定采集顺序、时间预算、存储位置和停止条件。自动证据要先解决存储问题Heap Dump 可能接近当前堆的量级写入速度受磁盘影响。容器内路径如果没有持久卷Pod 删除后文件仍会消失共享节点磁盘空间不足还可能影响其他工作负载。启用前确认目录权限、可用空间、配额、加密、访问控制与清理策略。下面保留一组 JDK 启动参数作为核对示例不是生产标准配置。日志轮转大小、文件数量、GC 类型以及 OOM 后是否立即退出都要按目标 JDK、堆大小和恢复策略验证# 示例在目标 JDK 和持久化目录中验证后再启用 JAVA_OPTS-XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/var/log/app/heap_dump_%p.hprof \ -XX:CrashOnOutOfMemoryError \ -Xlog:gc*,gcphasesdebug,safepointinfo:file/var/log/app/gc_%p.log:time,uptime,pid:filecount5,filesize100M \ -XX:UseG1GCHeapDumpOnOutOfMemoryError尝试在 OOM 时写堆快照但不能保证磁盘不足、进程被强杀或底层故障时仍成功。CrashOnOutOfMemoryError会改变恢复行为只有在写操作一致性和编排重启策略已经验证后再使用。GC 日志用于还原分配与停顿趋势轮转窗口能覆盖多久取决于日志速率不能从文件数直接推算小时数。CPU 异常先采样再终止CPU 高可能来自业务计算、JIT、GC、锁竞争或系统线程。线程 Dump 需要间隔采集才能判断同一线程是否持续停在相同栈。脚本应接受明确 PID而不是用pgrep -f java猜测目标多 JVM 节点上抓错进程会浪费时间也可能暴露无关服务信息。下面的脚本加入了 PID 校验、路径引用和目录权限。它仍需目标容器具备top、jcmd及相应 attach 权限JFR 的开销也要在预发环境评估。#!/bin/bash set -euo pipefail PID${1:?Usage: save_evidence.sh java-pid} kill -0 $PID TIMESTAMP$(date %Y%m%d_%H%M%S) EVIDENCE_ROOT${EVIDENCE_ROOT:-/var/log/app} EVIDENCE_DIR${EVIDENCE_ROOT}/evidence_${TIMESTAMP} mkdir -p -- $EVIDENCE_DIR chmod 700 $EVIDENCE_DIR top -b -n 1 -H -p $PID | head -n 20 $EVIDENCE_DIR/top_threads.txt for i in 1 2 3; do jcmd $PID Thread.print $EVIDENCE_DIR/threads_${i}.txt sleep 2 done jcmd $PID JFR.start nameCpuCheck settingsprofile \ duration10s filename$EVIDENCE_DIR/cpu_check.jfr echo Thread dumps saved; JFR will finish at: $EVIDENCE_DIR/cpu_check.jfr从top得到的是操作系统线程 ID转换成十六进制后可以与 Thread Dump 的nid对照。但即使找到热点线程栈顶也只是采样时的位置需要结合多次 Dump、JFR 和源码确认不能保证一次就精确到根因代码行。用时间线连接指标、GC 与 TraceJVM 指标和业务 trace 通常通过服务实例、版本和时间窗口关联不要把 trace ID 做成 Prometheus 高基数标签。先从告警确定实例和时间段查看 GC 日志与 JFR再抽取该窗口的慢 trace 和错误日志。请求内容、用户标识和导出文件不进入普通日志需要业务复现时使用脱敏样本。相关性仍不是因果。Old Gen 上升与某个导出请求同时发生只能提示检查该路径。通过相同输入重放、分配 profile 和修复前后对比才能判断是否应该分页、流式处理或调整堆。直接调大-Xmx可能只是延后 OOM也可能增加 Dump 与 GC 成本。高风险采集动作要有审批与停止条件jmap -dump:live、高频方法增强和完整 Heap Dump 都可能引入明显停顿或资源消耗。是否执行取决于当前影响、剩余副本、堆大小和已验证开销。采集前确认磁盘空间和服务冗余采集中监控延迟与磁盘到达停止条件立即放弃并恢复流量。证据文件往往含业务对象、SQL、路径甚至密钥上传和分享前不能只做文件名脱敏。将原始文件放入加密、受控存储记录访问人和保留期限复盘材料只引用必要片段。演练脚本也要定期在当前镜像和 JDK 上运行避免真正故障时才发现工具缺失或目录不可写。一套可用的留证流程应回答谁有权触发先采什么最多花多长时间文件写到哪里服务何时重启证据何时删除。把这些条件在预发演练过比事故现场临时执行一串“标准命令”可靠得多。 排障时如何保留有效证据
排障时如何保留有效证据JVM 发生 OOM、CPU 饱和或长时间停顿时恢复服务和保留证据都重要。直接重启可能缩短影响却会清除容器内日志、线程状态和临时文件为了抓全量 Dump 而长时间阻塞进程也可能扩大故障。团队应在事前约定采集顺序、时间预算、存储位置和停止条件。自动证据要先解决存储问题Heap Dump 可能接近当前堆的量级写入速度受磁盘影响。容器内路径如果没有持久卷Pod 删除后文件仍会消失共享节点磁盘空间不足还可能影响其他工作负载。启用前确认目录权限、可用空间、配额、加密、访问控制与清理策略。下面保留一组 JDK 启动参数作为核对示例不是生产标准配置。日志轮转大小、文件数量、GC 类型以及 OOM 后是否立即退出都要按目标 JDK、堆大小和恢复策略验证# 示例在目标 JDK 和持久化目录中验证后再启用 JAVA_OPTS-XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/var/log/app/heap_dump_%p.hprof \ -XX:CrashOnOutOfMemoryError \ -Xlog:gc*,gcphasesdebug,safepointinfo:file/var/log/app/gc_%p.log:time,uptime,pid:filecount5,filesize100M \ -XX:UseG1GCHeapDumpOnOutOfMemoryError尝试在 OOM 时写堆快照但不能保证磁盘不足、进程被强杀或底层故障时仍成功。CrashOnOutOfMemoryError会改变恢复行为只有在写操作一致性和编排重启策略已经验证后再使用。GC 日志用于还原分配与停顿趋势轮转窗口能覆盖多久取决于日志速率不能从文件数直接推算小时数。CPU 异常先采样再终止CPU 高可能来自业务计算、JIT、GC、锁竞争或系统线程。线程 Dump 需要间隔采集才能判断同一线程是否持续停在相同栈。脚本应接受明确 PID而不是用pgrep -f java猜测目标多 JVM 节点上抓错进程会浪费时间也可能暴露无关服务信息。下面的脚本加入了 PID 校验、路径引用和目录权限。它仍需目标容器具备top、jcmd及相应 attach 权限JFR 的开销也要在预发环境评估。#!/bin/bash set -euo pipefail PID${1:?Usage: save_evidence.sh java-pid} kill -0 $PID TIMESTAMP$(date %Y%m%d_%H%M%S) EVIDENCE_ROOT${EVIDENCE_ROOT:-/var/log/app} EVIDENCE_DIR${EVIDENCE_ROOT}/evidence_${TIMESTAMP} mkdir -p -- $EVIDENCE_DIR chmod 700 $EVIDENCE_DIR top -b -n 1 -H -p $PID | head -n 20 $EVIDENCE_DIR/top_threads.txt for i in 1 2 3; do jcmd $PID Thread.print $EVIDENCE_DIR/threads_${i}.txt sleep 2 done jcmd $PID JFR.start nameCpuCheck settingsprofile \ duration10s filename$EVIDENCE_DIR/cpu_check.jfr echo Thread dumps saved; JFR will finish at: $EVIDENCE_DIR/cpu_check.jfr从top得到的是操作系统线程 ID转换成十六进制后可以与 Thread Dump 的nid对照。但即使找到热点线程栈顶也只是采样时的位置需要结合多次 Dump、JFR 和源码确认不能保证一次就精确到根因代码行。用时间线连接指标、GC 与 TraceJVM 指标和业务 trace 通常通过服务实例、版本和时间窗口关联不要把 trace ID 做成 Prometheus 高基数标签。先从告警确定实例和时间段查看 GC 日志与 JFR再抽取该窗口的慢 trace 和错误日志。请求内容、用户标识和导出文件不进入普通日志需要业务复现时使用脱敏样本。相关性仍不是因果。Old Gen 上升与某个导出请求同时发生只能提示检查该路径。通过相同输入重放、分配 profile 和修复前后对比才能判断是否应该分页、流式处理或调整堆。直接调大-Xmx可能只是延后 OOM也可能增加 Dump 与 GC 成本。高风险采集动作要有审批与停止条件jmap -dump:live、高频方法增强和完整 Heap Dump 都可能引入明显停顿或资源消耗。是否执行取决于当前影响、剩余副本、堆大小和已验证开销。采集前确认磁盘空间和服务冗余采集中监控延迟与磁盘到达停止条件立即放弃并恢复流量。证据文件往往含业务对象、SQL、路径甚至密钥上传和分享前不能只做文件名脱敏。将原始文件放入加密、受控存储记录访问人和保留期限复盘材料只引用必要片段。演练脚本也要定期在当前镜像和 JDK 上运行避免真正故障时才发现工具缺失或目录不可写。一套可用的留证流程应回答谁有权触发先采什么最多花多长时间文件写到哪里服务何时重启证据何时删除。把这些条件在预发演练过比事故现场临时执行一串“标准命令”可靠得多。