性能观测工具链

• perf bench 支持的子系统（mem、sched、futex、epoll、syscall 等）
• 基准的运行方式与结果解读
• 基准测试在版本对比与调优验证中的适用场景

perf bench 是 perf 工具集内置的微观基准测试工具，用于对内核各子系统进行标准化压测，支持的子系统包括 mem（内存拷贝、分配）、sched（调度器）、futex（快速用户态互斥锁）、epoll（事件轮询）、syscall（系统调用）、ringbuffer 等。常用用法如 perf bench mem memcpy 测试内存拷贝带宽、perf bench sched pipe 测试进程间管道调度切换开销、perf bench futex hash 测试锁竞争吞吐，perf bench list 可列出全部可用基准及其参数。

它的价值在于"可复现、可对比"：通过固定场景、固定次数重复测量输出吞吐量或单次操作耗时，适合在硬件升级、内核版本变更、内核参数调优前后做横向对比，量化验证优化效果。但注意 perf bench 是微观基准，测的是内核原语在隔离条件下的表现，不能替代应用层压测（如 wrk、sysbench），真实业务收益还需结合端到端测试确认。

本题考察对内核级基准测试工具的体系化认知。回答要点是"子系统清单 + 运行方式 + 结果解读 + 适用边界"四层：先列举支持的子系统，再说明如何运行与读取输出，最后强调其适用场景是版本/配置对比而非整体性能评估，体现对工具定位的准确理解。

• perf sched record/report/latency 的完整使用流程
• 调度延迟（sched latency）与唤醒事件的解读
• 适用场景：调度类延迟问题与 CPU 争用分析

perf sched 是 perf 针对调度器事件的分析工具，典型流程是 perf sched record 采集一段时间内的调度事件（sched_switch、sched_wakeup、sched_wakeup_new 等），然后通过 perf sched latency 或 perf sched report 分析。latency 输出会按任务汇总等待与运行情况，关键字段包括平均/最大调度延迟（avg/max delay）、任务被唤醒后到真正上 CPU 运行的时间差，以及任务总运行时间，帮助定位"被唤醒但迟迟没跑起来"的延迟型问题。

perf sched 的典型应用场景包括：排查高延迟业务背后的 CPU 调度抖动、分析多线程任务在核间迁移（migration）带来的 cache 失效、判断某个任务是否被更高优先级任务或中断持续抢占。与 strace 的"系统调用视角"、火焰图的"热点函数视角"不同，perf sched 提供的是"调度器时间线视角"，三者在延迟类排障中互补使用。

本题考察对调度事件分析工具链的掌握。核心是"采集-分析"两步：record 抓事件、latency/report 看延迟统计；回答应明确调度延迟的含义（唤醒到运行的时间差）与典型适用场景，并点明它与函数级剖析工具的分工，体现对工具定位的区分能力。

• bpftrace 基于 eBPF 的探针式观测原理
• 实时排障典型场景：文件、网络、内存、exec 等
• 内核版本与权限（root/CAP_BPF）前提

bpftrace 是基于 eBPF 的动态追踪工具，用类似 awk 的脚本语言在 kprobe、uprobe、tracepoint、kfunc 等探针上运行小型程序，实现毫秒级部署的实时观测。典型单行脚本用例包括：统计进程系统调用次数（bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'）、追踪文件打开路径、观测新进程 exec（bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf(...); }'）、统计 TCP 连接与重传、查看 OOM 触发时进程内存等，几乎覆盖"谁在干什么"的实时追问。

使用前提：内核需开启 BPF（CONFIG_BPF、CONFIG_BPF_EVENTS），一般需要 root 或具备 CAP_BPF/CAP_SYS_ADMIN 权限；生产环境还应评估探针开销——高频探针在大流量下会放大采样成本，通常用于短时定点排障而非长期监控。与 perf 相比，bpftrace 更偏"自定义即时问答"，perf 更偏"标准化采集分析"。

本题考察对 eBPF 动态追踪工具实用面的理解。回答应包含"原理（探针 + 内核态程序）+ 典型用例（系统调用、文件、网络、进程）+ 前提条件（内核特性、权限、开销控制）"三个层次，能体现排障实战经验。

• await/r_await/w_await 的服务时间+队列等待时间含义
• svctm、util、aqu-sz 与磁盘吞吐的关联
• 机械盘与 SSD 的指标差异与解读基准

