Oracle日志体系分层结构与故障定位路径

数据库出故障的时候，监控图只能告诉你现象，真正能还原因果的只有日志。很多团队在事故复盘时发现，指标已经报警十分钟，值班人员却还在猜，原因往往不是没人干活，而是没人知道该翻哪个文件、按什么顺序翻。Oracle的日志并非一堆散落的文本，它有一套明确的生成者、存放位置、生命周期和层次关系。把这套关系理顺，排查动作就从试错变成推演。

一、日志体系在故障定位中的位置

Oracle的日志可以按生成主体分成三层。实例层由后台进程写入，代表是告警日志与各类转储文件，回答实例整体发生了什么。会话层由具体的前台会话触发，代表是会话跟踪文件与优化器跟踪，回答某条语句为什么慢。存储层由写进程与归档进程产生，代表是重做日志与归档日志，回答数据在某一刻是什么状态、是否还能恢复。

这三层的关系是递进的。实例层负责圈定时间窗与错误类型，会话层负责定位到具体语句与等待，存储层负责确认数据完整性与恢复边界。顺序颠倒就会浪费大量时间。见过最典型的错误是拿到一个实例终止的报告，第一反应是去翻归档日志，花了两个小时确认归档没坏，才发现告警日志里早就写着共享池耗尽。

故障定位本质上是一个时间轴对齐的过程。业务侧反馈的慢，监控侧的尖刺，告警日志里第一条异常，转储文件的创建时间，这四者必须在同一时间基准上对齐。Oracle的告警日志默认使用服务器本地时间并且不带时区标记，跨机房部署时如果主机时区不一致，对齐就会出错。这不是细节问题，很多误判就出在这里。

日志还有一条容易被忽略的属性，它是有成本的。开启会话级跟踪会把每一行代码路径写进文件，单个会话一小时可以产出几个GB。审计策略过宽会让每次登录都写一条记录，高峰期直接拖慢登录。因此在设计排查手段时，必须同时设计关闭条件，否则定位完一个问题会引入下一个问题。

最后要说清楚一件事。日志能证明发生过什么，不能证明为什么发生。为什么发生要靠对机制的理解去反推，日志只是证据链。只收集证据不做推理，就会陷入文件越看越多、结论越来越模糊的局面。

二、ADR目录结构与文件分布

从11g开始，Oracle把所有诊断数据集中到自动诊断资料库，英文缩写为ADR。它的根目录由诊断目标决定，通常是数据库的ORACLE_BASE下的diag目录。结构是固定的四层，diag下面按产品分rdbms与tnslsnr，rdbms下面按数据库名分，再下面按实例名分。单实例环境下数据库名与实例名相同，集群环境下同一个数据库名下面会有多个实例目录。

实例目录下有若干固定子目录。trace存放告警日志与跟踪文件，这是日常翻得最多的地方。alert目录存放XML格式的告警日志。cdump存放核心转储。incident按事件编号建立子目录，存放该次事件的打包材料。hm存放健康检查报告。trace目录下还有一个admin子目录，存放按需生成的转储。

目录结构与磁盘占用可以在主机上用下面一组命令确认。

cd $ORACLE_BASE/diag/rdbms/proddb/proddb1
ls

# 各诊断子目录的磁盘占用
du -sh trace incident cdump hm

# 最近一天新增的跟踪文件数量
find trace -name "*.trc" -mtime -1 | wc -l

想确认当前实例的实际路径，最可靠的方式是查视图而不是记路径。执行 select name, value from v$diag_info 就能拿到诊断主目录、告警日志全路径、默认跟踪文件目录、健康监控目录等关键位置。这个视图在每个实例上都成立，集群环境下切到不同实例查会得到各自的路径，避免了凭记忆拼路径拼错的尴尬。

确认诊断路径的标准查询如下。

set linesize 200
column name  format a30
column value format a80

select name, value
from v$diag_info
order by name;

