gitlab-nginx日志狂刷gitlab-runner /api/v4/jobs/request接口日志

Posted on Views:

这是GitLab Runner 正常的“心跳式拉活”行为，不是异常，也不是攻击。只是 **Nginx 日志把它“忠实地记录下来”。

1. 现象本质：为什么 Nginx 在疯狂刷这条日志

POST /api/v4/jobs/request  →  204 No Content
User-Agent: gitlab-runner 16.3.0

1.1 这一步 GitLab Runner 在干嘛

GitLab Runner 是主动轮询模式，不是 Server Push。

它会不断问 GitLab：

“现在有任务给我吗？”

  • 有任务 → 返回 201 + job payload
  • 没任务 → 返回 204 No Content（你现在看到的）

这是完全符合 GitLab 设计的行为。

2. 请求流程（核心机制）

sequenceDiagram
    participant Runner as GitLab Runner
    participant Nginx as Nginx
    participant GitLab as GitLab Rails API

    Runner->>Nginx: POST /api/v4/jobs/request
    Nginx->>GitLab: 转发请求
    GitLab-->>Nginx: 204 No Content
    Nginx-->>Runner: 204
    Note over Runner: sleep 几秒
继续下一轮请求

2.1 为什么是 POST 而不是 GET

  • 请求体包含 Runner token、能力标签
  • 服务端需要校验 Runner 状态
  • 避免被缓存（GET 容易被中间层缓存）

3. 为什么你会“明显感觉在刷日志”

3.1 常见触发条件

  1. Runner 数量多

    • 每个 Runner 都在独立轮询

  2. Runner check_interval 较小

    • 默认 3s 左右
    • 10 个 Runner ≈ 每分钟 200+ 条日志

  3. Nginx access_log 未过滤

    • 所有 2xx 都记
    • /api/v4/jobs/request 频率极高

4. 解决方案

4.1 方案一（强烈推荐）：Nginx 日志过滤

不记录这类心跳请求

1
2
3
4
5
6
map $request_uri $log_jobs_request {
    default 1;
    ~^/api/v4/jobs/request$ 0;
}

access_log /var/log/nginx/access.log main if=$log_jobs_request;

效果：

  • GitLab API 还在
  • Runner 正常跑
  • 日志立刻清净 80%+