iostat -x 的关键指标：await 是 IO 请求从进入队列到完成的总平均时间（含排队等待与服务时间），r_await/w_await 分别为读/写请求的平均等待时间；svctm 是平均每次 IO 的服务时间（近似值，新内核已弱化其参考价值）；util 表示设备忙碌时间占比（接近 100% 未必就是瓶颈，NVMe 等多队列设备即使 util 高也可能仍有富余带宽）；aqu-sz 为平均队列长度。判断思路：await 明显大于 svctm，说明 IO 在排队，瓶颈在磁盘吞吐能力；await 与 svctm 接近则说明请求基本立等可取，瓶颈可能在并发度或应用层。

解读时要注意存储介质差异：机械盘单次寻道服务时间在毫秒级（如 8-12ms），await 几十毫秒常见；SSD 服务时间在百微秒级，await 超过 10ms 即异常。还应结合 r/s、w/s、rkB/s 等吞吐指标判断是"量大导致的排队"还是"个别慢盘/慢路径导致的延迟"，必要时用 iostat -x -t 或 pidstat -d 定位到具体进程。

本题考察对磁盘性能指标体系的理解。关键是区分"排队等待时间"与"服务时间"：await 大而 svctm 小说明排队，两者接近说明服务本身慢；再结合介质基准（机械盘 vs SSD）给出合理阈值判断，避免只报指标不解释根因。

• offcpu 时间的概念与阻塞原因分类（IO、锁、调度）
• perf sched 与 BCC offcputime/offcputime-bpfcc 的用法区别
• 火焰图（offcpu 火焰图）的解读

offcpu 分析关注进程处于不可运行状态（睡眠、阻塞、等待）的时间，即"本可运行却没在跑"的损耗，用于定位延迟不是由 CPU 计算引起、而是由等待 IO、锁竞争、网络、睡眠等引起的问题。工具链包括 perf 与 BCC：perf sched record 可记录调度事件并查看 offcpu 分布；BCC 的 offcputime-bpfcc（原 offcputime）通过 eBPF 追踪调度器切换事件，直接按进程输出 offcpu 时间排行，并可用 -f 生成 offcpu 火焰图，展示"进程阻塞在什么调用路径上"。

两者区别：perf 的方案基于事后事件记录分析，采样的是调度器时间线；BCC offcputime 是实时聚合器，输出更直接（哪个进程、哪个内核/用户栈、累计阻塞多久），适合快速定位"谁在睡觉"。典型场景：应用延迟突增但 CPU 利用率不高时，先用 offcputime 找出阻塞热点进程，再结合其调用栈（如等锁、等 IO、等网络）进一步定位。内核版本较老时 BCC 依赖 kprobes，注意生产环境探针开销与内核符号表完整性。

本题考察对阻塞型性能问题的分析方法。回答关键是区分"CPU 型"与"offcpu 型"延迟问题，说明 offcputime 类工具的价值在直接量化"等待时间"，并掌握 perf 与 BCC 两套实现及火焰图产出，体现延迟排障的完整方法论。

• perf record 采样参数（-F 频率、-g 调用栈、-p 进程）与 perf report 查看
• FlameGraph 脚本生成火焰图（stackcollapse-perf.pl + flamegraph.pl）的流程
• 火焰图解读：宽度代表占比、栈顶热点、采样误差

生成火焰图的标准流程：先用 perf record -F 99 -g -p <pid> -- sleep 30 以 99Hz 周期采样并记录调用栈（-g 开启栈回溯，现代内核推荐 --call-graph dwarf 或 fp），再用 perf report 交互查看，或用 FlameGraph 工具链的 stackcollapse-perf.pl 把 perf.data 折叠成栈格式、flamegraph.pl 渲染出 SVG 火焰图。火焰图 x 轴是采样占比（宽度越大占比越高，与时间无关），y 轴是调用栈深度，栈顶是采样时正在执行的函数。

解读要点：看栈顶宽块找热点函数，从下往上看完整调用路径；"平顶"（宽而浅）说明热点直接来自某个函数，可能值得优化或深挖（如自旋锁、频繁 syscall）；结合 -F 采样频率估算误差——99Hz 采样在低频短程事件上可能失真，火焰图反映的是"采样时刻在跑什么"的概率分布。常见陷阱：没有正确开启栈回溯导致火焰图缺失层级、未排除采样自身的干扰（perf 进程自身）、优化级别影响函数符号（需 debuginfo 或 --call-graph 配置）、短时间采样代表性不足。