ADR有一套自己的保留策略。短期策略控制告警日志与普通跟踪文件的保留天数，默认三十天。长期策略控制事件打包材料的保留天数，默认一年。策略存在配置文件里，可以用命令行工具修改。这两个值直接决定了故障发生一个月后还能不能翻到证据。金融与电信行业有合规留存要求，往往需要把长期策略调到数年，同时配套清理脚本，否则磁盘会被慢慢吃掉。

磁盘占用的增长速度经常被低估。一个每天产生二十次ORA00600的实例，每次事件打包包含跟踪文件与转储，单次可以达到几百MB，一天就是几个GB。再加上会话级跟踪忘记关闭，trace目录膨胀到几百GB的案例并不罕见。比较务实的做法是把diag目录单独挂一个文件系统，设一个水位告警，到百分之八十就人工介入，而不是等到根分区写满导致实例挂起。

清理时要注意顺序。先清incident目录下已经打包上传的旧事件，再清trace目录下无对应事件的孤立文件，最后才动告警日志。告警日志是排查的入口，删掉它等于把索引删了。清理动作必须脚本化并且留日志，人工rm在凌晨三点执行是事故的高发点。

三、告警日志的记录机制与阅读方法

告警日志是整个日志体系的入口文件，文件名通常是alert加实例名加点log。它由后台进程写入，写入是串行的，因此不会出现两条记录交错的情况。这一点很重要，说明告警日志里的顺序就是真实发生顺序，不需要怀疑并发写导致的错乱。

记录内容是结构化程度很低的一行行文本，但格式相对固定。时间戳在前，随后是进程信息或者错误信息。实例启动会写入一串启动参数与环境信息，实例关闭会写入关闭模式。这两组标记是切分时间窗的最好工具，任何一次排查都应该先找到最近一次启动记录，把时间窗限定在启动之后。

ORA00600这类内部错误在告警日志里占多行。第一行给出错误码与参数个数，随后是若干行arg，按arg加方括号加序号的格式列出。参数顺序是有意义的，不同错误码对应不同含义，解读时必须对照官方文档，不能凭经验猜。紧接着通常会有转储文件路径，指向trace目录下的具体文件，这是继续深挖的入口。

这里有一个常见误解，认为告警日志会记录所有错误。事实并非如此。用户会话遇到的普通错误，比如唯一约束冲突、无效数字，不会进告警日志，只会返回给客户端。只有影响实例运行、触发后台进程动作、或者被显式设置为记录到告警日志的错误才会出现。所以告警日志干净不等于没问题，这一点在排查业务报错时特别容易踩坑。

另一个容易忽略的点是XML版本的告警日志。alert目录下的log点xml文件包含更完整的字段，包括错误码、组件、副作用描述，适合被采集工具解析。文本版适合人读，XML版适合机器读。做集中日志平台的团队应该采集XML版，字段解析的稳定性远高于正则匹配文本。

阅读顺序建议固定为四步。先定位时间窗，再找第一条错误，然后看错误前后的进程活动，最后跳到对应转储文件。不要从文件末尾往上翻，末尾往往是连锁反应的结果，第一条错误通常在中前段。

还有一个实用技巧是关注错误之间的间隔。同一条错误以固定间隔重复出现，说明有一个轮询机制在反复失败，比如作业进程按调度周期重试、监控进程按心跳周期探测。间隔不固定则说明是外部请求驱动的，量级随业务流量变化。这两种模式指向的处置方向不同，前者要停调度，后者要限流。仅凭一条错误的时间间隔就能做出这个判断，比翻十个文件都快。

告警日志还会记录一些看起来无害但实际关键的切换事件。日志组切换、检查点完成、归档完成、参数修改，这些记录本身不是错误，但它们给出了系统的时间节拍。把业务尖刺与这些节拍对齐，常能发现根因是某个后台动作与业务高峰撞在了一起。比如大批量日志切换与批处理启动同时发生，IO就被两边抢光了。

四、后台进程跟踪文件的生成条件

trace目录下的文件按命名规则区分来源。文件名由实例名、进程类型、进程号、线程号组成，后缀是trc。同名的trm文件是跟踪元数据，记录跟踪文件的段信息，本身不含诊断内容，但删除trc之后trm会变成垃圾，反之亦然，清理时要成对处理。

