2026年服务器日常巡检监控告警考核押题卷及答案

2026年服务器日常巡检监控告警考核押题卷及答案一、单项选择题（每题2分，共20分）1.Linux系统中，查看系统整体负载平均值的命令是？A.df-hB.uptimeC.free-mD.netstat-an2.一般建议服务器磁盘使用率告警阈值设置为多少比较合理？A.50%B.70%C.80%D.95%3.以下哪个命令用于查看Linux系统内存使用情况？A.du-shB.iostatC.free-hD.lsblk4.在systemd系统中，查看某服务（如nginx）运行状态的正确命令是？A.servicenginxstatusB.systemctlstatusnginxC.chkconfignginxstatusD.psnginx5.下列哪项不属于服务器硬件健康监控的常见指标？A.CPU温度B.风扇转速C.磁盘SMART状态D.HTTP请求数6.Linux系统中，查看磁盘I/O使用情况的命令是？A.iostatB.topC.freeD.ping7.监控系统检测到某服务器网络接口持续10分钟丢包率达到30%，应优先采取的措施是？A.立即重启服务器B.检查交换机端口、网线、网卡及链路状态C.忽略，等待自动恢复D.增加服务器带宽8.关于告警收敛（抑制），下列说法正确的是？A.收敛会增加告警数量B.收敛可以让同一故障只产生一条有效告警，减少告警风暴C.收敛是删除所有告警D.收敛只用于邮件告警9.查看Linux系统日志中内核级错误信息通常使用哪个命令？A.dmesgB.dfC.topD.ls10.服务器CPU负载（loadaverage）持续高于CPU逻辑核心数多少倍，通常认为系统严重过载？A.0.5倍B.1倍C.2倍D.5倍二、多项选择题（每题3分，共15分。错选、多选、漏选均不得分）1.服务器日常巡检通常包括以下哪些内容？A.CPU使用率B.内存使用率C.磁盘空间使用率D.关键服务进程状态2.常见的监控告警级别包括？A.Info（提示）B.Warning（警告）C.Critical（严重）D.Recovery（恢复）3.使用top命令可以实时查看以下哪些信息？A.CPU总体使用率B.内存使用情况C.各进程资源占用D.磁盘分区使用率4.网络监控中常用的性能指标包括？A.带宽利用率B.丢包率C.网络延迟（RTT）D.TCP连接数5.一次完整的告警处理闭环应包括哪些环节？A.告警接收与确认B.故障定位与排查C.故障处理与恢复D.告警关闭与复盘总结三、判断题（每题1分，共10分）1.Linux系统中，df-h可查看各挂载分区的使用情况。2.服务器内存使用率达到100%时，系统一定会立即崩溃。3.监控告警系统只能发送邮件通知，不能对接短信、电话等渠道。4.定期巡检可以完全替代实时监控告警。5.告警阈值设置得越低，监控效果越好。6.服务器RAID卡电池或电容状态异常可能影响写缓存，应纳入巡检范围。7.Linux系统中，/var/log/messages是常见的系统日志文件。8.网络接口出现少量零星丢包（如小于0.1%）时，也必须立即触发严重告警。9.systemctllist-units--type=service可以列出当前已加载的服务单元。10.服务器巡检中发现磁盘SMART报告大量重映射扇区增长，应立即备份数据并准备更换磁盘。四、简答题（每题5分，共15分）1.简述服务器日常巡检的主要项目（至少列出5项）。2.监控告警阈值的设置应遵循哪些原则？3.收到服务器CPU使用率过高告警后，请简述排查思路。五、案例分析题（每题20分，共40分）1.某Web服务器磁盘使用率告警，/分区使用率在2小时内从60%增长到92%。业务部门反馈网站访问缓慢，部分上传功能异常。请分析可能原因，给出详细排查步骤和处理措施。2.某业务服务器内存使用率持续95%以上并触发告警，业务响应变慢但未完全中断。该服务器配置32GB内存，运行Java应用和MySQL数据库。请给出排查思路、可能原因及优化建议。参考答案与解析一、单项选择题1.答案：B解析：uptime可显示当前时间、系统运行时长、登录用户数以及1分钟、5分钟、15分钟的平均负载。df查看磁盘使用，free查看内存，netstat查看网络连接。2.答案：C解析：磁盘使用率达到80%时通常触发预警，以便在写满前有时间处理；超过95%则视为紧急告警。过低会导致频繁误报，过高则失去预警意义。3.答案：C解析：free-h以易读格式显示内存总量、已用、空闲、共享、缓冲/缓存及可用内存。du用于统计文件或目录大小，iostat查看I/O，lsblk查看块设备。4.答案：B解析：systemd系统中使用systemctl管理服务，status子命令可查看服务活动状态、PID、日志片段等。5.答案：D解析：HTTP请求数属于应用层或业务监控指标，不属于硬件健康监控。CPU温度、风扇转速、磁盘SMART均为硬件健康指标。6.答案：A解析：iostat用于报告CPU统计信息和设备、分区的输入/输出统计，是磁盘I/O监控常用工具。7.答案：B解析：持续高丢包率通常由物理链路故障、端口协商异常、网卡故障或网络拥塞引起，应优先从链路层排查。盲目重启或增加带宽不能解决根本问题。8.答案：B解析：告警收敛或抑制是指对同一故障源产生的多条重复告警进行合并、压缩，避免短时间大量告警冲击运维人员。9.答案：A解析：dmesg用于显示内核环形缓冲区内容，常用于查看硬件错误、驱动异常、OOM等内核级信息。10.答案：C解析：loadaverage超过逻辑核心数1倍说明有任务等待CPU，超过2倍通常认为系统严重过载并需要介入处理。二、多项选择题1.答案：ABCD解析：日常巡检应覆盖计算、存储、网络、服务等主要维度，上述四项均为基本巡检项目。2.答案：ABC解析：Recovery是故障恢复后的通知类型，不属于告警级别。常见告警级别一般包括Info、Warning、Critical、Emergency等。3.答案：ABC解析：top命令可实时显示CPU、内存、进程列表及资源占用，但无法查看磁盘分区使用率，后者需使用df命令。4.答案：ABCD解析：带宽利用率、丢包率、延迟和TCP连接数均为网络监控的核心指标，可反映网络质量与负载情况。5.答案：ABCD解析：完整的告警闭环应包含接收、确认、定位、处理、恢复、关闭、复盘等环节，缺少任一环节都可能导致问题重复发生或遗漏。三、判断题1.答案：正确2.答案：错误解析：Linux会使用swap或触发OOMKiller机制，不一定立即崩溃，但会导致性能严重下降甚至进程被杀。3.答案：错误解析：现代监控系统普遍支持邮件、短信、电话、即时通讯工具、webhook等多种通知方式。4.答案：错误解析：定期巡检与实时监控互补。巡检可以发现趋势性问题，但无法及时捕获突发故障，实时监控告警才能实现快速响应。5.答案：错误解析：阈值过低会产生大量误报和告警疲劳，导致运维人员忽略真正严重的告警。6.答案：正确7.答案：正确8.答案：错误解析：偶发轻微丢包可能是瞬时网络波动，应设置合理阈值和持续时间条件，避免误报。9.答案：正确10.答案：正确四、简答题1.答案：(1)CPU使用率与负载平均值；(2)内存使用率与swap使用情况；(3)磁盘空间使用率与磁盘I/O；(4)网络连通性、丢包率与延迟；(5)关键服务进程运行状态；(6)硬件健康状态，包括温度、风扇、电源、RAID卡状态；(7)系统日志异常情况；(8)安全补丁更新时间与时钟同步状态。解析：日常巡检旨在提前发现趋势性问题和潜在风险，应覆盖服务器计算、存储、网络、服务、硬件、安全等核心维度，避免单点遗漏。2.答案：(1)结合业务特点和历史基线设定合理阈值，而非一刀切；(2)区分不同告警级别，设置预警、警告、严重等多级阈值；(3)避免阈值过低导致大量误报，也避免过高导致漏报；(4)对关键指标设置持续时间和触发次数条件，避免瞬时抖动触发；(5)定期回顾和调整阈值，适应业务增长和架构变化。解析：合理的阈值设置是监控系统有效运行的关键，需平衡灵敏度和误报率，并结合实际运维经验不断优化。3.答案：(1)使用top或htop查看占用CPU最高的进程及CPU使用率；(2)结合loadaverage判断是CPU资源不足还是单个进程异常；(3)查看相关进程日志和应用日志，确认是否为正常业务高峰、程序死循环或代码bug；(4)检查是否有异常进程、挖矿木马或外部攻击行为；(5)若为短期业务高峰，可考虑限流、扩容或优化代码；若为程序缺陷，则修复后重启服务并持续跟踪。解析：CPU过高可能由多种原因引起，排查思路应遵循“先定位进程、再分析原因、后采取措施”的顺序，避免盲目重启掩盖根因。五、案例分析题1.可能原因：(1)日志文件异常快速增长，如遭受攻击或应用错误导致大量日志输出；(2)上传目录或临时目录未及时清理，文件大量堆积；(3)数据库备份、日志归档文件残留；(4)应用异常产生核心转储文件或大文件；(5)日志轮转（logrotate）失效，导致单个日志文件持续增大；(6)已删除文件仍被进程占用，磁盘空间未释放。排查步骤：(1)使用df-h确认/分区使用率及剩余空间；(2)使用du-sh/*或ncdu/定位占用空间最大的目录；(3)重点检查/var/log下各日志文件大小，确认是否异常增长；(4)检查Web服务器（nginx/apache）访问日志和错误日志，分析是否存在大量异常请求或错误；(5)检查应用上传目录、临时目录/tmp、/var/tmp是否有大量未清理文件；(6)检查是否有备份文件、压缩包残留在根分区；(7)检查logrotate配置文件是否正常，是否存在轮转失败；(8)使用lsof|grepdeleted查看已被删除但仍被进程占用的文件句柄，必要时重启相关服务释放空间。处理措施：(1)清理可安全删除的临时文件、备份文件和过期日志；(2)修复日志轮转配置，确保日志定期切割和压缩；(3)对上传目录配置独立分区或磁盘配额，防止写满根分区；(4)配置磁盘使用率分级告警，提前预警；(5)优化应用日志输出级别，减少非必要日志；(6)若磁盘空间仍不足，可在线扩容或迁移部分数据到独立磁盘。解析：磁盘使用率快速上升通常与日志或文件堆积有关。排查时应先定位空间占用，再结合业务日志和应用行为分析根因。处理时要同时解决当前空间不足和防止后续复发，形成闭环。2.排查思路：(1)使用free-h查看内存总量、已用、buffer/cache、swap使用情况，判断是实际内存不足还是缓存占用过高；(2)使用top或htop按内存排序，找出占用内存最多的进程；(3)检查Java进程的启动参数（-Xmx、-Xms）以及GC日志，判断是否频繁FullGC或发生内存泄漏；(4)检查MySQL的内存相关参数，如innodb_buffer_pool_size、max_connections等，评估内存占用是否合理；(5)查看/var/log/messages或dmesg，检查是否有OOMKiller记录；(6)使用ps-eopid,ppid,cmd,%mem,rss--sort=-%mem或pmap、jmap等工具分析内存分布；(7)判断高内存占用是cache/buffer可回收部分还是进程实际占用。可能原因：(1)Java堆内存设置过大，且存在内存泄漏，导致堆持续增长；(2)MySQL缓存参数配置过大，占用大量物理内存；(3)系统cache/buffer占用较高但属于正常可回收内存，监控未区分导致误报；(4)应用存在内存泄漏或未释放的数据库连接；(5)swap使用增多，导致性能下降；(6)异常进程或外部攻击导致内存异常消耗。优化建议：(1)调整Java堆内存大小和垃圾回收器，结合GC日志优化堆分配；(2)优化MySQL参数，如适当降低innodb_buffer_pool_size或限制ma