本题考察 CPU 型性能剖析的标准工作流。回答按"采集-折叠-渲染-解读"四步展开，强调 x 轴占比而非时间的语义，并指出栈回溯方式、采样频率与符号解析等影响火焰图质量的实操细节，体现真实排障能力。

• 采样模式：周期性采样（-F、--period）与 profiling 的统计性质
• 跟踪模式：perf trace、perf stat 与事件级记录的区别
• 两种模式在开销、数据量与适用场景上的取舍

采样模式通过硬件性能计数器或定时器周期性中断，记录"此刻正在执行什么"，得到的是事件分布的概率样本，典型如 perf record -F 99 的 CPU profiling，开销低、数据量可控、统计上能反映热点占比，适合长时间剖析找热点，但低频事件可能被低估。跟踪模式记录每个事件的完整现场（时间戳、pid、栈），如 perf trace 对系统调用的逐个记录、perf stat 对计数器进行精确累加汇总，数据完整但开销大、数据量随事件频率线性增长，适合短时间精确观测特定事件序列。

选择原则：找"统计热点"用采样（如火焰图剖析）；数"精确次数/延迟"用 perf stat（计数累加，如 cache miss 总数、上下文切换总数）；看"事件执行顺序与参数"用跟踪（如 perf trace 查看某进程的 syscall 序列）。生产环境通常先用采样快速圈定方向，再用跟踪或 bpftrace 定点深挖，控制数据量与开销。

本题考察对 profiling 两种范式的本质区分。回答应抓住"概率统计 vs 全量记录"这个核心差异，并落到工具对应关系（record=采样、stat=trace=跟踪计数）与开销/数据量权衡上，展示对 perf 工具族整体架构的理解。

• sar -W 的 pswpin/s 与 pswpout/s 字段含义
• 换页与换出对性能的影响
• 与 vmstat si/so、free 的结合判断

sar -W 显示系统换页统计，核心字段 pswpin/s（每秒从交换区换入内存的页面数）与 pswpout/s（每秒换出到交换区的页面数），取值来源是内核的 pswpin/pswpout 计数器。持续非零且数值较大说明内存在频繁换入换出，进程内存超配导致，通常伴随 CPU 高、响应慢、IO 压力增大。与 vmstat 的 si/so 字段对应，free -h 的 available 持续接近 0 时，换页会显著放大延迟。

判断方法：短时少量换页（如启动瞬间）可接受；持续 si/so 大于数百页每秒即需处理。常见处置：先看内存大头（top 按 RES、ps aux --sort=-rss），排查泄漏或超配，再决定扩容、调 vm.swappiness、回收缓存或限制容器 cgroup 内存；若 swap 盘在机械盘上，换页对性能伤害极大，应优先避免。注意区分"换页"与"page cache 回收"：sar -W 只看 swap 进出，page cache 回收属于正常内存回收。

本题考察内存换页指标的读取与联动分析。回答关键是讲清 pswpin/pswpout 的含义与异常判据（持续非零）、与 vmstat/free 的对照关系，并给出处置路径，避免把缓存回收误判为换页。

• strace -p 的附着用法与 -f 多线程跟踪
• 附着权限（ptrace_scope、CAP_SYS_PTRACE）与对目标进程的性能影响
• 典型场景：卡死、慢调用、文件缺失定位

strace -p 可附着到已运行进程，实时输出其系统调用；多线程进程需加 -f（含线程组内子进程）；-e trace= 过滤调用类型（如 file、network、signal），-tt 加微秒时间戳、-T 显示每次调用的耗时，-o file 落盘避免输出干扰。典型排障：进程"卡住"时看最后一个未返回的 syscall（如阻塞 read、futex 等待）；应用慢时用 -T 找耗时长的调用；启动失败但无日志时抓 execve/openat 定位缺失文件或依赖。采集完成用 Ctrl-C 结束，进程本身不受影响。

注意事项：附着需要与目标进程同用户或有 CAP_SYS_PTRACE 权限，且受 kernel.yama.ptrace_scope 限制（默认 1 时仅允许同进程组附着）；strace 通过 ptrace 拦截每个 syscall，会显著降低目标进程吞吐（可达数倍），生产环境应短时使用、低频进程优先，或用 perf trace 降低开销；对已多线程进程附着时新线程也会被跟踪。长时间跟踪应配合日志与监控确认无副作用。

