币圈Telegram群 教程采集任务的监控与报警：Prometheus + Grafana实践

教程采集任务最常见的问题，不是程序完全停止，而是任务看似成功、数据却已经过期。例如定时器仍在运行，但解析失败率升高、采集数量骤降，或者某个关键任务已经数小时没有成功完成。

本文以 Prometheus、Grafana 和 Alertmanager 为核心，介绍如何为教程采集系统建立一套可观察、可定位、可恢复的监控体系。示例适用于 Python、Node.js、Java 等能够暴露 Prometheus 指标的任务服务。

🧭 一、先定义监控目标，而不是盲目堆指标

优秀的监控首先要回答三个问题：任务是否按时执行、数据是否成功产出、异常发生后是否能够及时通知负责人。只监控进程存活状态，无法判断采集内容是否为空或结构是否已经变化。

1. 任务指标分层

建议将指标分为运行层、质量层和资源层。运行层关注执行次数与耗时，质量层关注成功率、解析错误和产出数量，资源层则关注队列长度、并发数与抓取延迟。

tutorial_task_runs_total{task, result}
tutorial_task_duration_seconds{task}
tutorial_task_items_total{task}
tutorial_task_parse_errors_total{task}
tutorial_task_last_success_unixtime{task}
tutorial_task_queue_depth{task}

标签应保持稳定，例如 task、env、result 和 instance。不要把文章 URL、用户 ID 或错误详情直接作为标签，否则高基数会增加 Prometheus 内存压力，甚至影响查询性能。

币圈Telegram群 ⚙️ 二、让采集程序暴露可用指标

应用应提供一个只读的 /metrics 接口，让 Prometheus 主动抓取。对于持续运行的 Worker，这是最简单可靠的方式；对于一次性批处理任务，则需要额外设计“最后一次成功时间”指标。

下面是 Python 客户端的简化示例，重点是记录成功、失败、耗时和最后成功时间，而不是把所有业务日志都转换成指标。

import time
from prometheus_client import Counter, Gauge, Histogram, start_http_server

runs = Counter(
    "tutorial_task_runs_total",
    "Total task runs",
    ["task", "result"]
)
duration = Histogram(
    "tutorial_task_duration_seconds",
    "Task execution duration",
    ["task"]
)
last_success = Gauge(
    "tutorial_task_last_success_unixtime",
    "Unix time of the last successful run",
    ["task"]
)

def execute_task(task_name, handler):
    started = time.time()
    try:
        handler()
        runs.labels(task_name, "success").inc()
        last_success.labels(task_name).set(time.time())
    except Exception:
        runs.labels(task_name, "failed").inc()
        raise
    finally:
        duration.labels(task_name).observe(time.time() - started)

start_http_server(9105)

生产环境中还应增加超时、重试上限和错误分类，例如网络错误、解析错误、目标站点限流等。重试不能无限进行，否则单个异常站点可能占满线程，导致其他教程采集任务也无法执行。

🔧 三、配置 Prometheus 抓取任务

Prometheus 的 scrape 配置应区分开发、测试和生产环境，并为每个任务添加清晰的 job 标签。若采集服务运行在 Kubernetes 中，可以改用 Service Discovery，避免手工维护实例地址。

scrape_configs:
  - job_name: "tutorial-crawler"
    scrape_interval: 30s
    scrape_timeout: 10s
    static_configs:
      - targets:
          - "crawler-worker-01:9105"
        labels:
          env: "production"
          service: "tutorial-crawler"

抓取间隔应明显短于业务允许的最大延迟，但不必追求秒级监控。采集任务通常是分钟级或小时级作业，合理的间隔能够在监控及时性、存储成本和应用负载之间取得平衡。

3.1 设计第一批告警规则

第一批规则建议覆盖“没有成功”“失败率过高”“实例不可达”和“队列持续堆积”。告警必须包含 task、env、severity 和 runbook_url，方便值班人员收到通知后直接定位。

