机器人采集任务的监控与报警：Prometheus + Grafana实践

机器人采集任务一旦进入多站点、并发执行和定时调度阶段，最先暴露的通常不是代码错误，而是任务悄悄变慢、数据量异常下降、部分站点持续失败等问题。

仅依赖日志排查，很难及时回答“哪个任务失败了”“失败持续多久”“是否影响了业务数据”这些关键问题。本文以 Prometheus 和 Grafana 为核心，介绍一套可落地的机器人采集任务监控与报警方案，同时兼顾稳定性、可观测性和运维成本。

🧭 一、先明确监控目标：不要只盯着进程是否存活

采集机器人进程处于运行状态，并不代表任务真的健康。程序可能仍然在线，但目标站点返回了验证码、解析规则失效，或者队列已经积压数小时。

因此，监控应覆盖四个层次：任务是否执行、执行是否成功、执行质量是否正常、数据是否按预期产出。这四层指标能够把“机器活着”和“业务正常”区分开。

核心指标设计

任务执行次数适合使用 Counter，记录成功、失败和跳过等结果；执行耗时适合使用 Histogram，用于观察平均耗时和 P95、P99 延迟。

此外，还应记录抓取条数、队列延迟、最后一次成功时间、HTTP 状态分布以及当前活跃 Worker 数量。指标标签建议只使用任务名、站点和结果类型，避免把 URL、用户 ID 或关键词直接放入标签。

collector_task_runs_total{task, site, result}
collector_task_duration_seconds{task, site}
collector_items_total{task, site}
collector_queue_lag_seconds{queue}
collector_last_success_timestamp_seconds{task, site}
collector_http_responses_total{task, site, status}
collector_workers_active{service}

需要特别注意标签基数问题。将完整 URL、随机请求参数或错误堆栈作为标签，会快速制造大量时间序列，最终增加 Prometheus 内存压力并拖慢 Grafana 查询。

⚙️ 二、在采集程序中埋点

Prometheus 的基本模式是主动拉取指标。采集服务需要提供一个可访问的指标接口，Prometheus 按固定周期读取当前状态，应用程序则负责在任务执行过程中持续更新计数器、直方图和仪表盘指标。

下面示例使用 Python 客户端展示埋点思路，实际项目也可以使用 Go、Java、Node.js 或其他 Prometheus 官方客户端。

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

task_runs = Counter(
    "collector_task_runs_total",
    "Total collector task runs",
    ["task", "site", "result"]
)

task_duration = Histogram(
    "collector_task_duration_seconds",
    "Collector task duration",
    ["task", "site"],
    buckets=(1, 5, 10, 30, 60, 120, 300)
)

items_total = Counter(
    "collector_items_total",
    "Total collected items",
    ["task", "site"]
)

last_success = Gauge(
    "collector_last_success_timestamp_seconds",
    "Unix timestamp of last successful run",
    ["task", "site"]
)

def run_task(task, site):
    started = time.time()
    result = "success"

    try:
        items = collect_data(site)
        items_total.labels(task, site).inc(len(items))
        last_success.labels(task, site).set(time.time())
        save_data(items)
    except Exception:
        result = "error"
        raise
    finally:
        task_runs.labels(task, site, result).inc()
        task_duration.labels(task, site).observe(time.time() - started)

start_http_server(9108)

计数器不应在程序重启时手动清零，因为 Prometheus 的 rate 函数能够处理计数器重置。对于一次执行时间很短、执行完立即退出的批处理任务，可以考虑 Pushgateway，但必须设计唯一任务标识并定期清理过期数据。

采集程序还应区分网络错误、解析错误、限流、验证码和数据校验失败。错误原因可以写入日志或低基数标签，便于定位问题，但不要把完整异常文本直接作为 Prometheus 标签。

📡 三、配置 Prometheus 抓取指标

Prometheus 的抓取间隔需要根据任务频率和报警时效进行平衡。实时性要求较高的任务可以使用 15 秒到 30 秒的抓取周期，低频日报任务则可以适当放宽。

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "collector"
    metrics_path: /metrics
    static_configs:
      - targets:
          - "collector-a:9108"
          - "collector-b:9108"

生产环境中建议通过服务发现、容器编排平台或 Consul 管理目标地址，避免服务器扩容后还要手工修改配置。指标接口不应直接暴露到公网，至少要使用网络隔离、访问控制或反向代理认证。

