跳转到主要内容

​
实时频率

frequency_minute 参数控制 monitor 的扫描频率。
设置行为使用场景
0（默认）实时 — 信号在出现时即被检测并投递大多数 monitor — 最快的投递速度
1 - 60固定间隔（分钟）需要可预测的频率时
60 - 1440每小时到每天摘要式汇总、低优先级信号
设置 frequency_minute: 0 后，Pubrio 会在信号出现时立即检测并投递——无需轮询，无延迟。

​
重试配置

当 webhook 投递失败时，重试有助于自动恢复。
参数范围默认值建议
max_retry_per_trigger0 - 31关键 monitor 设置为 2-3
retry_delay_second1 - 51使用 3-5 秒以等待瞬时问题解决
重试会重新投递相同的负载——不会重新运行信号检测，也不会产生额外的搜索积分消耗。

​
流程重试

流程重试 端点允许您重新尝试特定的失败投递。主要优势：
  • 失败不收费 — 投递失败时不会消耗积分。仅在成功投递时收取积分。
  • 故障排除 — 重试失败的日志条目以诊断 Webhook 问题，无需创建新的触发。
  • 原始目标选项 — 使用 is_use_original_destination 以原始日志中的目标快照进行重试，适用于故障后已更新 Webhook URL 的情况。
通过 统计日志 查找失败的投递并逐一重试。

​
失败处理

max_failure_trigger 参数（范围：1-10，默认值：5）控制在 monitor 自动暂停前允许多少次连续投递失败。 推荐做法：
  1. 设置 notification_email 以在失败发生时接收告警
  2. 生产 monitor 将 max_failure_trigger 保持在 3-5
  3. 使用统计日志诊断失败——检查 error_message 和 response_status_code
  4. 修复问题后，通过更新 Monitor 重新激活
  5. 使用处理重试重新尝试特定的失败投递

​
通过统计端点轮询

虽然 webhook 处理实时投递，统计端点提供监控、调试和审计功能。

​
概览轮询

使用 Monitor 统计进行仪表板级别的健康检查： 
curl -X POST https://api.pubrio.com/monitors/statistics \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{ "profile_id": 1 }'
返回聚合指标：monitor 总数、今日与昨日的触发数、成功率和对比率。

​
基于日志的轮询

使用统计日志查看触发历史： 
curl -X POST https://api.pubrio.com/monitors/statistics/logs \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "profile_id": 1,
    "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "page": 1,
    "per_page": 10
  }'
每个日志条目包含状态、积分用量、信号/公司/人员数量、处理时间和错误详情。
将 webhook 投递与定期日志轮询结合使用以获得最大可靠性：webhook 处理实时数据处理，日志轮询捕获任何遗漏的投递并提供审计追踪。

​
扩展建议

优先选择专注的 monitor 而非过于宽泛的 monitor。 追踪”美国企业级公司的 AI 职位”的 monitor 比”所有地方的所有职位”更容易调试。专注的 monitor 还允许你将不同的信号类型路由到不同的 webhook 端点。
你的 webhook 端点应该：
  • 在 30 秒内响应
  • 立即返回 200 并异步处理数据
  • 优雅地处理重复负载（幂等性）
  • 记录所有传入负载以便调试
使用获取 Monitor 列表进行筛选：
  • 按 detection_mode 和 destination_type 筛选
  • 按 last_modified 或 last_trigger_at 排序
  • 使用 search_term 按名称搜索
使用 Monitor 统计快速发现表现不佳的 monitor。