本题考察动态调试工具的实战使用。回答要点是"附着方式（-p/-f/-e/-T）+ 权限前提（ptrace_scope/CAP）+ 开销风险 + 典型定位场景"，既讲命令也讲边界，体现对生产环境安全操作的意识。

• vmstat 关键字段：r（可运行队列）、b（阻塞）、si/so、us/sy/wa
• top 的 CPU 分解（us/sy/wa/st）与内存（RES、swap）字段
• 跨工具关联分析：CPU 型、IO 型、内存型问题的判别路径

联合解读的核心是"交叉验证、按形态分类"。vmstat 的 r 表示可运行队列长度（含正在运行的线程），长期大于 CPU 核数说明 CPU 超载；b 表示不可中断睡眠（多因磁盘 IO 等待）；si/so 表示换入换出。top 的 CPU 行把时间分解为 us（用户）、sy（内核）、wa（IO 等待）、st（被虚拟化偷走）、id（空闲）。iostat -x 提供设备级吞吐与延迟佐证。典型形态：r 大、us 高 → CPU 计算密集；wa 高、b 大、iostat await 大 → IO 瓶颈；si/so 持续非零、free available 低 → 内存换页瓶颈；st 高且 wa 异常 → 检查宿主机超卖。

分析时不要只看单工具单字段：如"load average 高但 CPU 空闲"往往是 D 态（不可中断睡眠）堆积导致；"wa 高但磁盘 util 低"可能是设备排队或慢路径；top 的 1/5/15 分钟 load 趋势可区分瞬时尖峰与持续恶化。最终结合进程级工具（pidstat、top 内按 CPU/RES 排序）落到具体进程，形成"系统层定位-进程层确认-根因处置"的链路。

本题考察性能问题"形态判别"能力。回答应给出"r/wa/si-so/st"四类典型形态与对应瓶颈的映射，并强调多工具交叉验证与进程级下钻的方法论，这是性能排障区别于单指标监控的关键。

• OS 层与应用层观测各自的能力边界
• 时间轴对齐与指标交叉验证的方法
• 典型链路：GC 频繁、线程阻塞、CPU 飙高之间的因果判定

OS 层观测（top/vmstat/perf/iostat）回答"系统资源如何使用"，应用层观测（JVM GC 日志、线程 dump、APM 的调用链与响应时间）回答"应用为什么慢"。组合定位的关键是"时间对齐"：把两端数据对齐到同一时间窗（GC 日志时间戳、APM trace 时间、OS 监控曲线），先找异常窗口，再双向求证。例如 CPU 飙高且 GC 频繁：看 GC 日志确认是否 Full GC 风暴，用 jstat/jstack 找 GC 线程与分配热点，用 perf 确认是 JIT 编译、GC 线程还是业务线程在烧 CPU；又如响应慢但系统空闲：说明是锁等待或下游依赖慢，OS 层无能为力，需线程 dump 与 APM 调用链定位。

方法论上先看"资源型"还是"等待型"：资源型问题 OS 层必有表征（CPU/IO/内存指标异常），等待型问题 OS 层往往安静，需应用层证据。常用组合手段：jstack 多线程 dump 看锁与 BLOCKED 状态、配合 top -H 看线程 CPU 消耗的 tid 对照；GC 日志与 iostat 对照判断是磁盘慢导致还是 GC 自身导致；APM 的 P99 分层耗时（网络/服务/DB）与 OS 指标相互印证。最终结论必须能在两层数据上同时自洽，避免单层误判。

本题考察跨层性能诊断的综合能力。回答强调"时间对齐 + 资源型/等待型二分 + 双向证据链"三点，并用 GC、线程、CPU 的具体组合案例展示落地方法，体现端到端排障的工程化思维。

• 周期采样（-F 定时/计数器溢出）的统计性质与误差来源
• 上下文切换采样（sched_switch）的应用场景
• 采样频率与开销、准确性的权衡

perf record 默认通过 perf event 周期性采样：要么定时器中断（如 -F 99 即每秒 99 次），要么硬件计数器溢出触发（如 -c 100000 每 10 万次指令采样一次）。其本质是"以样本推断分布"：样本落在哪个栈，就认为该函数占对应比例。准确性受采样频率与事件形态影响——热点函数是长周期、高频执行的代码时误差小；短而低频的代码容易被漏采。采样频率越高样本越准，但中断处理与写盘开销越大（perf 自身开销与数据量线性增长）。

