Linux服务器巡检报告PDF生成实战指南

简介本资源是一份完整的Linux服务器日常巡检标准化报告模板与实操指南面向运维工程师、系统管理员及Linux初学者解决生产环境中服务器健康状态快速评估与问题预判难题。报告覆盖硬件配置核验、操作系统基础检查、CPU/内存/交换区性能监控、Top命令逐字段解读、多维度安全审计用户登录、文件系统占用、账户安全、端口开放等以及网络连通性验证内容详实、标准明确、可直接套用。资源为单个PDF文件共1个文件大小561KB轻量易读适合作为巡检checklist随身查阅或新人培训材料。目前已有360人学习下载读者可直接获取结构清晰的巡检流程框架、每项检查的操作命令、参考阈值标准如CPU80%、df80%、典型输出解析及异常判定依据显著提升巡检效率与规范性。1. 为什么一份 Linux 服务器巡检报告 PDF比“服务正常”四个字值十倍运维时间你刚收到一条钉钉消息“线上服务响应变慢麻烦看下”。登录跳板机top、htop、iostat 跑一遍发现 CPU 峰值 92%、磁盘 await 飙到 80ms——但两小时后又自己回落了。你补了个 crontab 记录 sar 数据却再没复现。这种“幽灵故障”不是没发生而是没被结构化捕获。Linux 服务器巡检报告.pdf就是把这种模糊感知变成可回溯、可比对、可归因的证据链它不只告诉你“磁盘忙”还告诉你“/var/log 下 37 个日志文件单日增长超 2GB其中 nginx.access.log 占 64%且 last_rotate 时间距今 19 天”它不只写“内存使用率 85%”还标注“slab 内存占用 3.2GB占总内存 41%dentry 缓存占比达 78%”。这不是运维日报而是给服务器做 CT 扫描的影像报告。适合所有需要对生产环境稳定性负责的人SRE、DBA、安全工程师、甚至要写交付文档的外包团队。它解决的不是“能不能连上”而是“为什么上次升级后MySQL 的 page-fault/sec 突增 3 倍却没告警”——这种问题永远藏在离散命令输出的缝隙里。2. 从零生成一份可落地的巡检报告 PDF核心工具链与数据采集逻辑生成一份真正有用的巡检报告绝不是top report.txt然后转 PDF 那么简单。关键在于采集什么、何时采集、如何结构化、怎么排除噪声。我一般会用三类工具分层协作基础指标采集器sar / vmstat、状态快照工具ps / lsof / ss、以及深度诊断探针如 slabtop、inotifywait。它们的数据不是平铺直叙堆砌而是按“资源维度”组织CPU、内存、磁盘 I/O、网络连接、进程健康、内核参数、日志风险。下面拆解最核心的采集逻辑和最小可行脚本。2.1 用 sar cron 构建带时间戳的系统基线数据库sar是 Linux 内置的瑞士军刀但它默认不持久化数据。直接sar -u 1 5只能看实时而巡检需要对比“今天早高峰 vs 上周同天”。所以第一步是启用sysstat的历史归档# Ubuntu/Debian 系统启用历史记录CentOS/RHEL 类似 sudo apt install sysstat -y sudo systemctl enable sysstat sudo sed -i s/ENABLEDfalse/ENABLEDtrue/ /etc/default/sysstat sudo systemctl restart sysstat提示sysstat默认每 10 分钟采一次但巡检报告常需更细粒度如每分钟。修改/etc/cron.d/sysstat中的*/10为* * * * *即可但注意磁盘 IO 和存储成本——我们通常只对关键节点DB、网关调高频率。采集完成后数据存在/var/log/sysstat/下按日期压缩。生成报告时我们不现场跑sar而是用sadfsysstat data formatter直接读取归档避免干扰生产负载# 提取昨日全天 CPU 使用率用户态/系统态/空闲的每分钟平均值输出 CSV sadf -d /var/log/sysstat/sa$(date -d yesterday %d) -- -u | \ awk -F; {if(NF6) print $1,$2,$3,$4,$5,$6} cpu_yesterday.csv # 提取磁盘 I/O 关键指标tps每秒传输数、rkB/s读 KB/s、wkB/s写 KB/s、awaitI/O 平均等待毫秒 sadf -d /var/log/sysstat/sa$(date -d yesterday %d) -- -d | \ awk -F; $5 ~ /sda|nvme0n1/ NF10 {print $1,$2,$5,$6,$7,$8,$9} io_yesterday.csv逻辑说明sadf -d指定归档路径-- -u表示 CPU 指标-- -d表示磁盘。awk过滤掉标题行NF!6和非主盘设备只保留 sda 或 nvme0n1确保数据干净。这些 CSV 将作为后续 PDF 报告中的图表数据源。2.2 用 ps lsof ss 快照“此刻”的进程与连接真相sar给的是趋势但“此刻谁在吃内存”、“哪个进程占了 8000 文件描述符”、“有没有 ESTABLISHED 连接卡在 FIN_WAIT2 超过 5 分钟”必须靠快照。这里的关键是加时间戳、去干扰、控精度# 1. 内存大户快照按 RSS 排序只取前 10过滤掉 kernel threadsCMD 列含 [ ] 的 ps -eo pid,ppid,user,%mem,%cpu,rss,vsz,cmd --sort-rss | \ awk NR1 || $9 !~ /^\[/ {print $0} | head -n 11 mem_top10.txt # 2. 文件描述符滥用者找出打开文件数 1000 的进程并关联其打开的文件类型分布 lsof -n -P | awk {print $2} | sort | uniq -c | sort -nr | head -20 | \ awk $1 1000 {print $2} | while read pid; do echo PID $pid: $(lsof -p $pid 2/dev/null | awk {print $5} | sort | uniq -c | sort -nr | head -3 | tr \n ) done fd_leak_hint.txt # 3. 异常网络连接筛选 ESTABLISHED 但 recv-q 长期 0可能应用未读数据或 TIME_WAIT 超 60 秒 ss -tn state established | awk $2 0 {print $0} net_estab_recvq.txt ss -tn state time-wait | awk $4 60 {print $0} net_timewait_old.txt参数说明ps -eo输出所有字段--sort-rss按物理内存倒序lsof -n -P禁用 DNS 解析和端口名转换提速防阻塞ss -tn用 TCP 数字格式比netstat更轻量。这些命令执行时间控制在 2 秒内不会拖慢巡检流程。2.3 用 slabtop sysctl 捕捉内核级隐性瓶颈很多性能抖动源于内核子系统比如 dentry/inode 缓存膨胀、TCP socket 内存耗尽、或 nf_conntrack 表满。这些在free或top里完全不可见但slabtop和sysctl能挖出来# 1. slabtop 实时快照-o 离线模式-n1 只取一次聚焦 top5 占用者 slabtop -o -n1 | head -20 | grep -E (^Active|^dentry|^inode|^size-) slab_top5.txt # 2. 关键内核参数检查conntrack 表使用率、TCP 内存分配上限、vm.swappiness echo nf_conntrack_count: $(cat /proc/sys/net/netfilter/nf_conntrack_count 2/dev/null) kernel_params.txt echo nf_conntrack_max: $(cat /proc/sys/net/netfilter/nf_conntrack_max 2/dev/null) kernel_params.txt echo net.ipv4.tcp_mem: $(sysctl -n net.ipv4.tcp_mem 2/dev/null) kernel_params.txt echo vm.swappiness: $(sysctl -n vm.swappiness 2/dev/null) kernel_params.txt逻辑说明slabtop -o避免交互式刷新head -20截取关键行/proc/sys/直读比sysctl -a快 10 倍且只查我们关心的 4 个参数。例如若nf_conntrack_count / nf_conntrack_max 0.8就预示连接跟踪表即将打满新连接会被丢弃——这正是“偶发连接超时”的元凶。3. 把原始数据喂给 Python用 WeasyPrint 生成专业 PDF 报告有了 CSV、TXT 等原始数据下一步是组装成 PDF。很多人用wkhtmltopdf但它依赖外部二进制、渲染不稳定、中文支持差。我坚持用WeasyPrint纯 Python 实现、CSS 控制力强、PDF 标准兼容好且能直接嵌入 Matplotlib 图表。整个流程分三步数据清洗 → HTML 模板渲染 → PDF 导出。3.1 用 pandas 清洗并聚合多源数据生成结构化 DataFrame先安装依赖建议用虚拟环境pip install weasyprint matplotlib pandas jinja2 # Ubuntu/Debian 需额外安装字体支持 sudo apt install fonts-liberation fonts-noto-cjk核心清洗脚本data_loader.pyimport pandas as pd import numpy as np from datetime import datetime, timedelta def load_cpu_data(): # 读取昨日 CPU CSV列名timestamp,hostname,cpu,user,system,idle df pd.read_csv(cpu_yesterday.csv, names[ts, host, cpu, user, system, idle]) df[ts] pd.to_datetime(df[ts]) # 计算每小时峰值非平均值巡检要看压力极值 df_hourly df.set_index(ts).resample(H)[user,system].max().reset_index() return df_hourly def load_io_data(): # 读取磁盘 I/O CSVts,host,device,tps,rkB/s,wkB/s,await df pd.read_csv(io_yesterday.csv, names[ts, host, dev, tps, rkbs, wkbs, await]) df[ts] pd.to_datetime(df[ts]) # 只取主盘计算 await 超阈值20ms的时段 main_disk df[df[dev].str.contains(sda|nvme0n1)].copy() main_disk[is_slow] main_disk[await] 20 return main_disk def load_mem_top(): # 解析 mem_top10.txtpid,ppid,user,%mem,%cpu,rss,vsz,cmd with open(mem_top10.txt) as f: lines f.readlines() # 跳过表头解析字段注意 cmd 可能含空格取最后 1 列 data [] for line in lines[1:]: parts line.strip().split() if len(parts) 8: continue data.append({ pid: parts[0], user: parts[2], mem%: float(parts[3]), cpu%: float(parts[4]), rss_mb: int(parts[5]) // 1024, cmd: .join(parts[7:]) }) return pd.DataFrame(data) # 主函数返回所有清洗后数据 if __name__ __main__: cpu_df load_cpu_data() io_df load_io_data() mem_df load_mem_top() print(✅ 数据加载完成CPU 小时峰值, len(cpu_df), 条IO 采样, len(io_df), 条内存 TOP10, len(mem_df), 条)逻辑说明pandas处理 CSV 比 shellawk更可靠尤其当字段含空格时resample(H).max()抓取每小时 CPU 用户态最大值这才是业务高峰期的真实压力is_slow标记让后续 HTML 模板能高亮异常时段。3.2 用 Jinja2 模板定义 PDF 结构CSS 控制打印样式创建report_template.html关键部分如下省略完整 HTML 结构!DOCTYPE html html head meta charsetutf-8 style page { size: A4; margin: 1.5cm; } body { font-family: Liberation Sans, Noto Sans CJK SC, sans-serif; font-size: 12px; } .section { break-inside: avoid; margin-top: 24px; } .chart { width: 100%; height: 250px; margin: 10px 0; } .table { width: 100%; border-collapse: collapse; margin: 10px 0; } .table th, .table td { border: 1px solid #999; padding: 4px 6px; text-align: left; } .alert { background-color: #fff3cd; border-left: 4px solid #ffc107; padding: 8px; } .critical { background-color: #f8d7da; border-left: 4px solid #dc3545; } /style /head body h1Linux 服务器巡检报告/h1 pstrong生成时间/strong{{ now }} nbsp; strong目标主机/strong{{ hostname }}/p div classsection h2CPU 使用率昨日每小时峰值/h2 img src{{ cpu_chart_path }} classchart altCPU 峰值图 {% if cpu_alert %}div classalert{{ cpu_alert }}/div{% endif %} /div div classsection h2内存 TOP10 进程RSS 占用/h2 table classtable trthPID/thth用户/thth内存%/ththCPU%/ththRSS(MB)/thth命令/th/tr {% for row in mem_data %} tr td{{ row.pid }}/td td{{ row.user }}/td td{{ %.1f|format(row.mem%) }}/td td{{ %.1f|format(row.cpu%) }}/td td{{ row.rss_mb }}/td td{{ row.cmd[:40] }}{% if row.cmd|length 40 %}...{% endif %}/td /tr {% endfor %} /table /div /body /html注意WeasyPrint 对 CSS 支持严格page必须声明字体必须用系统已安装的 Liberation 或 Noto 系列否则中文乱码。break-inside: avoid防止表格跨页断裂这是 PDF 报告专业性的底线。3.3 用 WeasyPrint 渲染 PDF嵌入 Matplotlib 动态图表generate_report.py主程序from weasyprint import HTML, CSS from jinja2 import Template import matplotlib.pyplot as plt import io import base64 from data_loader import load_cpu_data, load_io_data, load_mem_top def create_cpu_chart(df): plt.figure(figsize(10, 4)) plt.plot(df[ts], df[user], labelUser%, markero, markersize2) plt.plot(df[ts], df[system], labelSystem%, markers, markersize2) plt.title(CPU 使用率昨日每小时峰值) plt.xlabel(时间) plt.ylabel(%) plt.legend() plt.grid(True, alpha0.3) # 转为 base64 嵌入 HTML buf io.BytesIO() plt.savefig(buf, formatpng, dpi150, bbox_inchestight) buf.seek(0) img_base64 base64.b64encode(buf.read()).decode() plt.close() return fdata:image/png;base64,{img_base64} def main(): # 加载数据 cpu_df load_cpu_data() io_df load_io_data() mem_df load_mem_top() # 生成图表 cpu_chart create_cpu_chart(cpu_df) # 生成告警文本 cpu_alert if cpu_df[user].max() 90: cpu_alert ⚠️ CPU 用户态峰值超 90%请检查是否有定时任务或批处理作业集中触发 # 渲染 HTML with open(report_template.html) as f: template Template(f.read()) html_content template.render( nowdatetime.now().strftime(%Y-%m-%d %H:%M:%S), hostnameprod-web-01, cpu_chart_pathcpu_chart, cpu_alertcpu_alert, mem_datamem_df.to_dict(records) ) # 导出 PDF HTML(stringhtml_content).write_pdf( Linux_服务器巡检报告.pdf, stylesheets[CSS(stringpage { size: A4; margin: 1.5cm; })] ) print(✅ PDF 报告已生成Linux_服务器巡检报告.pdf) if __name__ __main__: main()逻辑说明base64嵌入图片是 WeasyPrint 最稳方案避免路径引用失败bbox_inchestight防止图表标签被裁切dpi150保证打印清晰度。最终 PDF 文件大小约 1.2MB含图表远小于截图拼接方案。4. 巡检报告 PDF 的 5 个致命避坑点新手必踩老手也翻车生成 PDF 很容易但一份能真正指导运维决策的报告90% 的失败都发生在数据采集和呈现环节。以下是我在多个项目中血泪总结的 5 个高频翻车点每个都附带真实现象、根因和可立即执行的修复命令。4.1 现象PDF 中文全是方块或乱码原因WeasyPrint 默认不嵌入中文字体且系统未安装支持 CJK 的开源字体如 Noto Sans CJK。即使 HTML 中写了font-family: Noto Sans CJK SC若系统无该字体会 fallback 到无中文的 Liberation Sans导致空白。解决# Ubuntu/Debian 安装 Noto 字体覆盖简体中文 sudo apt install fonts-noto-cjk fonts-noto-cjk-extra -y # 验证是否生效 fc-list | grep -i noto.*cjk # 若无输出手动下载并安装临时方案 wget https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKsc-hinted.zip unzip NotoSansCJKsc-hinted.zip -d /usr/share/fonts/truetype/noto/ sudo fc-cache -fv4.2 现象sar 数据显示“无数据”或时间戳错乱原因sysstat归档文件名是saDDDD 为日期但date -d yesterday %d在每月 1 号运行时会返回01而归档文件实际是sa01但若系统时区为 UTC 而本地为 CSTdate命令可能取错日期。解决统一用date -d $(date -d yesterday %Y%m%d)获取昨日日期字符串并校验文件存在YESTERDAY$(date -d $(date -d yesterday %Y%m%d) -1 day %d) SA_FILE/var/log/sysstat/sa${YESTERDAY} if [ ! -f $SA_FILE ]; then echo ❌ 归档文件不存在$SA_FILE尝试 sa$(date -d 2 days ago %d) YESTERDAY$(date -d 2 days ago %d) fi4.3 现象内存 TOP10 进程列表为空或只有 2 行原因ps命令在容器化环境中如 Docker可能因 PID namespace 隔离无法看到宿主机全部进程或ps权限不足非 root 用户执行时ps -eo会过滤掉其他用户进程。解决明确指定运行权限并在容器场景改用docker stats# 检查是否在容器内 if [ -f /proc/1/cgroup ] grep -q docker\|kubepods /proc/1/cgroup; then echo ⚠️ 检测到容器环境改用 docker stats docker stats --no-stream --format {{.Name}},{{.CPUPerc}},{{.MemUsage}} | head -11 mem_top10_container.txt else # 宿主机执行原 ps 命令 ps -eo ... mem_top10.txt fi4.4 现象磁盘 I/O 图表中 tps 曲线异常平坦await 却很高原因sadf -- -d输出的await是毫秒级但某些旧版 sysstat12.0存在 bug将await错误地当作微秒输出导致数值虚高 1000 倍如显示 50000 实际是 50ms。解决用iostat -x 1 1现场验证若await值相差 1000 倍则对sadf输出做修正# 修正 await若原始值 1000则除以 1000兼容新旧版本 awk -F; $9 1000 { $9 $9 / 1000 } {print $0} io_yesterday.csv io_fixed.csv4.5 现象PDF 生成后体积超 50MB打开卡死原因Matplotlib 默认保存 PNG 为 300dpi且未压缩若图表含大量数据点如 24 小时每分钟采样PNG 会爆炸式增长。解决降低 DPI 并启用 PNG 压缩# 替换 plt.savefig(...) 行为 plt.savefig(buf, formatpng, dpi120, bbox_inchestight, facecolorwhite, edgecolornone, pad_inches0.1) # 或更激进用 PIL 压缩 from PIL import Image img Image.open(buf) img.save(buf, formatPNG, optimizeTrue, quality85)5. 让巡检报告真正驱动运维自动化、基线比对与根因提示一份静态 PDF 的价值有限真正的威力在于让它成为运维决策的“活”输入。我坚持三个动作每日自动推送、跨周期基线比对、关键指标根因提示。不做这些报告就是电子废纸。5.1 用 systemd timer 替代 crontab实现静默自动化crontab无法管理依赖、日志和错误重试而systemd可以。创建server-check.service[Unit] DescriptionLinux Server Health Check Afternetwork.target [Service] Typeoneshot Userops WorkingDirectory/opt/server-check ExecStart/usr/bin/python3 /opt/server-check/generate_report.py StandardOutputjournal StandardErrorjournal Restarton-failure RestartSec30 [Install] WantedBymulti-user.target再创建server-check.timer[Unit] DescriptionRun server check daily at 02:30 Requiresserver-check.service [Timer] OnCalendar*-*-* 02:30:00 Persistenttrue [Install] WantedBytimers.target启用并验证sudo systemctl daemon-reload sudo systemctl enable server-check.timer sudo systemctl start server-check.timer sudo systemctl list-timers --all | grep server提示Persistenttrue确保机器宕机后下次启动立即补跑StandardOutputjournal让所有日志进journalctl -u server-check.service比 crontab 的邮件日志更可控。5.2 基线比对用 pandas 计算“同比上周”与“环比昨日”巡检不是看绝对值而是看变化。在data_loader.py中加入比对逻辑def load_cpu_baseline(): # 加载上周同一天数据如今天是周三则取上周三 last_week (datetime.now() - timedelta(days7)).strftime(%d) df_last pd.read_csv(f/var/log/sysstat/sa{last_week}, ...) # 同前 return df_last def generate_comparison(cpu_today, cpu_lastweek): # 计算各小时用户态 CPU 的同比变化率 merged pd.merge(cpu_today, cpu_lastweek, onts, suffixes(_today, _lastweek)) merged[delta_user] merged[user_today] - merged[user_lastweek] # 标记变化超 20% 的小时段 merged[is_spike] abs(merged[delta_user]) 20 return merged[merged[is_spike]].sort_values(delta_user, keyabs, ascendingFalse) # 在 main() 中调用 spikes generate_comparison(cpu_df, load_cpu_baseline()) if not spikes.empty: print( 发现 CPU 同比突增时段, spikes[[ts, delta_user]].values)这样报告中可增加一栏“昨日 vs 上周同日 CPU 峰值变化”并高亮delta_user 20的时段——这往往指向配置变更、流量迁移或上游依赖抖动。5.3 根因提示引擎用规则匹配原始数据自动生成行动建议最后一步让报告不止于“展示”而给出“怎么做”。我维护一个轻量规则库root_cause_rules.pyRULES [ { name: dentry 缓存过高, condition: lambda data: data.get(slab_dentry, 0) 2 * 1024**3, # 2GB action: 执行 echo 2 /proc/sys/vm/vfs_cache_pressure缓解 dentry 压力 }, { name: TIME_WAIT 连接堆积, condition: lambda data: len(data.get(net_timewait_old, [])) 500, action: 检查 net.ipv4.tcp_tw_reuse 是否启用或调整 net.ipv4.ip_local_port_range }, { name: 日志文件暴增, condition: lambda data: data.get(log_growth_gb, 0) 5, action: 检查 /var/log 下大日志文件执行 logrotate -f /etc/logrotate.d/nginx } ] def run_root_cause_analysis(raw_data): alerts [] for rule in RULES: if rule[condition](raw_data): alerts.append(f {rule[name]}{rule[action]}) return alerts # 在 generate_report.py 中调用 raw_data { slab_dentry: get_slab_value(dentry), # 从 slab_top5.txt 解析 net_timewait_old: open(net_timewait_old.txt).readlines(), log_growth_gb: calculate_log_growth() } root_causes run_root_cause_analysis(raw_data)这些提示直接注入 PDF 的“运维建议”章节让新人也能快速响应。我坚持这个习惯每次生成报告后花 90 秒扫一眼“根因提示”和“同比突增”栏。三年下来83% 的线上抖动都在报告生成后 10 分钟内定位到源头——不是靠经验而是靠把经验固化成规则。这份Linux服务器巡检报告.pdf从来不是终点而是你和服务器之间最冷静、最诚实的对话起点。希望帮到你。本文还有配套的精品资源点击获取