跟踪文件不是随时都产生的。触发条件大致有五类。后台进程异常终止会留下跟踪，这是实例抖动的直接证据。内部错误会生成转储与跟踪。显式开启会话级跟踪会为该会话生成文件。设置了诊断事件，比如转储系统状态，会按需生成。健康监控发现异常也会主动生成检查报告与相关转储。

文件头部的信息价值很高，但经常被跳过。头部包含实例名、主机名、进程号、启动时间、版本、操作系统信息、会话信息。排查集群环境下的问题时，头部的主机名能立刻告诉你这个文件来自哪个节点，避免在多个节点的同名文件之间混淆。版本信息也很关键，同一个错误码在不同小版本上的成因可能完全不同。

关联关系是这样建立的。告警日志给出进程号与转储路径，跟踪文件头部给出同样的进程号，incident目录下的子目录名就是事件编号。三者构成一条链。断链的情况通常发生在事后拷贝文件时只拷了trc没拷incident，导致上下文丢失。规范做法是以incident目录为单位整体打包，而不是挑单个文件。

文件体积需要提前预估。一个包含完整堆栈与内存转储的跟踪文件可以是几个GB，文本编辑器打不开。这时候要用分段查看的方式，先看头部与错误段落，再看末尾。用 tail 与 head 配合关键字检索是常规手段，直接整文件加载会让排查工具本身卡死。

告警日志与跟踪文件的关键字检索可以固化成这样的脚本。

#!/bin/bash
# 用法: check_alert.sh /path/to/alert_proddb1.log
ALERT=$1

echo '===== 内部错误定位 ====='
grep -nE 'ORA-00600|ORA-07445|ORA-04031' "$ALERT" | tail -20

echo '===== 最近一次启动，用于切分时间窗 ====='
grep -n 'Starting ORACLE instance' "$ALERT" | tail -3

echo '===== trace目录下最大的跟踪文件 ====='
ls -lhS "$(dirname "$ALERT")" | head -10

还有一个经验性的判断。如果trace目录下短时间内出现大量同类型跟踪文件，且进程类型集中，基本可以判定是某个后台任务在批量失败，比如作业进程反复重试、归档进程反复报错。这种模式比单个文件更有诊断价值，值得先做一次按修改时间排序的统计。

五、重做日志与归档日志的诊断价值

重做日志记录的是数据块变更的物理描述，是实例恢复与介质恢复的唯一依据。它不属于通常意义上的诊断日志，但在两类场景里不可替代。一是确认某个时间点之后数据是否还能恢复，二是追溯误操作到底改了哪些行。

追溯误操作要用日志挖掘工具。它把归档日志与在线日志解析成可读的行级变更记录，可以按时间、按表、按操作类型过滤。前提是补充日志已经开启，否则只能看到块变更，看不到足够的列信息。很多团队在出事之后才发现没开补充日志，挖掘出来的内容无法定位到具体行，这时候只能走备份恢复，代价高得多。

归档日志的价值还体现在容量规划上。归档的产生速率直接反映业务写入强度与日志切换频率。切换过于频繁说明日志组太小，会造成检查点压力与性能抖动。切换过慢说明组太大，故障时丢数据的窗口变长。这两个方向都不是好事，需要根据实际写入量设定。

一个常见误区是把归档日志当成诊断日志来看。归档日志里没有错误信息，也没有等待事件，翻它找不到性能问题的答案。它能回答的是数据层面发生了什么，不能回答实例层面为什么慢。把这两类问题混在一起，就会在错误的方向上耗时间。

删除归档日志更是必须极其谨慎的动作。删除前要确认备份已完成、备库已应用、恢复窗口要求已满足。用强制删除跳过校验的做法，会在真正需要恢复的那一天变成灾难。这类操作应该有审批，不应该出现在值班手册的快捷命令里。

还有一个细节常被忽略。归档路径的可用空间与归档进程的写失败是直接关联的，空间不足时归档进程会挂起，进而导致所有写事务卡住，表现为全库无响应。这个链条在日志里的特征非常明确，告警日志会先出现归档写失败，随后出现日志切换无法完成，最后是会话等待。看到这一串记录，处置就是腾空间或者改归档路径，不要去做其他猜测。