部署完成后，先在 Prometheus 的 Targets 页面确认目标状态为 UP，再检查指标是否持续增长。不要在 Grafana 尚未验证之前直接上线报警，否则很容易因为指标名称、标签或权限配置错误产生误报。

📊 四、使用 Grafana 构建可读的监控面板

Grafana 面板不应只是指标堆叠，而要围绕运维决策组织。第一行建议展示任务成功率、最近成功时间、当前积压和整体采集条数，第二行展示耗时分位数、错误类型和各站点状态。

成功率应使用时间窗口计算，避免某一次瞬时失败放大为严重事故。耗时则优先观察 P95 或 P99，因为平均值可能掩盖少量但持续存在的慢任务。

sum by (task) (rate(collector_items_total[5m]))

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

sum by (task, result) (
  rate(collector_task_runs_total[10m])
)

time() - max by (task) (
  collector_last_success_timestamp_seconds
)

面板变量可以设置任务名和站点筛选器，让同一套 Dashboard 适用于不同采集项目。颜色建议统一：绿色表示正常，黄色表示风险，红色表示需要立即处理，避免同一状态在不同图表中使用不同含义。

🚨 五、设计真正有用的报警规则

报警阈值不能完全凭经验设置，应结合历史基线、任务周期和业务容忍度确定。对于每五分钟运行一次的任务，连续十分钟没有成功可能已经严重；对于每天运行一次的任务，则应围绕调度窗口设计规则。

groups:
  - name: collector.rules
    rules:
      - alert: CollectorSuccessRateLow
        expr: |
          (
            sum by (task) (
              rate(collector_task_runs_total{result="success"}[10m])
            )
            /
            clamp_min(
              sum by (task) (rate(collector_task_runs_total[10m])),
              1
            )
          ) < 0.95
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "采集任务成功率过低"

      - alert: CollectorTaskStale
        expr: |
          time() - max by (task) (
            collector_last_success_timestamp_seconds
          ) > 1800
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "采集任务超过 30 分钟没有成功"

      - alert: CollectorTargetDown
        expr: up{job="collector"} == 0
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "采集指标目标不可达"

报警内容必须包含任务名、站点、当前值、持续时间和处理建议。通知渠道可以接入企业微信、邮件、Telegram 或值班系统，但建议设置分组、静默和抑制规则，避免一个上游网络故障触发数百条重复消息。

每一条报警都应关联一份处理手册，例如先查看最近错误类型，再检查目标站点响应，最后确认代理、队列和数据库状态。没有处理路径的报警，往往只会增加噪声，而不会提升恢复速度。

🛡️ 六、生产环境中的稳定性与合规注意事项

采集任务应遵守目标站点的服务条款、robots 规则和访问频率限制。通过合理限速、退避重试、缓存和增量采集降低对目标服务的压力，也能减少自身被封禁后产生的大面积报警。

监控数据本身也可能包含敏感信息，因此不要把 Cookie、Token、完整请求头或个人数据写入日志和指标。Grafana 应按照团队角色分配只读、编辑和管理员权限，并对外部通知渠道进行脱敏。

上线前可进行一次故障演练：主动停止一个 Worker、模拟目标站点超时、制造解析失败并清空队列。确认报警能够触发、通知能够送达、面板能够定位问题，才算完成真正的监控闭环。

❓ 常见问题解答（FAQ）

Prometheus 能直接监控短时运行的采集脚本吗？

可以，但短脚本可能在 Prometheus 抓取前就已经退出。此类任务可使用 Pushgateway，或者由长期运行的调度器汇总执行结果后暴露指标，同时要设置过期清理机制。

为什么任务成功率很高，但采集数据仍然减少？

成功率只代表程序没有抛出错误，不能证明返回数据完整。应同时监控采集条数、字段校验通过率、去重比例和与历史基线的偏差。

报警太多，应该怎样降低噪声？

先增加持续时间条件，再使用告警分组、抑制和维护静默。更重要的是合并重复指标，并区分 warning 与 critical，让真正影响数据产出的故障优先通知值班人员。

Grafana 面板最应该优先展示哪些数据？

建议优先展示成功率、最后成功时间、采集条数、任务耗时 P95、队列延迟和错误类型。面板应服务于故障判断，而不是追求图表数量。

总体而言，Prometheus 负责持续采集和计算指标，Grafana 负责呈现趋势和辅助定位，报警系统则负责推动处理动作。只有把业务指标、可视化面板、通知策略和故障手册连接起来，机器人采集任务才真正具备可运营的监控能力。