凌晨两点被电话叫醒业务系统连不上登上小机一看/var/adm/syslog/syslog.log最后几行明晃晃地写着某个磁盘的 I/O 报错再往前翻半小时warning 已经反复刷屏了。这种情况在 HP-UX 小机的运维里见得太多了——很多人遇到故障第一反应是重启、换备件或者直接找原厂却忘了机器自己一直在写日记。这篇就聊 HP-UX 小机故障检测里最基础、也最容易被低估的一块LOG。日志不是出了事才翻的废纸堆它是系统从启动到崩溃全过程的第一现场记录。搞清楚 HP-UX 的日志体系怎么布局、哪些文件值得盯、报错信息怎么读你就能在故障扩散之前拿到最关键的线索。适合刚接手小机的运维新手也适合已经在管机器但总靠重启大法续命的老手。1. 为什么说LOG是HP-UX故障检测的第一入口1.1 小机故障的独特性和日志的先手价值HP-UX 小机跟普通 x86 服务器在运维逻辑上有本质区别。这类机器往往跑的是核心业务停机窗口极窄硬件结构复杂多路 CPU、多张 HBA 卡、外接盘阵而且很多关键信息不像 Linux 那样随手dmesg就能看全。硬件层面的故障信号比如内存单比特纠错、PCI 插槽异常、风扇转速掉档、电源模块切换往往先在日志里留痕过一段时间才演变成业务可感知的故障。也就是说日志是唯一能在还没出事阶段就给你预警的通道。我见过太多案例某台小机的 syslog 里连续几天刷Memory error detected运维没当回事直到某天业务进程莫名其妙被 kill才回头翻日志发现早有预兆。还有磁盘链路的问题Disk I/O error隔几小时冒一条看着不影响业务实际上 HBA 卡或者光纤链路已经在临界状态。日志的价值不在于事后追责而在于它比业务监控更早感知到硬件和内核层面的抖动。从实操角度看小机故障检测有三条主线硬件状态ioscan、cstm、STM、性能指标sar、glance、日志事件syslog、EMS、启动日志。前两者是快照反映的是当下状态日志是时间轴记录的是演变过程。故障排查时时间轴往往比快照更有说服力因为你知道问题是什么时候开始的、中间经历了什么、有没有反复。这也是为什么我习惯把日志当成故障检测的第一入口——先看时间轴再看快照定位效率会高很多。1.2 HP-UX日志体系的整体布局HP-UX 的日志不像某些系统那样集中在一个目录里而是分散在几个关键路径下各管一摊。刚接触的人容易懵不知道去哪个文件里找线索。我把它归成四类理解了分类找日志就有方向了。第一类是系统运行日志核心是/var/adm/syslog/syslog.log这是 syslogd 守护进程收集的所有系统级消息的汇总内核报错、服务启停、认证事件、cron 执行结果都可能落在这里。轮转后的历史文件是OLDsyslog.log。第二类是启动和关机轨迹包括/etc/rc.log或/var/adm/rc.log视版本而定、/var/adm/shutdownlog记录系统每次启动、关机、进入单用户模式的完整过程排查机器为什么自己重启了必看。第三类是审计和登录记录/var/adm/sulog记录 su 切换/var/adm/wtmp记录登录历史用last读/var/adm/btmp记录失败登录用lastb读。第四类是硬件和诊断日志包括/var/adm/ras/下的 RAS 相关记录、EMS 事件日志/var/opt/resmon/log/event.log、STM 工具日志/var/stm/logs/。这四类日志的读取节奏不一样。syslog 是实时刷的适合tail -f盯着启动日志是每次开机生成一段适合事后回溯审计日志是累积的适合定期巡检硬件日志则是有事才写平时安静一旦出现密集记录就要警惕。很多人只盯着 syslog.log忽略了启动日志和 EMS 事件日志结果遇到机器无故重启这种问题就抓瞎——syslog 里可能只有一句重启前的最后消息真正的线索在 shutdownlog 和 rc.log 里。注意不同 HP-UX 版本11i v1/v2/v3的日志路径和文件名有细微差异接手一台机器第一件事应该是把上述路径逐个ls一遍确认哪些存在、哪些为空建立自己的路径清单。别等出事了才现找。2. HP-UX核心日志文件逐个拆解2.1 syslog.log与OLDsyslog.log的读取要点/var/adm/syslog/syslog.log是日常排查的主战场但很多人读它的方式不对——直接cat一遍几千行刷屏啥也看不出来。正确姿势是先看尾部、再看关键词、最后看时间窗口。tail -100 /var/adm/syslog/syslog.log拿到最近的现场grep -i error\|fail\|warn /var/adm/syslog/syslog.log | tail -50快速筛出异常grep 时间段把范围锁定到故障发生前后。这个文件的格式是时间戳 主机名 进程名[PID]: 消息内容。时间戳默认是MMM dd HH:MM:SS没有年份跨年排查时要留意。进程名那一列很关键vmunix表示内核消息硬件、驱动、内存相关的多半来自它syslogd是日志服务本身cron是定时任务sshd是远程登录ems或resmon是事件监控。看到vmunix打头的报错要格外上心那基本是硬件或内核层的问题。OLDsyslog.log是轮转后的上一份排查问题持续了多久时要把两个文件连起来看。syslog 轮转策略由/etc/syslog.conf和 cron 里的轮转脚本共同决定有的机器一周一轮有的按大小轮还有的机器压根没配轮转syslog.log 能涨到几个 G——这种情况本身就是隐患文件系统被日志撑爆导致业务写不进去的事故我遇到过不止一次。接手机器时先ls -lh /var/adm/syslog/看一眼文件大小心里有个数。提示syslog.log 里如果出现大量重复的同一类报错比如每秒一条磁盘错误说明问题在持续恶化不要只看到业务还能跑就放着不管重复刷屏本身就是强信号。2.2 启动与关机轨迹日志的回溯方法排查机器为什么自己重启/var/adm/shutdownlog和rc.log是绕不开的。shutdownlog记录每次关机的发起者、时间、原因格式比较简洁。如果看到shutdown: ... by user root那多半是人为操作如果只有一条系统终止记录、没有人为发起的痕迹就要怀疑是硬件看门狗触发或者电源事件。rc.log部分版本在/etc/rc.log部分在/var/adm/rc.log记录的是启动过程中每个 rc 脚本的执行结果。这个文件的价值在于系统启动到某一步卡住或者某个服务没起来这里会留下 FAIL 或者超时记录。我处理过一次机器重启后网卡没起来的问题syslog 里啥也没有最后是在 rc.log 里发现网络初始化脚本报了一个配置文件的权限错误改完权限就恢复了。这两个文件的特点是平时不看、出事必看。建议在每次计划内重启后顺手扫一眼 rc.log 尾部确认没有意外的 FAIL 记录养成习惯能省掉很多事后排查。另外dmesg命令输出的是内核环形缓冲区的当前内容跟 syslog 里的vmunix消息有重叠但不完全等同机器刚启动时dmesg能看到完整的硬件探测过程包括内存容量识别、CPU 数量、各 PCI 插槽上挂的设备这些信息对判断硬件有没有被正确识别很有用。2.3 登录审计类日志的使用场景/var/adm/sulog、wtmp、btmp这三个文件管的是谁在什么时候用什么方式登了机器。sulog直接cat就能读每行记录一次 su 尝试成功失败都有标记。wtmp要用last命令读last -20看最近二十次登录last reboot看重启历史这个特别有用能快速知道机器最近重启过几次、每次的上下线时间。btmp用lastb读记录的是失败登录尝试。安全审计场景下lastb输出里如果出现大量来自同一来源的失败尝试基本可以判定是有人在扫密码。这时候要做的不是只改密码而是结合 syslog 里sshd相关的记录看攻击的持续时间和频率必要时在网络层做限制。日常运维场景下last reboot是我最常用的命令之一——接手一台陌生机器先敲一下机器最近有没有异常重启、重启间隔是否规律一目了然。这三个文件都是二进制格式sulog 除外不要试图用cat读 wtmp 和 btmp会出一堆乱码。另外这些文件也会轮转历史记录可能被截断重要审计场景要确认轮转策略是否满足留存要求。2.4 硬件与RAS相关日志的识别特征/var/adm/ras/目录下存放的是 RASReliability, Availability, Serviceability相关的记录不同版本内容有差异常见的有boot.log启动过程的详细记录、崩溃转储相关的索引文件等。这个目录不像 syslog 那样高频写入但一旦有内容更新往往意味着硬件层面发生了值得关注的事件。硬件故障在日志里的典型特征有几类内存相关会出现Memory error、ECC、single-bit、multi-bit这样的字眼单比特错误通常能被纠错、不影响业务但密集出现说明内存条在老化多比特错误则是致命信号磁盘和链路相关会出现Disk I/O error、SCSI、fiber channel、link down、HBA等关键词电源和风扇相关会出现power supply、fan、thermal等词。这些消息大多由vmunix进程写入 syslog所以 syslog 和 RAS 目录要对照着看。我个人的经验是硬件类报错不要孤立地看单条要看密度和趋势。偶尔一条单比特内存错误可以观察一天几十条就必须安排更换磁盘 I/O 错误如果只出现在某一块盘上那基本锁定该盘或它的链路如果多块盘同时报错就要怀疑是 HBA 卡、光纤交换机或者背板的问题。日志的价值就在于它能帮你把故障范围从整个系统缩小到某个部件。2.5 EMS事件日志与STM工具日志的定位EMSEvent Monitoring Service是 HP-UX 上负责硬件和系统事件监控的组件它的事件日志在/var/opt/resmon/log/event.log部分版本在/etc/opt/resmon/log/。这个文件记录的是 EMS 监控到的资源状态变化包括硬件告警、阈值触发、监控项启停。跟 syslog 相比EMS 日志更结构化、更聚焦硬件很多在 syslog 里只有一句话的硬件事件在 EMS 日志里能看到完整的资源路径和事件级别。STMSupport Tool Manager是诊断工具日志在/var/stm/logs/下记录的是每次运行诊断工具的过程和结果。这个日志平时用得少但在需要向原厂提供诊断信息、或者怀疑某个硬件部件有问题需要跑诊断确认时STM 的日志和报告就是关键材料。cstm命令可以交互式地查看硬件详细信息mstm是它的菜单版跑完之后结果会落到 STM 相关路径下。实际排查中我的顺序通常是先看 syslog 定位大致方向再看 EMS 日志确认硬件事件的级别和资源需要深入时跑cstm或ioscan -fnC确认硬件状态。这三者配合基本能把硬件类故障定位到具体部件。EMS 日志容易被忽略因为路径比较深但只要涉及硬件告警它往往比 syslog 更完整、更可信。3. 日志的实操抓取与高效解读方法3.1 定位问题的四步筛选法日志排查最怕没有章法地乱翻。我总结了一个四步法按顺序走绝大多数问题能在十几分钟内锁定方向。第一步定时间故障是什么时候发生的、业务是什么时候感知到的把时间窗口缩小到前后半小时。第二步定来源是登录类、启动类、硬件类还是服务类问题对应到前面说的四类日志。第三步定关键词根据故障现象选关键词连不上看sshd、network、link卡顿看I/O、timeout、memory重启看shutdown、boot、panic。第四步定密度同类消息是孤立的还是密集的孤立可能是偶发密集基本是持续故障。这个方法的精髓是先缩小范围再深入而不是一上来就grep全文件。举个例子业务反馈上午十点左右数据库连不上第一步锁定 9:30 到 10:30 的 syslog第二步判断这属于服务类问题第三步 grepdatabase相关进程名或者connection、refused第四步看报错是否集中在某个时间点。按这个节奏走比漫无目的地翻要快得多。3.2 常用命令组合与实时监控技巧几个命令组合值得背下来。实时盯日志用tail -f /var/adm/syslog/syslog.log配合grep --line-buffered可以做关键词实时过滤比如tail -f /var/adm/syslog/syslog.log | grep --line-buffered -i error\|fail屏幕上只刷异常行清爽很多。按时间窗口筛用awk或者sed配合时间戳比如grep ^Mar 15 09: /var/adm/syslog/syslog.log能把某天九点的记录全拉出来。统计报错频率用grep ... | awk {print $5} | sort | uniq -c | sort -rn能快速看出哪个进程、哪类消息在刷屏。看文件增长用ls -lh和du -sh确认日志没有失控。跨文件关联用grep -h同时在 syslog.log 和 OLDsyslog.log 里搜避免漏掉轮转前的记录。这些命令都不复杂但组合起来用能省大量时间。提示tail -f盯日志时如果发现刷屏速度突然加快先别急着 CtrlC让它多跑十几秒把密集期的完整记录抓下来这往往是故障最关键的现场。3.3 硬件故障的日志特征识别硬件故障在日志里有一套相对固定的语言。内存问题看Memory error、ECC、correctable、uncorrectable其中uncorrectable出现基本意味着进程会被杀或者系统会 panic。磁盘问题看Disk I/O error、SCSI error、timeout、retryretry频繁说明链路不稳定。网络问题看link down、link up、duplex mismatch、frame error。电源和散热看power supply、fan failure、temperature。识别这些特征之后关键动作是关联到具体部件。syslog 里的报错通常会带设备路径或者实例号比如某条 SCSI 错误会指明是哪个c#t#d#设备拿着这个标识去ioscan -fnC disk的输出里对就能知道是哪块物理盘。HBA 相关的报错会带卡的位置信息对照ioscan -fnC fc能定位到具体卡。这一步做扎实了报修时给原厂的信息才准确避免来回扯皮。# 筛出硬件相关报错并按设备路径归类 grep -iE memory error|disk i/o|scsi|hba|link down|power supply|fan \ /var/adm/syslog/syslog.log | \ awk {print $5, $6, $7, $8} | sort | uniq -c | sort -rn | head -203.4 软件与系统级故障的日志特征识别软件层面的故障信号跟硬件不一样更碎。服务起不来看failed to start、permission denied、no such file、address already in use。文件系统满看No space left on device注意这个报错有时是 inode 耗尽而不是块耗尽df -i和df -k要都看一眼。进程被杀看Out of Memory、killed、signal 9。网络服务看connection refused、timeout、reset by peer。这类故障的排查要点是顺藤摸瓜。syslog 里只报了一个结果比如某某服务启动失败但失败原因往往在更早的几行——可能是配置文件读不到、可能是依赖的服务没起来、可能是端口被占。我习惯在报错行前后各看二十行把上下文一起拉出来很多问题在这个范围内就能看到根因。软件故障还有一个容易忽略的点cron任务失败。syslog 里cron进程的记录会显示每次任务执行的结果如果某个备份脚本或者巡检脚本每天都失败日志里会规律性地出现错误但因为不影响主业务往往被无视。定期扫一眼cron相关记录能发现不少慢性病。4. 典型故障场景的日志排查实战4.1 系统意外宕机或重启的还原过程机器自己重启是最让人紧张的场景。排查顺序应该是先last reboot看重启时间点再翻shutdownlog看有没有人为发起然后看rc.log确认启动过程是否正常最后在 syslog 里找重启前最后几分钟的记录。如果shutdownlog里有 root 发起的记录那就是人为或者脚本触发顺着时间点找谁在操作。如果没有人为记录syslog 在重启前有panic、trap、Memory error之类的内核消息基本可以判定是硬件或内核崩溃。如果 syslog 在重启前戛然而止、什么也没留下那要怀疑电源瞬时掉电或者看门狗强制复位这种情况下 EMS 日志和硬件管理口的事件记录如果有会更有帮助。还有一种情况是重启前 syslog 里有大量磁盘或文件系统报错然后系统挂掉。这种要顺着报错往前追很可能是文件系统损坏导致内核异常。还原这类问题的关键是时间轴要完整——last reboot给时间点shutdownlog给关机方式rc.log给启动结果syslog 给崩溃前现场四份材料拼起来故事线就清楚了。4.2 磁盘与文件系统异常的定位路径磁盘问题的日志表现分几层。最轻的是偶发I/O error加重试成功业务无感中间是持续I/O error导致应用报读写失败最重是文件系统损坏或者盘彻底掉线。排查时先看报错涉及的设备路径用ioscan -fnC disk确认盘的在线状态用bdf看文件系统使用率用vgdisplay、lvdisplay看逻辑卷状态。文件系统满是很常见的故障源报错是No space left on device。这里有个坑bdf看着还有空间但应用就是写不进去八成是 inode 耗尽df -i一看便知。inode 耗尽的典型原因是某个目录下堆了海量小文件比如临时文件或者日志没清理找到那个目录清掉就好。还有一种情况是删除大文件后bdf显示空间没释放那是有进程还持有该文件的句柄fuser或lsof找到进程重启即可。磁盘链路问题要结合 HBA 和光纤交换机的日志一起看。如果 syslog 里某块盘反复link down又link up先换光纤或者换端口试试别急着换盘——很多时候盘是好的问题在链路。我踩过一次坑盯着盘换了两次没解决最后发现是 HBA 卡的一个端口有问题换卡就好了。日志里 HBA 相关的报错关键词要单独留意。4.3 网络与HBA链路故障的联合排查网络故障在 syslog 里通常表现为link down、link up成对出现或者duplex mismatch、frame error、carrier lost。单次 link 抖动可能是对端重启或者光模块问题频繁抖动就要查物理层。排查时先把报错时间点和网络监控的丢包时间点对齐确认是同一个问题再看是哪个网卡实例用lanscan、nwmgr确认网卡状态和速率配置。HBA 链路故障的表现类似但影响的是存储访问。syslog 里会看到fiber channel、HBA、target相关的报错配合ioscan -fnC fc和fcmsutil可以看链路状态和端口统计。如果 HBA 报错和磁盘 I/O 报错在时间上高度重合基本可以判断是存储链路问题而不是单块盘的问题。这类故障的排查心得是不要孤立地看网络或存储小机的网络和存储在物理层经常是交叉的比如同一块背板、同一个 PCI 域日志里两类报错同时出现时要往物理层的公共部件上想。另外网络和 HBA 的报错密度是判断严重程度的好指标偶发和持续的处理方式完全不同。4.4 登录失败与安全审计的日志线索lastb输出突然变长或者 syslog 里sshd记录出现大量Failed password说明有人在尝试登录。这时候要做三件事看来源是否集中集中说明是针对性扫描、看尝试的用户名是否规律比如一直试 root 或者常见弱口令用户名、看时间跨度短时间高频说明是自动化工具。处理动作上先确认没有成功登录的记录last里看有没有异常来源的成功登录再评估是否需要网络层限制。syslog 里sshd的成功登录记录会带来源 IP跟last的输出能对上。如果发现某个账号在非工作时间从异常来源登录成功要立即改密码并排查该账号的操作历史。审计类日志的日常价值在于建立基线。平时什么样是正常的出了异常才能一眼看出来。建议定期比如每周把last、lastb、sulog扫一遍心里有数真出事时不慌。5. 日志轮转、归档与长期运维5.1 syslog.conf的配置要点/etc/syslog.conf决定哪些消息写到哪个文件。默认配置通常把大部分消息写进syslog.log但有些机器会把mail、cron、auth分开写到独立文件具体看配置。改这个文件的原则是只加不减、改完重启 syslogd。加一条规则比如把local0设施的消息单独写到某个文件格式是local0.* /var/adm/syslog/app.log注意设施和级别之间是点号路径前面是制表符或者空格具体看版本要求用cat -A确认一下更稳妥。改完配置要kill -HUP或者重启 syslogd 让配置生效。这里有个坑配置写错了 syslogd 可能起不来或者不写日志改之前先备份改完立刻验证日志有没有正常写入。另外 syslog 的级别debug、info、notice、warning、err、crit决定了记录的详细程度生产环境不建议开debug会刷爆日志文件。5.2 日志轮转与空间管理日志轮转没配好是小机运维的经典隐患。/var分区被日志撑满轻则写不进新日志重则影响业务比如某些服务需要写临时文件。管理策略有三条一是确认轮转机制存在cron 里的轮转脚本或者 logrotate 类工具二是设定合理的保留份数syslog 保留 3 到 5 份足够三是定期清理陈旧的崩溃转储和诊断报告。/var/adm/crash/下的崩溃转储文件可能非常大几个 G 很常见确认不需要保留后及时清理。/var/stm/logs/和/var/stm/data/也会累积诊断数据定期归档或清理。清理前务必确认文件不再需要——崩溃转储在排查完根因之前不要删这是还原故障现场的唯一材料。注意清理日志前先用du -sh看清各目录占用别一上来就rm -rf误删正在被进程写入的日志文件可能导致进程异常。清理后确认对应服务状态正常。5.3 建立日志巡检机制日志巡检不难难在坚持。我的做法是列一个清单每周花二十分钟过一遍ls -lh /var/adm/syslog/看文件大小和轮转是否正常grep -ic error看报错数量有没有异常增长last reboot看有没有非计划重启lastb | wc -l看失败登录数量df -k和df -i看文件系统和 inode 使用率。这几项过完机器的健康度心里就有底了。更进一步的做法是给关键报错设阈值告警比如 syslog 里Memory error或Disk I/O error一分钟内超过 N 条就触发通知。这个可以写个简单的 shell 脚本配合 cron 实现不需要复杂工具。核心思路是让机器自己喊疼而不是等人去翻。巡检机制建起来之后很多故障能在萌芽阶段就被处理掉不至于演变成停机事故。6. 常见问题速查与踩坑心得6.1 日志排查速查表现象首选日志关键命令/关键词常见根因机器无故重启shutdownlog、rc.log、sysloglast reboot、grep panic人为操作、硬件故障、电源事件业务连不上syslog.loggrep sshd、grep network服务未启动、端口占用、链路断开文件写不进去syslog.loggrep No space、df -k、df -i空间满、inode 耗尽、句柄未释放磁盘报错syslog.log、EMS 日志grep I/O error、ioscan -fnC disk盘故障、HBA 故障、链路不稳内存告警syslog.loggrep -i memory error|ECC内存条老化、单比特/多比特错误登录异常btmp、sulog、wtmplastb、last、cat sulog暴力尝试、账号异常使用服务启动失败rc.log、syslog.loggrep FAIL、grep failed配置错误、权限问题、依赖缺失这张表不是万能的但能覆盖日常八成以上的场景。遇到表里没有的回到四步筛选法按时间、来源、关键词、密度往下走。6.2 几个容易踩的坑第一个坑是只看 syslog 不看启动日志。机器重启类问题syslog 往往在崩溃瞬间就断了真正的关机方式和启动结果在 shutdownlog 和 rc.log 里。只看 syslog 会得出日志突然中断的错误结论。第二个坑是忽略日志文件的增长速度。syslog 一天涨几百兆说明有问题在持续刷屏但业务可能暂时无感。等文件系统被撑满问题就从隐患变成事故了。定期看文件大小比事后救火省心得多。第三个坑是报错只看单条不看上下文。syslog 里一条服务启动失败背后可能是前面十行的配置读取错误只盯着报错行会漏掉根因。养成看前后二十行的习惯。第四个坑是清理日志不看进程状态。直接删掉正在被写入的日志文件空间可能不释放句柄还在或者导致进程写日志异常。正确做法是先停相关服务或者用 文件的方式清空而不是rm。第五个坑是硬件报错不当回事。单比特内存错误、偶发 I/O 错误看着不影响业务但它们是硬件劣化的早期信号。日志里出现这类记录该记录记录、该报修报修别等它变成多比特错误或者盘彻底掉线。我自己在小机上踩得最深的一次是某台机器的 syslog 里连续几天出现磁盘超时因为业务一直正常就没管结果某天盘阵的一个控制器切了业务中断两小时。事后翻日志所有的前兆都写在那里只是没人看。从那以后我对日志里重复但不致命的报错特别敏感——它们不是噪音是机器在提前打招呼。