Epsilon无操作收集器适合短生命周期任务压测，因其零侵入、无运行时开销，仅在启动和退出瞬间快照采集CPU、内存、线程、GC等指标，不持续采样、不干扰毫秒级任务。
在短生命周期任务（如批处理、定时脚本、Flink/Spark 临时作业）中做压测，难点不是发压本身，而是监控链路来不及建立——任务可能几秒就结束，而传统监控 Agent（如 Prometheus Exporter、JVM Agent）启动、注册、上报指标需要数百毫秒到数秒，导致关键指标丢失。
为什么 Epsilon 无操作收集器适合这类场景
Epsilon 是一种“零侵入、无运行时开销”的指标采集机制，它不依赖 JVM Agent、不 hook 方法、不启动独立线程，而是通过编译期或启动参数注入极轻量的探针，仅在任务启动和退出两个瞬间快照式采集资源状态（CPU 使用率、内存 RSS、线程数、GC 次数等）。它不持续采样，因此对毫秒级任务无干扰，也不会因采集失败导致任务异常。
适用于以下典型短任务：
- Shell 脚本封装的 Python/Java 工具调用（如数据清洗脚本）
- Kubernetes Job 或 CronJob 启动的单次计算任务
- Flink per-job 模式下生命周期小于 10 秒的 SQL 任务
- Serverless 函数（如 AWS Lambda 容器化模拟环境）
快速接入 Epsilon 收集器的三步法
以 Java 短任务为例（其他语言类似）：
-
打包阶段：将
epsilon-collector.jar作为javaagent添加进启动命令，但设置-Depsilon.mode=snapshot（禁用流式上报，只做启停快照） -
运行阶段：添加 JVM 参数
-Depsilon.snapshot.on.exit=true -Depsilon.snapshot.dir=/tmp/epsilon-snapshots，确保退出时写入本地文件 -
聚合阶段：任务结束后，用
epsilon-mergeCLI 工具合并同一批任务的多个快照（支持按 job_id、timestamp、host 分组），输出标准化 JSON 或 CSV
结合压测工具生成有效负载曲线
单纯采集不够，需与压测节奏对齐。推荐组合方式：
- 用 hey 或 wrk 控制并发请求频率（例如每秒触发 5 个 Kubernetes Job），每个 Job 内嵌 Epsilon 快照
- 用 Task ID + 时间戳前缀 命名快照文件，便于后续按时间窗口聚合（如“每 3 秒内所有任务的平均内存峰值”）
- 将 Epsilon 输出的
rss_mb、cpu_percent、duration_ms三项作为核心 SLI，绘制“并发数 → 平均耗时 / P95 内存占用”双轴图
避坑提醒：短任务压测的常见失效点
即便用了 Epsilon，仍需注意：
- 容器环境需挂载宿主机
/proc（否则 RSS 和 CPU 统计不准）；K8s 中加securityContext.procMount: "Unmasked" - 避免在
preStop钩子中清理快照目录——任务退出极快，钩子可能未执行完就 kill - Epsilon 不采集业务指标（如 QPS、错误码），需在任务代码里用
System.out.println("[EPSILON_METRIC] qps=42, errors=0")打印，再由日志采集器统一提取
