Prometheus进程监控需分层采集：系统层用node_exporter或windows_exporter抓基础状态，应用层用客户端库暴露业务指标，短任务经Pushgateway中转，并通过relabel_configs统一标签实现联动下钻。
进程监控不能只靠“ps aux”看一眼，得让 Prometheus 持续、结构化地采集关键指标，并能和系统、应用指标联动下钻分析。核心思路是：系统层用 Exporter 抓进程基础状态，应用层用客户端库暴露业务维度的进程行为，再通过统一标签关联。
用 node_exporter 或 windows_exporter 抓进程基础指标
node_exporter（Linux）和 windows_exporter（Windows）都内置进程相关收集器，无需额外开发就能获取进程存活、CPU/内存占用、线程数等通用信息。
- Linux 下启用
processes收集器（默认开启），指标如process_cpu_seconds_total{process_name="nginx"}、process_resident_memory_bytes{process_name="redis-server"} - Windows 下通过
--collectors.enabled=process启用进程采集，支持按进程名、PID、用户、会话等多维度过滤，指标如windows_process_cpu_time_total{process="chrome"} - 建议在启动时加白名单，避免采集过多低价值进程：比如 node_exporter 可配
--collector.processes.whitelist="^(nginx|redis-server|python3)$"
用 prometheus-client-python 主动暴露进程级业务指标
如果进程本身是 Python 服务（如 Celery worker、后台任务脚本），直接在代码里定义指标更精准——不只是“它在不在”，而是“它干得怎么样”。
- 用 Counter 记录任务执行总数、失败次数：
task_runs_total{worker="celery@web01",status="success"} - 用 Gauge 反映当前活跃任务数、队列积压量：
celery_active_tasks{queue="default"} - 用 Histogram 统计单次任务耗时分布，支持查 P95 延迟：
task_duration_seconds_bucket{task="send_email",le="5.0"} - 关键细节：标签值尽量动态注入，比如
worker=socket.gethostname()、queue=task.queue，避免硬编码导致多实例指标混淆
对短生命周期进程或批处理任务，用 Pushgateway 中转
像定时脚本、CI 构建任务这类运行时间很短的进程，Prometheus 的 pull 模型抓不到——它们还没等被拉取就退出了。这时要用 Pushgateway 作为临时中转站。
- 脚本结束前调用
push_to_gateway("pushgateway:9091", job="backup_job", registry=registry) - Pushgateway 会暂存指标，Prometheus 定期从它那里拉取，指标带
job="backup_job"标签，还可加instance="web01"区分来源 - 注意清理策略：设置
--persistence.file并配合 TTL，避免过期指标堆积；或脚本开头先 push 空指标清旧数据
统一标签与告警联动的关键配置
光有指标不够，得让进程指标能和主机、服务、环境对上号，才能快速定位问题。
- 在 Prometheus 的
scrape_configs里用relabel_configs注入统一标签：比如把主机名映射为host，把部署目录路径提取出服务名作为service - 写告警规则时，结合进程状态与系统资源：例如
absent(process_cpu_seconds_total{process="myapp"}[5m])表示进程已消失，再叠加node_load1 > 8就能区分是进程崩了还是机器过载 - Grafana 面板里把
process_resident_memory_bytes和jvm_memory_used_bytes（如果 Java 进程）画在同一图，能直观看出是堆内还是堆外内存异常