六、监听日志与客户端连接问题

监听日志由监听进程写入，位置在diag目录下的tnslsnr分支里，与数据库实例目录平级。它记录连接的建立、服务的注册、连接的拒绝。客户端报连接失败时，这个文件是第一现场。

日志里的关键信息包括连接请求的时间、客户端地址、服务名、以及失败原因。服务名写错、实例未注册、监听未启动，这三种情况在日志里的表现完全不同，能直接区分是配置问题还是进程问题。动态注册的实例在启动后需要一定时间才会出现在监听里，重启后立刻连接失败往往就是这个原因，不是故障。

监听日志默认会轮转，老文件被改名保留。这意味着最需要的那段记录可能在轮转文件里，而不是当前文件里。排查时应该把当前文件与最近的轮转文件一起看。轮转阈值可以调整，但调大意味着单文件变大，检索变慢，需要权衡。

开启监听跟踪能拿到更细的握手过程，代价是日志量成倍增长，高峰期会明显影响连接建立速度。这个开关适合短时间打开，定位完立刻关。忘记关的案例不少，几周后磁盘被监听日志写满，反而造成新的故障。

集群环境下日志是分散的。多个节点各有监听，扫描监听还有自己的日志。客户端连不上时，先确认它连的是哪个地址，再去对应节点的日志里找，不要在一个节点上反复翻。地址与节点的映射关系要提前整理成文档，事故现场没人有空去查。

七、审计日志与统一审计视图

审计记录回答的是谁在什么时候做了什么。传统审计把记录写进数据库表，统一审计则把记录写到专用的表空间，并且默认开启若干策略。两者的存储位置、查询视图、清理方式都不同，混着讲会造成误解。

统一审计的记录存放在AUDSYS模式下的内部表里，通过统一审计相关的视图查询。这个视图能看到策略名、事件时间、用户、对象、操作结果、以及客户端标识。定位权限变更、异常登录、敏感表访问，都从这里入手。视图本身有延迟，刚发生的操作可能要等一会才出现，这一点在实时排查时要有心理准备。

变更与敏感操作的审计追溯可以按下面方式查询。

set linesize 200

select dbusername, event_timestamp, action_name,
       object_name, client_program_name
from unified_audit_trail
where event_timestamp > systimestamp - interval '1' day
  and action_name in ('CREATE USER', 'ALTER USER', 'GRANT')
order by event_timestamp desc;

审计对性能的影响是实打实的。每条审计记录都是一次插入，高并发短事务场景下，审计写入会成为瓶颈，表现为日志文件同步等待上升。因此审计策略必须精确到对象与操作，不能图省事全库全操作开启。曾经有团队为了合规把全库审计打开，结果批处理窗口从两小时延长到五小时，最后不得不回退重做策略。

清理审计记录要按分区或按时间范围批量删除，并且避开业务高峰。直接大批量删除会产生大量重做与撤销，还可能撑爆撤销表空间。比较稳妥的做法是先把审计表空间设为只读归档，再新建表空间承接新记录。

审计日志还有一个容易被忽视的用途，变更追溯。当有人反映某张表的权限突然变了、某个账号多了一个角色，审计记录能给出准确的时间与执行者。这比问人可靠得多。前提是相关审计策略在变更之前就已经开启，事后补开是没有历史记录的。

八、等待事件与系统状态转储

实例完全无响应时，常规查询进不去，只能靠转储。系统状态转储会把当前所有进程的状态、持有的锁、等待的队列、内存结构概要写进文件。它的级别决定内容详细程度，级别越高文件越大、生成越慢，在系统已经卡死的情况下，高等级转储可能生成十几分钟。

挂起分析是更轻量的手段。它针对会话与锁的关系做三次采样，输出等待链。链的末端就是阻塞源。读这个输出的关键是顺着链条找到最后一个不等待别人的会话，那个才是根因。很多人看到链很长就慌了，其实只要找到末端，问题就收敛了。

