简介这份《DELL服务器日常点检表》适用于服务器运维、系统管理员及企业IT支持人员面向DELL PowerEdge等机架/塔式服务器的日常巡检与故障排查场景。文档以服务器状态指示灯、电源按钮、硬盘驱动器灯、NIC显示灯为线索系统说明各组件状态含义并对蓝色常亮、琥珀色闪烁、绿色持续亮起等灯态给出正常或故障的对应判断同时提示可结合LCD面板、驱动器状态指示灯补充定位问题。资源还提供可直接使用的点检表模板便于按日记录硬件状态、系统日志与运维备注帮助快速定位异常、降低宕机风险。资源为单个PDF文件压缩包仅216KB轻量便携适合打印或导入移动设备现场查阅。目前已有114人学习下载内容虽精简但覆盖硬件点检、系统日志检查、故障诊断与维护保养要点可作为企业服务器巡检制度和新人上手操作手册的参考底稿。1. 这份点检表到底在解决什么服务器日常点检这件事绝大多数团队都做得不到位。不是大家不重视而是手工巡检本身充满了“不确定性”今天用ssh登上去看一眼负载明天忘了看日志后天新来的同事压根不知道要查什么。DELL服务器因为自带iDRAC和OMSA这套还算完整的管理体系在巡检上其实有非常明确的边界——但前提是你得知道该把这些命令、状态码、阈值落在哪里。这份点检表的价值不在于那张表格本身而在于它把“经验驱动”变成了“流程驱动”电源冗余状态、磁盘背板温度、SEL日志里的ECC错误计数、RAID阵列的rebuild进度每一项都有可量化的判据。我见过不少运维手里有表格但要么画得过于复杂导致每天根本填不完要么漏掉了DELL最有价值的iDRAC告警和PERC控制器日志。真正合理的日常点检应该控制在15分钟内完成并且只盯那些“出问题前有征兆”的指标。这篇文章会从巡检的整体逻辑开始把DELL独有工具链里的核心命令、判据和参数拆开来讲最后给出一份可以直接改造成自家基线模板的思路。如果你现在的做法还是定期登服务器看一眼负载就完事说明你还没用到点检表真正的潜力——它是一套把故障拦截在SEL事件爆发之前的预警机制。2. 用iDRAC做巡检为什么这是DELL巡检的第一数据源2.1 IPMI命令的可用性是点检的前提DELL服务器的iDRAC提供了带外管理通道这意味着即使操作系统不可达你依然能拿到关键硬件状态。日常巡检里最常见的坑是服务器上装了OMSA于是所有巡检都依赖操作系统里的omreport结果某次内核崩溃或者网络栈卡死整台机器的硬件状态就完全失明了。正确的做法是把带外IPMI作为第一数据源带内OMSA作为辅助。IPMI的命令走的是UDP 623端口只要iDRAC的独立网口NIC1配置了管理IP巡检就不受业务系统影响。先确认iDRAC的连通性和固件版本这是后续一切命令能跑通的前提。连接测试可以用ping但更稳妥的是直接用ipmitool跑一条只读命令能通就说明认证和网络都没问题ipmitool -I lanplus -H 192.168.1.10 -U root -P calvin -c sel elist last 5-I lanplus指定使用IPMI 2.0的加密协议-c让输出变为逗号分隔便于后续用awk或grep处理。如果这条命令返回了SEL条目或Entries in SEL提示说明iDRAC的RMCP端口可用。如果报错Unable to establish IPMI session要优先检查管理口IP、网关和iDRAC用户权限而不是先怀疑服务器坏了。2.2 SEL日志解析是巡检的核心动作SELSystem Event Log记录了硬件层面的所有关键事件包括ECC内存纠错、CPU过热、VRD电压异常、风扇转速低于阈值等。日常巡检里最容易忽略的是ECC事件的“低频出现”单次可纠正内存错误不足以让系统宕机但如果每天都能看到新条目说明这条内存的CE计数正在累积未来大概率会升级为UE不可纠正错误。以下命令把SEL中的ECC相关事件单独摘出来ipmitool -I lanplus -H 192.168.1.10 -U root -P calvin sel elist | grep -i ECC\|correctable\|uncorrectable如果输出为空说明在该SEL分区里没有内存纠错事件这是正常的。真正需要关注的是事件的频率和类型。为了准确判断可以配合sel time get来核对事件时间戳避免把几周前的旧事件误判为当天发生。iDRAC的SEL默认能存约1024条记录存量满后会覆盖最老的条目所以巡检频率至少应该保证在SEL写满之前能把日志收集归档一遍。2.2.1 用sel save做离线归档只在屏幕上看到SEL列表是不够的巡检应该把日志落盘形成可追溯的时间序列。常用做法是每次巡检都做一次全量导出并以日期命名ipmitool -I lanplus -H 192.168.1.10 -U root -P calvin sel save /opt/check/deLL_r720_$(date %Y%m%d).sel这个二进制的SEL文件可以直接用于后续比对也可以用ipmitool -f回放成可读文本。归档的意义在于当内存ECC事件是每天1次还是每小时10次单看当前快照根本分不清必须有历史记录对比。我一般会在点检表里留一列专门写“与昨日SEL条数差”差值突然变大往往比具体错误码更早暴露硬件退化。2.3 iDRAC电源和风扇指标的量阈值电源状态和风扇转速是iDRAC带外巡检中信息量最大的两个指标。DELL服务器的电源模块PSU通常成对配置IPMI里可以读取每个电源的输入功率、输出功率和状态ipmitool -I lanplus -H 192.168.1.10 -U root -P calvin sdr type Power Supply输出里的Status字段如果是ok不代表电源真的健康。还需要对比两台电源的输出功率是否均衡如果一台输出300W另一台只有50W说明负载分配策略异常或其中一颗电源已经降级。风扇方面DELL的PowerEdge服务器正常工作时PWM转速会随负载动态调整巡检时只需要确认没有风扇处于Fail或Predictive Failure状态同时记录所有风扇转速的最大值。风扇的绝对转速值不同型号差异很大R730的A类风扇在23°C环境下的待机转速约5000 RPM而R940的冗余风扇会达到8000所以判据应该是“同一台机型的横向对比”而不是用固定数字一刀切。3. 用OMSA命令做硬件自检磁盘和阵列的状态判读3.1 为什么带内巡检选OMSA而不是只依赖iDRACiDRAC能覆盖电源、风扇、温度、SEL这些带外指标但磁盘SMART信息、RAID阵列的逻辑卷状态、BBU电池备份单元的充放电周期这些数据iDRAC里要么不完整要么延迟明显。DELL的OMSAOpenManage Server Administrator在操作系统内部封装了完整的存储控制器查询接口命令行的核心是omreport。日常巡检里判断一块物理盘是否即将故障最可靠的依据是SMART里的Reallocated Sector Count和Current Pending Sector计数这两项在iDRAC的Storage页面里看不到完整历史只能靠OMSA。OMSA没装或者服务挂了会直接导致带内巡检失效所以点检表的第一项检查就是服务状态systemctl status dsi_amtsd.service 2/dev/null || systemctl status dataengOMSA在systemd下对应的服务名在不同版本中不同DSET采集服务也经常被误当成OMSA主服务。如果服务无法启动优先看/opt/dell/srvadmin/var/log/dsi_amtsd.log和srvadmin-storage的安装情况。这是DELL服务器巡检最常见的坑服务装了但没设开机自启重启一次就全白查。3.2 用omreport读取RAID控制器全局视图在确认OMSA服务运行后第一个命令应该是查询存储控制器的总览这决定了后面的巡检路径omreport storage controller输出的关键字段是Controller Status和PFA StatusPredictive Failure Analysis。Controller Status为Ok只代表控制器本身没坏真正的隐患藏在PFA Status的非None状态里。PFA一旦标记某块磁盘有预测性故障说明该盘已经在控制器内部被判了“缓期执行”这时候点检表应该把该盘标记为Warning并规划窗口期更换。3.2.1 检查虚拟磁盘和物理磁盘的状态链控制器状态正常后再逐层往下查Virtual Disk和Physical Disk。虚拟磁盘对应操作系统看到的逻辑盘物理磁盘则是背板上的实体盘。这里的巡检逻辑是如果虚拟磁盘Status变成Degraded说明阵列里有一块物理盘离线如果Status是Failed则阵列已经失效必须立即介入。用以下命令把完整链路打出来omreport storage vdisk omreport storage pdisk controller0pdisk输出里Status字段有Ok、Non-Critical、Critical、Failed四档。巡检时重点看Critical和Non-Critical其中Non-Critical常见于磁盘SMART告警或Global Hot Spare盘被占用而Critical说明出现了Failed盘或重建中断。这里有个参数容易被忽略Bus Protocol字段如果是SAS还是SATA决定了该盘在背板上的物理位置点检表里记录盘位时必须以Enclosure:Connector:Target格式为准而不是操作系统里的/dev/sdb——后者重启后可能变化。3.3 磁盘SMART参数的阈值与记录方法SMART全量信息可以通过omreport拿到但逐条读太长。日常巡检要抓的只有三个属性Reallocated Pending Sector、Reallocated Sector Count、Temperature。这三个值藏在omreport storage pdisk controller0输出的Mechanical Properties或SMART Info字段里部分新旧版本OMSA的字段名有差异所以更通用的做法是读原始SMARTsmartctl -a /dev/sdb -d megaraid,4-d megaraid,4里的4是PERC控制器下的Enclosure Device ID不是操作系统看到的盘序。这个参数最容易踩坑/dev/sdb对应的物理盘序号必须通过omreport storage pdisk查然后映射到megaraid的设备号。如果直接跑smartctl -a /dev/sdb不带-dPERC尤其是H730、H740以上通常返回Device would block错误。温度这个指标的阈值没有统一标准DELL官方对SAS盘的警告阈值一般是55°CSATA盘是50°C。但这只是“不触发告警”的底线巡检里如果发现盘温超过45°C就应该检查散热风道和RAID卡上的散热片是否积灰因为PERC控制器本身过热会导致降速进而让磁盘写入延迟上升最终表现为应用层iowait异常而硬件日志无告警。4. 收集DSET日志故障定界和开Case的标准动作4.1 DSET在点检里的定位DSETDell System E-Support Tool是DELL服务器做硬件故障定界时采集全量信息的官方工具。日常巡检里它不该每天都跑因为全量采集会产生数百MB的日志包耗时十几分钟。但在两种场景下它是必选项一是SEL里出现Critical级别告警需要定位时二是准备向DELL开硬件支持工单时。没有DSET包的工单厂商客服通常会先要求你补采集一来一回时间浪费很严重。DSET起一个收集命令会做这些事把所有SEL条目、RAID控制器日志包含BBC电池充放电历史、BIOS设置、OMSA收集到的存储状态、操作系统日志、firmware版本列表一次性打包。它对巡检的真正价值是作为“定界快照”——判断某个告警是物理硬件还是驱动层引起DSET包里的LSI日志能直接看到PERC控制器的内部异常。4.2 在Linux下用命令行触发DSET收集DSET在Linux下的命令行收集和Windows版一样建议用长期运行的Linux机器做远程采集。以下命令把采集内容压缩包放到指定目录/opt/dell/toolkit/bin/dset --version /opt/dell/toolkit/bin/dset collect -c 0 -f /opt/check/dell_r720_$(date %Y%m%d)_dset.zip-c 0指定采集级别为0最低级别只保留硬件和存储核心日志不含完整OS日志适合日常故障定位。如果要开Case给厂商建议不加-c参数直接采集全量。参数里的-f指定输出文件路径注意DSET输出的zip文件名末尾带时间戳不要为了图省事用固定文件名覆盖否则后续对比版本差异时会丢失关键历史。4.2.1 根据收集包快速定位日志位置DSET生成的压缩包结构固定解压后进入DSET目录能看到分好类的子目录。真要快速找到硬件核心日志不需要解压整个包unzip -l dell_r720_20250312_dset.zip | grep -i SEL\|LSA\|amdtee\|hardwareSEL在包内通常以sel_*.txt形式存放LSA是LSI阵列控制器的日志片段。如果你把DSET收集做成每周一次的巡检动作解压包内的BIOS版本和iDRAC固件版本做一个当前基线表对后续升级固件能否回退有直接的参考价值。DELL的BIOS降级经常因为Downgrade Prevention策略被拒而DSET里的固件历史可以告诉你上一次升级是从哪个版本上来的从而决定是否需要先清SEL再降级。5. 设计一张能落地的点检表模板字段、周期与责任5.1 点检表的字段设计一张合格的点检表必须同时满足两个约束新人看着能操作老手看字段就能判断风险。字段不能全是“正常/异常”这种二元选项因为硬件的很多状态是“可疑但还没病发”的中间态。参考行业里成熟的巡检模板日常点检的字段分为四类基础身份信息机器名、Service Tag、iDRAC IP、带外指标电源、风扇、温度、SEL、带内指标OMSA服务、RAID状态、SMART关键属性、事件记录最近一次硬件变更、上次出现的事件码。我一般会在表格里加一列“趋势标记”记录本次巡检数值与上次的差值。这一步对付飘忽不定的问题很有效——比如磁盘温度今天38°C明天39°C单看都没事但如果连续三天都在上涨即使还没到50°C告警线也说明风道出了问题。点检表里如果没有“趋势”这个维度就永远只能在故障发生之后去SEL里翻时间线。5.2 用SQLite做本地巡检记录给点检表加索引直接维护Excel总有人会漏填日期或填错机房位置常见做法是把结果落到一个本地SQLite数据库里Excel只负责临时展示。用sqlite3建表巡检项作为record表字段如下CREATE TABLE check_log ( hostname TEXT, service_tag TEXT, check_date DATE, sel_count INTEGER DEFAULT 0, psu_status TEXT, fan_max_speed INTEGER, vdisk_status TEXT, pdisk_count INTEGER, pending_sectors INTEGER DEFAULT 0, note TEXT ); CREATE INDEX idx_check_date ON check_log (check_date, hostname);sel_count记录当天SEL总条目数下一次巡检时直接和这个值做减法新增数量才是要关注的动作。设计这个表时关键在pdisk_count它不代表磁盘数量而是代表有多少块盘处于非Ok状态初始化为0即可。这样在页面上只用一个where pdisk_count 0就能拉出所有有隐患的机器列表。5.3 点检频率和巡检路径编排DELL服务器的点检频率应该按机器的层级分开核心业务数据库服务器每天查SEL和电源状态普通应用服务器每周查一次整套OMSA状态离线备份服务器每月做一次全量硬体检。不要为了省事统一成一种频率——冷备服务器一个月才需要看一次而核心库的电源模块如果第二颗PSU已经亮黄灯必须当天处理不可能等周巡检才发现。巡检路径的编排原则是先带外后带内先状态后性能。带外IPMI能确认机器是否还活着、电源风扇是否正常带内OMSA再确认存储链路和RAID健康最后才登录操作系统看dmesg里有没有storage相关报错。按这个顺序如果带外就已经发现Critical状态带内的存储巡检就可以跳过直接进入故障处理流程节省时间也避免重复告警混淆判断。6. 自动化巡检脚本把点检表从Excel里解放出来日常点检表最大的敌人是“人忘了执行”。与其寄希望于员工的自觉性不如把巡检动作写成脚本由cron驱动结果自动写入SQLite。以下是适合大多数机房的最小自动化方案跑在一台管理机上不需要在每台服务器里装agent。先定义变量把服务器IP和凭据独立写在配置文件里避免脚本里硬编码密码HOSTS_FILE/opt/check/hosts.conf IDRAC_USERroot IDRAC_PASScalvin DB_FILE/opt/check/dell_check.db cat /opt/check/hosts.conf # r730-db01 192.168.1.10 # r720-app01 192.168.1.11巡检主脚本核心部分把单个循环单独拿出来方便扩展#!/bin/bash while read -r hostname ip; do if [[ -z $hostname || $hostname \#* ]]; then continue; fi sel_count$(ipmitool -I lanplus -H $ip -U $IDRAC_USER -P $IDRAC_PASS sel elist 2/dev/null | wc -l) psu_status$(ipmitool -I lanplus -H $ip -U $IDRAC_USER -P $IDRAC_PASS sdr type Power Supply 2/dev/null | grep -c ok) fan_status$(ipmitool -I lanplus -H $ip -U $IDRAC_USER -P $IDRAC_PASS sdr type Fan 2/dev/null | grep -c ok) sqlite3 $DB_FILE INSERT OR REPLACE INTO check_log(hostname,check_date,sel_count,psu_status,fan_max_speed) VALUES($hostname,date(now),$sel_count,ok:$psu_status,ok:$fan_status); done $HOSTS_FILE这段脚本里的三个shellcheck级错误值得说明grep -c在匹配不到时返回退出码1脚本没加set -e不会中断但sel_count会错误写为0密码里的特殊字符会在命令行里被当成通配符多台机器如果IPMI命令超时整个循环会卡在默认的5秒重试上建议给ipmitool统一加-N 1 -T 3把超时缩短避免脚本运行时间被拖到几个小时。这个自动化方案有一个必须处理的边界当SEL里出现内存ECC事件时sel_count的增加量可能只有1~2条直接看绝对数没有感知。所以判断逻辑应该用昨天的sel_count和今天相减差值超过5时才发告警。按照这个思路再加一层校验把巡检结果里最值得关注的逻辑写成一个独立判据脚本避免把所有事件一股脑发出来当vdisk_status出现Degraded、psu_status出现Critical、sel_count日增超过阈值时才触发通知。这个判据脚本才是自动化巡检的真正核心——采集动作能跑通只是及格线能不能把海量日志变成清晰的告警决定了这套方案在真实生产环境里活得过几天。本文还有配套的精品资源点击获取