上下文切换采样（--switch-events 或 sched_switch 事件）记录每次任务切换的上下文，可生成"进程切换视图"，用于分析 CPU 在任务间的分配与抢占，但样本粒度粗，不适合函数级热点。工程实践：先用低频率（如 49/99Hz）快速看轮廓，热点稳定后再按需提高频率定点细化；生产环境长时间采集优先低频率 + 数据压缩，短时定向诊断可提高频率；配合 --call-graph dwarf 获得完整栈但开销更大。理解采样原理有助于判断火焰图结论的可信度，避免把采样噪声当热点。

本题考察对采样统计原理的理解。回答抓住"概率样本推断分布"的本质，分析频率-准确性-开销三角关系，并区分周期采样与上下文切换采样的不同用途，体现对工具机理而非命令表面的掌握。

• sar 历史数据（sysstat 定时采集）的回放定位作用
• perf 事件记录的事后分析能力
• 实时 top 的即时快照与三者的配合流程

三类工具对应排障的三个阶段：实时 top 回答"现在怎样"，sar 回答"之前怎样"，perf 记录回答"当时为什么"。top 提供即时快照（CPU/内存/负载/进程排序），适合现场初判；sysstat 通过 cron 默认每 10 分钟落盘历史数据（/var/log/sa/saXX），可回放事发时间窗口的 CPU、内存、IO、网络趋势，用于追溯"什么时候开始恶化、是否与发布/变更重合"；perf record 需在事发时或事中采集，事后可反复回放分析调用栈、事件序列，回答"哪个函数/哪个路径导致"。

配合流程：收到告警先看实时 top 与 sar 最近时间窗定位异常指标与时间点；若需要函数级证据且系统仍在异常，启动 perf record/bpftrace 采集；事后用 sar -f 与 perf report/script 交叉复盘。注意 sar 默认保留周期（sadc 参数 HIST 与目录清理策略）决定可回溯深度，生产环境应配置足够的保留天数与指标密度（如 1 分钟粒度），并确认 sysstat 服务正常，否则"历史回放"缺失会丧失关键取证能力。

本题考察监控工具链的分工设计。回答用"现在/之前/为什么"三层定位三类工具的角色，并落到 sar 数据保留配置这一生产细节，体现对"事前-事中-事后"完整排障闭环的理解。

• 静态阈值（如 CPU>90%）简单但缺乏场景适应性
• 动态基线（分位数、周期性、AI/统计方法）的适应性与误报控制
• 分层告警与动作化设计（信息/警告/触发工单）

静态阈值如"CPU 持续 5 分钟 >90% 告警"简单直观、易解释，但同一阈值对不同业务形态失效：批处理集群高峰期 95% 是常态，数据库主库 70% 即可能危险，误报（常态高峰误警）与漏报（低于阈值但已退化）并存。动态基线告警基于历史数据建模（周/日周期性分解 + 分位数 + 指数平滑或统计检验，如 Prometheus 的 predict_linear、机器学习异常检测），能自适应业务曲线，识别"相对历史显著偏离"的变化，但引入模型误判、冷启动无基线、对突发新形态响应滞后等问题。

权衡设计：核心是"分层 + 组合"。第一层用粗静态阈值兜底（防模型失效）；第二层用动态基线捕捉异常变化；第三层对告警做抑制与聚合（持续时长、重复合并、维护窗口）。误报与漏报不可兼得，需用告警阈值/时长/级别调节灵敏度，并配合"告警动作化"（信息级通知、警告级建单、严重级自动止损）控制告警疲劳。落地时要为每条告警定义明确触发语义，避免"阈值拍脑袋"。

本题考察告警工程的权衡思维。回答关键是承认静态与动态各有优劣：静态简单可靠但僵化，动态自适应但复杂，结论落在"分层组合 + 灵敏度调节 + 动作化"的工程实践上，体现 SRE 对告警质量（而非数量）的追求。

• 性能基线的数据基础：历史时序的采集与窗口划分
• 分位数基线（P50/P95/P99）与季节性分解（日/周周期）
• 退化识别：偏差检测与告警触发

性能基线是用历史正常数据刻画"什么是正常"：采集至少数周以上的指标历史，按业务周期（工作日/周末、白天/夜间）切分窗口，计算每个窗口的分布特征——常用分位数（P50/P95/P99）而非均值，因为分位数对离群点鲁棒。季节性模型进一步分解时序为趋势 + 周期 + 残差（如 STL 分解、Prophet、Prometheus 的 anomaly detection），预测"此刻应当是多少"，实际值偏离预测超过设定幅度（如残差超 3σ 或超出历史 P99）即判定退化。