groups:
  - name: tutorial-crawler
    rules:
      - alert: TutorialTaskNoRecentSuccess
        expr: time() - tutorial_task_last_success_unixtime{task!=""} > 1800
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "教程采集任务长时间未成功"
          description: "任务 {{ $labels.task }} 已超过 30 分钟没有成功运行"
          runbook_url: "https://example.com/runbooks/tutorial-crawler"

      - alert: TutorialTaskHighFailureRate
        expr: |
          sum by (task) (increase(tutorial_task_runs_total{result="failed"}[15m]))
          /
          clamp_min(sum by (task) (increase(tutorial_task_runs_total[15m])), 1)
          > 0.2
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "教程采集任务失败率过高"

      - alert: TutorialCrawlerExporterDown
        expr: up{job="tutorial-crawler"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "采集服务指标端点不可达"

阈值不能照搬示例，应根据历史基线调整。对于每天运行一次的任务，使用短时间窗口判断失败率可能没有意义，更适合依赖最后成功时间、任务截止时间和业务产出量。

📊 四、用 Grafana 组织可执行的监控面板

Grafana 首页不应堆满几十个曲线，而应先展示任务总览，再逐层下钻到单个任务。推荐设置 task、env 和 instance 变量，让值班人员可以快速过滤异常范围。

4.1 推荐的四类面板

任务状态面板展示最后成功时间、最近执行结果和当前告警；吞吐面板展示每分钟新增教程数量；耗时面板展示 P50、P95 和 P99；质量面板展示解析错误、空内容和重复数据比例。

sum by (task, result) (
  rate(tutorial_task_runs_total[5m])
)

histogram_quantile(
  0.95,
  sum by (le, task) (
    rate(tutorial_task_duration_seconds_bucket[10m])
  )
)

time() - tutorial_task_last_success_unixtime{task=~"$task"}

sum by (task) (
  rate(tutorial_task_parse_errors_total[15m])
)

面板中的单位要明确，例如 seconds、items、percent 或 bytes。对“没有数据”和“数值为 0”要区别处理：没有数据通常表示指标未上报或抓取失败，0 才表示任务确实没有产出。

🚨 五、通过 Alertmanager 让告警真正送达

Prometheus 负责计算规则，Alertmanager 负责分组、去重、抑制和路由。建议按 env、service 和 severity 分组，避免同一个 Worker 的多个实例故障时产生大量重复消息。

route:
  group_by: ["alertname", "env", "task"]
  group_wait: 30s
  group_interval: 10m
  repeat_interval: 2h
  receiver: "oncall"

receivers:
  - name: "oncall"
    webhook_configs:
      - url: "https://alert.example.com/webhook"
        send_resolved: true

币圈Telegram群 通知内容应包含影响对象、持续时间、当前值、可能原因和处理链接。不要只发送“任务失败”四个字，否则告警虽然到达了，却无法帮助人员快速恢复服务。

【教程采集告警】
任务：{{ $labels.task }}
环境：{{ $labels.env }}
级别：{{ $labels.severity }}
现象：最近一次成功时间已超过阈值。
建议：先检查 Worker 日志、目标站点响应、队列状态和解析器版本。
处理记录：请在 Runbook 中补充原因与修复结果。

Webhook 地址、Token 和密码不能直接写入公开仓库。生产环境应使用 Secret、环境变量或密钥管理服务，并限制告警接收端的访问来源。

🧪 六、上线前验证与故障定位

监控上线前要主动制造一次失败、一次超时和一次空结果，确认指标变化、规则触发、通知送达和恢复消息都符合预期。只验证正常路径，往往会在真正故障时暴露配置问题。

promtool check config prometheus.yml
promtool check rules tutorial-alerts.yml

curl http://crawler-worker-01:9105/metrics
curl "http://prometheus:9090/api/v1/query?query=up%7Bjob%3D%22tutorial-crawler%22%7D"

币圈Telegram群 排查时应遵循“指标端点—Prometheus Targets—PromQL 查询—告警规则—Alertmanager 路由—接收端”的顺序。若 Grafana 显示空白，先确认时间范围、数据源和标签过滤条件，而不是立即修改业务代码。

此外，采集系统必须遵守目标站点的 robots.txt、服务条款和访问频率限制，并避免收集不必要的个人信息。合理限速、缓存和退避不仅是合规要求，也能降低封禁风险，提升任务长期稳定性。

✅ 七、形成可持续的监控闭环

稳定的 Prometheus + Grafana 实践不是一次性配置，而是持续迭代的过程。每次故障结束后，都应检查告警是否过早、过晚或缺少上下文，并将真实处理步骤补充到 Runbook。

当任务数量增加时，可进一步引入 SLO，例如“规定周期内成功完成的任务比例”和“数据产出延迟”。用业务结果衡量系统健康度，才能避免监控只关注机器，却忽略教程采集本身的价值。

常见问题解答（FAQ）

Prometheus 能直接监控一次性脚本吗？

可以，但一次性脚本结束后不会持续提供指标。对于短生命周期任务，应谨慎使用 Pushgateway，重点记录任务完成状态、最后成功时间和执行结果，并设计过期或清理机制，避免旧数据长期伪装成当前状态。

为什么任务失败了，Grafana 仍然显示正常？

常见原因是面板只展示 up 指标，或查询范围没有覆盖任务执行时间。应同时检查失败计数、最后成功时间、产出数量和 Prometheus 的 Targets 状态。

币圈Telegram群 告警太多，应该如何减少噪声？

先区分 warning 与 critical，再使用 for、group_by 和 inhibition 进行合并。不要简单关闭告警，应优先移除无法指导行动的规则，并为保留的告警补充明确的处理手册。

采集数量下降一定代表程序出错吗？

不一定，目标站点内容变化、节假日流量下降或过滤规则更新都可能造成产出减少。应结合目标响应码、解析错误率、输入数量和历史基线进行判断，而不是仅凭一个数量指标下结论。