journalctl虽不直接记录cpu频率与温度数值，但能捕获内核thermal子系统、acpi-cpufreq等驱动及thermald等服务输出的过热、降频相关警告日志，是定位硬件温控问题的关键线索。
Linux 中 journalctl 本身不直接记录 CPU 频率或温度数值，但能捕获内核、电源管理子系统（如 intel_idle、acpi_cpufreq）、硬件监控驱动（如 coretemp、k10temp）以及 systemd 触发的降频/过热保护行为所输出的关键日志。这些日志通常以 warning 或 err 级别出现，带有明确关键词，是定位过热或频率异常的首要线索。
查内核层温度与频率相关警告
过热保护由内核 thermal 子系统触发，CPU 降频常由 acpi-cpufreq 或 intel_pstate 驱动执行，它们都会向 journald 写入日志：
- 运行 journalctl -k -p warning --since "2 hours ago" | grep -i "thermal\|temperature\|throttle\|freq\|cpu.*off\|hot"，重点关注含 thermal_zone、critical、trip point、throttling 的条目
- 典型日志示例："thermal thermal_zone0: critical temperature reached (95 C), shutting down" 或 "CPU0: Core temperature above threshold, throttling"
- 加 -S "10 minutes ago" 缩小到最近窗口，避免被历史噪音干扰
查 systemd 和硬件服务的异常行为
CPU 持续降频或反复过热可能引发服务响应延迟甚至单元重启，这些也会留下痕迹：
- 运行 journalctl --since "today" --unit=systemd-logind --unit=thermald --unit=power-profiles-daemon -p notice..warning，检查热管理守护进程是否异常退出或重载
- 若使用 thermald（Intel 平台常用），查其完整日志：journalctl -u thermald -n 200，看是否频繁触发 passive cooling 或 failed to read temp
- 运行 journalctl -b -p err | grep -i "acpi\|pnp\|failed.*osc\|_psl\|_psr"，排查 ACPI 表异常导致的电源策略失效
结合时间点交叉验证系统负载与事件
单看日志不够，需把“温度告警时间”和“CPU 使用突增/卡顿时间”对齐：
- 先用 journalctl --since "1 hour ago" -o short-iso | grep -E "(throttle|thermal|temperature)" 提取带 ISO 时间戳的原始行，记下关键时间点（如 2026-09-15T14:22:03）
- 再查该时刻前后 5 分钟的服务状态：journalctl --since "2026-09-15T14:17:00" --until "2026-09-15T14:27:00" -u your-app.service -p info
- 同时查内核是否在此时段报告 I/O hung_task 或 memory pressure：journalctl -k -S "2026-09-15T14:20:00" -U "2026-09-15T14:25:00" | grep -E "(hung_task|out of memory|memory cgroup)"
导出结构化日志辅助长期趋势分析
若需统计降频频次或做周期性巡检，可用 JSON 格式导出后处理：
- 导出最近 24 小时所有 thermal 相关条目：journalctl --since "24 hours ago" -o json | jq 'select(.MESSAGE and (.MESSAGE | test("thermal|throttle|temperature"; "i")))' > thermal-events.json
- 快速统计每小时触发次数：journalctl --since "7 days ago" | awk '/thermal|throttle/{print $1,$2}' | cut -d' ' -f1,2 | sort | uniq -c
- 注意：普通用户可能无权读取全部内核日志，必要时加 sudo