触发方式有两种，一种是通过调试工具向指定进程发指令，另一种是预先配置事件让系统在检测到挂起时自动转储。后者适合生产环境，因为无响应时人可能连不上。自动转储要有阈值，否则轻微抖动也会触发，产生大量无用文件。

转储文件里最值得看的是进程列表与等待部分。进程列表给出每个进程的号、类型、状态、当前等待事件。状态为等待的进程要看它在等什么，状态为运行的进程要看它在跑什么。两者结合能判断是单点卡住还是全局资源耗尽。

系统状态转储与挂起分析的触发方式如下。

sqlplus / as sysdba
oradebug setmypid
oradebug unlimit

-- 系统状态转储，级别控制在生产可接受的范围
oradebug dump systemstate 266

-- 挂起分析，间隔数秒采样两次以区分暂时性等待
oradebug hanganalyze 3
oradebug hanganalyze 3

-- 输出跟踪文件路径
oradebug tracefile_name

内存结构部分适合判断共享池与缓冲区的压力。空闲链表长度、等待队列长度、命中率这类信息在正常运行时从视图也能拿到，但在系统卡死时视图查不了，转储是唯一来源。这也是为什么事后分析必须保留转储文件的原因。

转储本身的代价要说清楚。生成过程会暂停部分进程活动，相当于给系统加了一次短时冻结。在生产库上执行前必须评估，能通过单个会话跟踪解决的问题不要上升为全库转储。这个判断力比工具熟练度更重要。

采样次数也是参数。挂起分析做三次采样是为了区分暂时性等待与持续性等待，只做一次会把瞬时抖动误判为死锁。三次采样之间要有间隔，间隔太短三次结果几乎一样，看不出一致性，间隔太长又会让系统多冻结一段时间。常见取值是每次间隔数秒到十几秒，具体看业务对停顿的容忍度。

判断是否真的挂起，还有一个低成本信号。观察后台进程是否还在做检查点，如果检查点仍在推进，说明实例没死，只是某个资源被独占，处置方向是找到持有者而不是重启。如果检查点也停了，说明问题已经上升到实例级，这时候转储与重启的决策要更快做。这个区分能在几分钟内给出方向。

九、会话级跟踪与执行计划取证

单条语句慢，最有效的手段是会话级跟踪。开启后，该会话执行的每条语句、每次解析、每次执行、每次等待、每次读取，都会被记录。输出是二进制格式，需要用解析工具转成可读报告。

跟踪级别决定信息量。基础级别只记录语句与等待，加上等待详情能看到具体是哪个文件、哪个块的IO，加上绑定变量能看到实际传入的值。绑定变量非常关键，同一条语句传不同的值可能走完全不同的执行计划，看不到值就无法复现。

解析工具的输出有几个关键段落。总体统计给出解析次数、执行次数、CPU时间、耗时、物理读、逻辑读、行数。执行计划给出每一步的操作与代价。等待事件列表给出时间花在哪里。把这三段对起来看，就能判断是计划选错、还是IO瓶颈、还是锁等待。

优化器跟踪是另一个层次。它记录优化器在生成计划时的全部推演过程，包括各种访问路径的代价估算、转换前后的等价语句、最终选择理由。当出现计划突然变化、同一个语句在两个环境表现不同、索引明明存在却没用，这类问题就要看优化器跟踪。

这两个手段的共同问题都是体积。一个复杂查询的优化器跟踪可以到几十MB，会话级跟踪跑一小时可以到几GB。开启前要估算，开启后要记得关，文件要及时清理。忘记关导致磁盘写满的事故，比它解决的问题还多。

还有一个替代方案值得提。活动会话历史视图能以较低成本采样到语句级的等待分布，不需要开启跟踪就能大致定位热点。它不能替代跟踪的精度，但适合作为第一轮筛选，把范围从几百条语句缩到几条，再对有嫌疑的开跟踪。这个由粗到细的路径，比一上来就全量跟踪务实得多。

十、ADRCI工具链的日常用法

命令行工具把前面这些分散的路径与文件统一管理起来，不用记目录结构。它的常用子命令不多，但每个都对应一个固定场景。

