sar查不到DNS耗时是因为其仅采集内核公开指标，而DNS解析发生在用户空间，不属于内核跟踪范围，故无相关选项、日志字段或统计项；需用nslookup、dig、tcpdump或resolver服务统计等替代方案。
sar 本身不采集 DNS 解析耗时数据。
为什么 sar 查不到 DNS 耗时
sar 是内核级系统活动采集工具，只记录操作系统公开暴露的统计指标（如 CPU、内存、磁盘 I/O、网络接口吞吐、TCP 连接数等），而 DNS 解析发生在用户空间，由 glibc 或 systemd-resolved 等组件完成，不属于内核直接跟踪的系统资源事件。因此：
- sar 没有
-n DNS、-u dns或类似选项； -
/var/log/sysstat/saXX文件中不存在“DNS 响应时间”“解析失败次数”或“缓存命中率”字段； - 即使启用进程级采集（
ENABLE_PROCESS_STATS=true），sar 也只记录进程的 CPU/内存占用，不记录其发起的单次 DNS 查询行为。
替代方案：定位和测量 DNS 耗时
要排查历史或实时的 DNS 解析慢问题，需结合其他工具和日志：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
查应用层日志：Nginx、Apache、Java 应用、curl 脚本等若记录了请求耗时，可从中分离出 DNS 阶段（如 Nginx 的
$upstream_connect_time不含 DNS，但$request_time - $upstream_header_time可粗略估算）； -
抓包回溯：若提前启用了
tcpdump -w dns.pcap port 53或使用systemd-coredump+bpftrace记录过 DNS 流量，可用 Wireshark 打开分析响应时间； -
检查 resolver 缓存状态：运行
systemd-resolve --statistics（systemd-resolved）或rndc stats（BIND）查看历史缓存命中/超时计数——这些是服务自身维护的统计，非 sar 数据； -
复现+实测：用
time nslookup example.com或dig +stats example.com直接测当前解析延迟，再对比历史基线（如运维文档、监控图表）。
间接线索：从 sar 发现 DNS 问题的征兆
虽然不能直接看 DNS 耗时，但以下 sar 指标异常可能提示 DNS 成为瓶颈：
-
sar -n EDEV -f /var/log/sysstat/sa28显示网卡丢包率（%rxpck/s或rxerr/s）突增 → 可能因 DNS UDP 包被丢弃导致重试； -
sar -n TCP -f /var/log/sysstat/sa28中active/s（主动建连）远高于passive/s（被动接受），且伴随大量retrans/s→ 应用频繁超时重试 DNS（尤其 fallback 到 TCP 时）； -
sar -u -f /var/log/sysstat/sa28中 %user 较高，但 %iowait 和 %idle 都低 → CPU 在忙于处理大量短连接（如每秒数百次 curl + DNS 查询），而非 I/O 或空闲等待。
不复杂但容易忽略：DNS 性能问题从来不在 sar 里，而在应用日志、抓包文件和 resolver 服务自身的统计中。
