Harbor Webhook 投递延迟或未发送
目录
问题描述根本原因故障排查步骤 1 - 检查 Job Service Dashboard步骤 2 - 检查 jobservice 健康状态步骤 3 - 检查 jobservice 日志中的失败端点步骤 4 - 手动验证端点解决方案1. 删除无效的 Webhook 配置2. 清理卡住的队列3. 如果队列未恢复，则重启 jobservice4. 重新评估 jobservice 资源规格注意事项问题描述
在 Harbor 项目中发生事件后（例如推送镜像），配置的 Webhook 端点未能及时收到通知。症状包括：
- Webhook 消费方（例如 CI/CD 流水线中的制品触发器）响应延迟很长（几分钟或更久），或者完全没有响应。
- 在 Harbor UI → Job Service Dashboard 中，可以看到
WEBHOOK作业在待处理队列中的数量不断增加。
根本原因
Harbor 通过以下路径投递 Webhook：
harbor-core会为每个事件将一个 key 入队到 Redis。harbor-jobservice消费队列并调用已配置的 Webhook 端点。- 如果 HTTP 调用失败，
harbor-jobservice会重试最多 10 次，然后才丢弃该事件。
以下两种常见情况会导致流水线积压：
- 不可达的 Webhook 端点持续累积重试。 当项目中配置的一个或多个端点已不再可达时（例如服务已下线、URL 配置错误、防火墙规则变更），针对这些端点的每个事件都会消耗完全部 10 次重试后才被丢弃。如果存在足够多的无效端点，
jobservice大部分时间都会用来重试这些失效目标，正常的 Webhook 会排在它们后面等待。 harbor-jobservice被重启（例如因 OOM 被杀死）。 如果 Pod 在内存压力下反复重启，正在执行的作业会被中断，队列会持续增长。
故障排查
步骤 1 - 检查 Job Service Dashboard
在 Harbor UI 中，打开 Job Service Dashboard，查看 Type = WEBHOOK 的作业。重点关注：
- Pending Count —— 等待发送的 Webhook 作业数量。
- Latency —— 最早的待处理作业已经等待了多长时间。
Pending Count 持续增长通常表明重试正在不断堆积。
步骤 2 - 检查 jobservice 健康状态
确认 harbor-jobservice 没有发生崩溃循环：
如果在 Pod 状态中看到频繁重启，或者出现 OOMKilled 原因，说明 jobservice 资源不足。请在 Harbor CR 中增加其 CPU/内存 request 和 limit。
步骤 3 - 检查 jobservice 日志中的失败端点
如果同一个 URL 反复失败，说明该端点不可达，需要清理。
步骤 4 - 手动验证端点
从一个网络访问条件与 jobservice 类似的 Pod 中，测试受影响项目上配置的每个 Webhook URL：
在这里超时或返回错误的 URL，都可以视为需要移除的候选项。
解决方案
1. 删除无效的 Webhook 配置
在 Harbor UI 中，打开受影响的项目 → Webhooks，删除在步骤 4 中识别出的所有不可达端点。这样可以阻止新的事件继续进入重试循环。
2. 清理卡住的队列
在 Job Service Dashboard 中，选中处于待处理状态的 WEBHOOK 作业并点击 STOP。完成后，WEBHOOK 的 Pending Count 应降为 0，正常事件即可恢复投递。
3. 如果队列未恢复，则重启 jobservice
如果停止作业后队列仍然卡住，请重启 harbor-jobservice：
4. 重新评估 jobservice 资源规格
如果步骤 2 显示 Pod 发生了 OOMKilled，请提高 Harbor CR 中的资源限制，使 jobservice 有足够的内存处理其工作集。对于一个处于活跃使用状态的小型 Harbor，jobservice 通常至少需要 4 CPU / 8 Gi 内存 才能保持稳定。
注意事项
- 即使采取了以上三种缓解措施，Webhook 投递仍然是尽力而为。消费者不能假设每个事件都会被送达——重试预算是有限的（10 次），超过后事件会被丢弃。
- 在设计依赖 Harbor Webhook 的集成时，应优先使用具备幂等性的消费者，并定期基于 Harbor API 进行对账，而不要仅依赖单次通知。