查看诊断主目录列表用 show homes，切换当前目标是 set homepath 加路径。切换之后所有命令都针对该实例。多实例环境下一旦忘了切换，看到的会是另一个实例的数据，这是最常见的误操作。

查看告警日志用 show alert 加尾部行数，不用关心文件在哪。查看事件列表用 show incident，可以按时间范围过滤。查看问题列表用 show problem，问题是对多次同类事件的归并，一个问题的下挂多个事件，这个层次关系在做趋势判断时很有用。

常用的adrci批处理调用可以固化成下面这种形式。

adrci <<'EOF'
set homepath diag/rdbms/proddb/proddb1
show homes
show alert -tail 200
show incident -p "create_time > '2026-11-01 00:00:00'"
show problem
EOF

打包事件用命令生成压缩包，包内包含该事件相关的跟踪、转储、告警片段。打包前可以配置包含哪些文件，默认已经够用。生成的包可以直接交给厂商做远程分析，不需要人工挑文件。

清理用清除命令，可以按时间、按事件、按问题删除。批量清理务必先列出将要删除的清单再确认，直接执行容易误删。这个工具的删除是不可恢复的，没有回收站。

把这些命令写进巡检脚本是必要的。每天统计事件数量、跟踪文件总量、诊断目录占用，超过阈值就发告警。等到人为发现异常，往往已经积累了几十GB。自动化巡检的成本远低于一次磁盘写满的停机。

脚本化时有两点要注意。一是输出要能被人直接看，不要只输出一堆路径，要带上时间、实例、事件编号，方便按图索骥。二是脚本本身要能容忍异常，某个目录不存在或者权限不足时跳过而不是中断，否则一次权限调整就会让整个巡检失效，而失效往往没人发现，直到真的出事。

十一、事件打包与远程支援流程

事件与问题是两个概念，混淆会导致沟通成本上升。事件是一次具体的故障发生，有唯一编号、有发生时间、有对应的转储文件。问题是若干同类事件的集合，代表一个尚未解决的缺陷。提交给厂商时应该说清楚是哪一层，说错会被要求重提。

打包内容的选择有讲究。全部打包会把整个诊断目录压缩，动辄几十GB，上传和解析都很慢，而且包含大量无关信息。正确做法是按事件编号打包，工具会自动关联相关文件。如果确实需要上下文，可以额外附上故障前后一段时间的告警日志片段。

脱敏是必须的一步。跟踪文件里可能包含SQL文本与绑定变量，其中可能有手机号、身份证号、金额。对外提交前应该走脱敏流程，或者在测试环境复现后再打包。把生产数据原样交出去，合规上过不了关。

提交材料里最有价值的是时间线。故障开始时间、业务反馈时间、监控报警时间、第一次人工介入时间、关键操作时间，按顺序列清楚。厂商工程师拿到时间线，能快速定位到对应日志段落，比让他自己从几十万行里找高效得多。

回执与跟进也要留痕。事件编号、提交时间、对接人、结论、修复版本，这些信息应该记进内部知识库。同一个缺陷在不同版本上重复出现的情况很常见，有记录就能直接查到历史结论。

十二、典型故障的排查路径推演

第一个场景是实例反复终止。排查顺序是，先在告警日志里找最近一次启动记录，确认时间窗。再找终止前的最后一条错误，通常是ORA00600或者ORA07445。然后跳到对应转储文件，看进程类型与堆栈。如果是某个后台进程反复终止，重点看它处理的对象，比如归档进程看归档路径与空间，作业进程看具体作业。最后确认是否有外部因素，比如操作系统内存不足触发进程被杀，这种情况在告警日志里往往只有一句进程终止，需要去操作系统日志里找证据。

第二个场景是连接风暴后系统无响应。先看监听日志，确认连接请求的量级与来源。再看活动会话视图能否连上，如果连不上就走转储。转储里的进程列表会显示大量会话在等待某个共享资源，常见的是共享池分配等待或者日志同步等待。前者说明硬解析过多，后者说明提交过于频繁。两个方向的处置完全相反，必须先区分。区分方法看等待事件的名称，不要看现象。