与静态阈值对比：静态阈值回答"是否超限"，基线方法回答"相对正常偏离多少"，能捕捉"绝对值未超限但相对历史显著退化"的问题（如 P99 从 20ms 涨到 80ms，静态 200ms 阈值不报警但用户已感知）。工程要点：基线需定期重训（业务演进会漂移）、剔除发布/变更/故障期脏数据、对短周期指标用周季节性、告警需持续时长确认避免瞬时抖动误报。基线方法在指标监控（响应时间、错误率、资源使用）上价值最高，是 SLO 驱动的可观测性体系的基石。

本题考察动态异常检测的方法论。回答要点是"数据基础（历史+窗口）→ 建模方法（分位数/季节性分解）→ 判定逻辑（偏离幅度）→ 工程细节（重训、清洗、时长确认）"，并突出其与静态阈值"相对偏离"的本质区别。

• 保留策略（Retention）与多级存储（热/温/冷）
• 降采样（Downsampling）：原始→分钟→小时聚合并行的设计与 rollup 规则
• 高基数（High Cardinality）问题与标签设计控制

时序数据规模随采集粒度与标签组合爆炸增长，设计核心是"分级存储 + 降采样 + 基数控制"。保留策略按数据价值分层：原始高精度数据保留短周期（如 Prometheus 15 天、原始 10s 粒度），中精度（1m/5m 聚合）保留数月，低精度（1h/1d 聚合）保留数年，由 TSDB 的 retention 与多级存储（如 VictoriaMetrics downsampling、InfluxDB 连续查询、Thanos 的 downsampling 配置）实现。降采样用聚合函数（avg/max/min/count）压缩数据量，历史查询走聚合数据，但代价是丢失瞬时尖峰（如 max 保留可部分缓解）与分位数精度。

高基数控制是容量治理的关键：标签/字段维度过多（如把用户 ID、Pod 名、随机 token 放进指标标签）会使序列数指数膨胀，撑爆索引与内存。设计原则：标签只保留有查询与聚合价值的维度（集群、环境、服务、实例类型），动态值放日志或单独存储；限制每个指标的标签集合并做基数审计（如 Prometheus 的 label 规则与 VictoriaMetrics 的 cardinality explorer）。此外采集端抽样（尾部采样、随机采样）可降低流量，但会引入统计偏差，需明确抽样率与聚合方式。

本题考察可观测性数据工程能力。回答应覆盖"保留分层、降采样规则、基数治理"三块，并点明降采样与基数的代价（尖峰丢失、序列膨胀），体现从数据生命周期角度管理监控成本的意识。

• pull 模型：抓取端主动、健康状态由抓取探测、服务发现（SD）驱动
• push 模型：采集端主动上报，适合短生命周期任务与 NAT 环境
• 选型依据：批处理、事件型、网络环境与运维复杂度

pull 模型（Prometheus）由监控端按配置周期性抓取目标的 /metrics，优点：健康探测天然嵌入（抓不到即判定目标异常）、指标端点可校验（谁暴露什么一目了然）、便于在抓取端统一限流与配置；缺点：目标需可被网络直达、需服务发现（kubernetes_sd、file_sd、consul_sd）维护目标列表、短生命周期任务（批处理、Serverless、Job）抓取窗口可能错过。push 模型（StatsD、Telegraf、Pushgateway）由业务端/采集代理主动上报，优点：天然覆盖短生命周期与不可直达目标（NAT、边缘）、上报节奏由业务控制；缺点：监控端难以区分"目标故障"与"上报缺失"、滥用 Pushgateway 会使其成为状态单点与数据混乱源。

选型判断：常驻服务优先 pull + 服务发现（Prometheus 主流做法）；批处理/定时任务用 Pushgateway 或推送到网关（注意清理过期序列）；边缘/NAT/采集端离监控端远的场景用 Telegraf 推送到中心存储；K8s 生态默认 pull。实践上多采用混合：核心指标 pull，短任务与边缘场景 push，并在 push 侧做幂等与 TTL 清理，保证数据语义清晰。

本题考察监控架构模型的本质差异。回答抓住"谁主动"这一核心：pull 将健康探测与抓取耦合、依赖可达性与服务发现；push 适合短生命周期与不可达场景但牺牲可观测性语义；结论落到按工作负载类型混合选型。