Help us learn about your current experience with the documentation. Take the survey.

健康检查

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed

GitLab 提供了存活性和就绪性探针,用于指示服务的健康状况和对所需服务的可访问性。这些探针报告数据库连接、Redis 连接和文件系统访问的状态。这些端点可以提供给像 Kubernetes 这样的调度器,以便在系统准备就绪之前保持流量,或在需要时重新启动容器。

健康检查端点通常用于负载均衡器和其他 Kubernetes 调度系统,这些系统需要在重定向流量之前确定服务的可用性。

在大型 Kubernetes 部署中,您不应该使用这些端点来确定有效的正常运行时间。这样做可能会在因自动扩展、节点故障或其他正常且非破坏性操作需求而移除 pods 时显示假阴性。

要在大型 Kubernetes 部署中确定正常运行时间,请查看 UI 的流量。这经过了适当的平衡和调度,因此是有效正常运行时间的更好指标。您还可以监控登录页面 /users/sign_in 端点。

在 GitLab.com 上,使用诸如 Pingdom 和 Apdex 测量等工具来确定正常运行时间。

IP 允许列表

要访问监控资源,请求的客户端 IP 需要包含在允许列表中。 有关详细信息,请参阅如何将 IP 添加到监控端点的允许列表

本地使用端点

使用默认的允许列表设置,可以通过以下 URL 从 localhost 访问这些探针:

GET http://localhost/-/health
GET http://localhost/health_check
GET http://localhost/-/readiness
GET http://localhost/-/liveness

健康状态

检查应用程序服务器是否正在运行。 它不验证数据库或其他服务是否正在运行。 此端点绕过 Rails 控制器,并在请求处理生命周期的 早期作为额外的中间件 BasicHealthCheck 实现。

GET /-/health

示例请求:

curl "https://gitlab.example.com/-/health"

示例响应:

GitLab OK

综合健康检查

不要将 /health_check 用于负载均衡或自动扩展。 此端点验证后端服务(数据库、Redis),即使这些服务缓慢或不可用,只要应用程序正常运行,它也会失败。这可能导致从负载均衡器中不必要地移除健康的应用程序节点。

/health_check 端点执行综合健康检查,包括数据库连接、Redis 可用性和其他后端服务。它由 health_check gem 提供,并验证整个应用程序堆栈。

将此端点用于:

  • 综合应用程序监控
  • 后端服务健康验证
  • 连接问题故障排除
  • 监控仪表板和警报
GET /health_check
GET /health_check/database
GET /health_check/cache
GET /health_check/migrations

示例请求:

curl "https://gitlab.example.com/health_check"

示例响应(成功):

success

示例响应(失败):

health_check failed: Unable to connect to database

可用检查:

  • database - 数据库连接
  • migrations - 数据库迁移状态
  • cache - Redis 缓存连接
  • geo(仅限 EE)- Geo 复制状态

就绪性

就绪性探针检查 GitLab 实例是否准备好 通过 Rails 控制器接受流量。默认情况下, 该检查仅验证实例检查。

如果指定了 all=1 参数,该检查还会验证 依赖服务(数据库、Redis、Gitaly 等), 并为每个服务提供状态。

GET /-/readiness
GET /-/readiness?all=1

示例请求:

curl "https://gitlab.example.com/-/readiness"

示例响应:

{
   "master_check":[{
      "status":"failed",
      "message": "unexpected Master check result: false"
   }],
   ...
}

失败时,端点返回 503 HTTP 状态码。

此检查被免除 Rack Attack 的限制。

存活性

在 GitLab 12.4 中,存活性检查的响应体已更改, 以匹配下面的示例。

检查应用程序服务器是否正在运行。 此探针用于了解 Rails 控制器 是否因多线程而陷入死锁。

GET /-/liveness

示例请求:

curl "https://gitlab.example.com/-/liveness"

示例响应:

成功时,端点返回 200 HTTP 状态码,以及如下响应。

{
   "status": "ok"
}

失败时,端点返回 503 HTTP 状态码。

此检查被免除 Rack Attack 的限制。

Sidekiq

了解如何配置 Sidekiq 健康检查