第三个场景是批量作业突然变慢。先确认是全部作业慢还是个别作业慢，这决定了问题在实例层还是在语句层。个别慢就对该作业开会话级跟踪，看执行计划是否变化。计划变化的常见原因是统计信息过期或者绑定变量窥探。全部慢就看实例级指标，确认是IO还是CPU还是锁。这个分叉做对了，后面就是常规操作。

三个场景的共同点是先分层再定位。跳过分层直接猜，就会在错误的层次上花时间。分层不需要工具，只需要问两个问题，影响范围是全局还是局部，现象是资源不足还是逻辑错误。两个问题的答案就能把范围缩小八成。

再补一个高频场景，数据文件所在磁盘写满。这个问题的日志特征很典型，告警日志先出现无法扩展段的错误，随后是写操作失败，如果开了自动扩展并且空间确实不足，还会看到持续的重试记录。识别要点是看错误出现的对象是临时表空间还是数据表空间，两者处置不同。临时表空间满了可以扩文件或者加临时文件，业务不必停。数据表空间满了要评估是归档空间不足导致的连带，还是真的业务增长，盲目扩容会掩盖问题。这个判断要在动手扩之前完成，扩完再查就少了现场。

十三、日志治理与容量控制

保留策略要跟业务与合规对齐。诊断数据保留三十天是默认值，对于月结类的系统不够用，因为问题可能在下个月结时才复现。这类系统应该把长期策略调到九十天以上，同时接受更大的磁盘占用。

容量要按增长趋势算，不能按当前值算。统计最近三十天诊断目录的日均增量，乘以保留天数，再留百分之五十余量，就是需要的空间。事件密集的系统还要考虑突发，一次严重故障可能瞬间产生几十GB。

集中采集是规模化之后的必然选择。把告警日志的XML版本、监听日志、审计记录采到统一平台，做字段解析与关联检索。本地文件仍然保留，用于深度分析。两层结合，既有一眼可见的全景，也有可下钻的细节。

采集本身也有风险。采集代理占用主机资源、采集链路中断导致日志丢失、解析规则跟不上版本升级。这些都要在上线前验证。最稳妥的做法是采集与本地保留并行，采集出问题不影响本地排查。

清理必须自动化并且有审计。脚本按策略删除过期文件，删除前后记录数量与路径。人工清理只作为例外流程，并且需要两个人确认。这条规矩看起来繁琐，但它是防止误删的唯一有效手段。

十四、常见误区与团队协作约定

第一个误区是只看告警日志就下结论。告警日志是入口不是全部，很多问题的答案在转储与跟踪里。看到第一条错误就停止，等于只看目录不看正文。

第二个误区是把跟踪文件当垃圾删。跟踪文件是内部错误唯一的现场证据，删了就无法做根因分析。清理前必须确认没有未闭环的事件。

第三个误区是重启前不保留现场。重启会覆盖大量内存状态，告警日志虽然保留，但转储与跟踪的上下文会断。重启是处置手段，不是排查手段，重启前先打包。

第四个误区是时间不对齐。应用日志用UTC，数据库用本地时间，中间差八小时，对齐时就会把因果搞反。统一时间基准是排查前的第一件事，不是可选项。

第五个误区是多节点日志混看。集群环境下同名文件在多个节点都有，不确认主机名就开始分析，结论必然错。看文件先看头部的主机名。

协作层面有三条约定值得推广。故障单必须附事件包，不接受只有文字描述的报告。所有时间点统一用UTC记录，展示时再转本地。变更记录与日志时间线放在一起对照，因为绝大多数故障都能在变更记录里找到对应动作。这三条落下去，复盘效率会有明显提升。

日志体系的建设不是一次性的工程。它跟版本升级、架构演进、合规要求一起变化。定期回看保留策略是否还合适、采集字段是否还完整、排查路径是否还成立，比出事时临时抱佛脚有用得多。把日志当成基础设施的一部分来运维，故障定位就会从靠人靠运气，变成靠流程靠证据。