Python数据管道监控盲区在于try/except漏raise致静默丢数据；重试需区分场景选tenacity或手写循环；SparkSubmitOperator需配置waitAppCompletion；Prometheus中Counter与Gauge不可混用。
监控失败任务时，try/except 里漏掉 raise 会导致静默丢数据
Python 数据管道最危险的监控盲区，不是没日志，而是“看起来成功了，其实下游全空”。常见写法是加个 try/except 记录错误，但忘了重新抛出异常——结果任务标记为完成，实际数据根本没进数仓。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有捕获异常后不终止流程的
except块，必须明确决定：重试、跳过、还是raise；别默认吞掉 - 用
logging.exception()而非logging.error()，确保堆栈完整，否则查不到哪一行触发重试逻辑 - 如果用 Airflow，
on_failure_callback比日志更可靠——它不依赖任务体内的异常传播
重试用 tenacity 还是手写 while 循环？看是否需要退避和状态隔离
简单 HTTP 请求失败重试，手写三行 while + time.sleep() 足够；但数据库连接超时、Kafka 提交偏移失败这类场景，必须用带指数退避和状态重置的方案，否则可能雪崩。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
tenacity时，务必配stop=stop_after_attempt(3)和wait=wait_exponential(multiplier=1, min=1, max=10)，避免连续猛击下游 - 不要在重试装饰器里共享连接对象（比如把
requests.Session()当参数传进去），每次重试应重建干净上下文 - 对幂等性没保障的操作（如发 webhook），重试前先检查是否已执行成功，否则可能重复扣款
airflow.providers.apache.spark.operators.spark_submit 的失败判定不等于进程退出码
Airflow 默认只看 Spark 提交命令本身是否返回 0，但 Spark 作业可能提交成功、Driver 启动失败、或 Executor OOM 后被 YARN 杀掉——这时 spark-submit 进程早退出了，Airflow 却认为“任务完成”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 强制开启
spark.yarn.submit.waitAppCompletion=true（YARN 模式下），让spark-submit阻塞到应用真正结束 - 在 DAG 中用
SparkSubmitOperator的spark_binary参数指定带超时的 wrapper 脚本，比如timeout 3600 spark-submit ... - 关键任务加
trigger_rule="all_success"并配合depends_on_past=True，防止上游失败后下游误跑
监控指标打点时，prometheus_client 的 Counter 和 Gauge 别混用
想统计“今天处理了多少条订单”，该用 Counter；但如果存的是“当前正在处理的并发数”，就得用 Gauge。混用会导致 Prometheus 查询结果反直觉，比如重试次数突降（其实是 Gauge 被覆盖成新值）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
Counter只增不减，适合累计量（process_total,error_total）；Gauge可增可减，适合瞬时值（queue_length,active_workers） - 打点前先确认指标类型：重试次数是累计发生次数 →
Counter；当前重试中任务数 →Gauge - 本地调试时用
prometheus_client.start_http_server(8000)直接暴露/metrics，比埋进日志快得多
真正难的不是加监控或设重试，而是搞清每个环节的“失败边界”在哪——是网络断了？序列化失败？还是下游服务返回了 200 但 body 是 “{“error”:”timeout”}”？这些地方不定义清楚，再多的 tenacity 和 Counter 都只是幻觉。
