Health Check

原文：https://docs.gitlab.com/ee/user/admin_area/monitoring/health_check.html

Health Check

版本历史

  • 在 GitLab 9.1 中引入了活动性和就绪性探针.
  • health_check端点是在 GitLab 8.8 中引入的 ，在 GitLab 9.1 中已弃用.
  • 在 GitLab 9.4 中不赞成使用访问令牌 ，而推荐使用IP 白名单 .

manbetx 客户端打不开提供活跃度和准备情况探针，以指示服务的健康状况和对所需服务的可达性. 这些探针报告数据库连接，Redis 连接和对文件系统的访问状态. 可以将这些端点提供给 Kubernetes 之类的调度程序以保持流量，直到系统准备就绪或根据需要重新启动容器.

IP whitelist

要访问监视资源，需要将发出请求的客户端 IP 包含在白名单中. 有关详细信息，请参阅如何将 IP 添加到监视端点的白名单 .

Using the endpoints locally

使用默认白名单设置，可以使用以下 URL 从本地主机访问探针：

  1. GET http://localhost/-/health
  1. GET http://localhost/-/readiness
  1. GET http://localhost/-/liveness

Health

检查应用服务器是否正在运行. 它不会验证数据库或其他服务是否正在运行. 该端点绕过了 Rails Controller，并在请求处理生命周期的早期就作为附加的中间件BasicHealthCheck实现.

  1. GET /-/health

请求示例：

  1. curl 'https://gitlab.example.com/-/health'

响应示例：

  1. GitLab OK

Readiness

就绪探针会检查 GitLab 实例是否准备好通过 Rails Controller 接受流量. 默认情况下，该检查仅验证实例检查.

如果指定了all=1参数，则检查还将验证相关服务（数据库，Redis，Gitaly 等）并为每个服务提供状态.

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

请求示例：

  1. curl 'https://gitlab.example.com/-/readiness'

Example response:

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

失败时，端点将返回503 HTTP 状态代码.

如果通过token身份验证，则此检查确实会命中数据库，并且会重做 Redis.

此检查不受机架攻击.

Liveness

警告：在 GitLab 12.4中，”活动性”检查的响应主体已更改为与以下示例匹配.

检查应用服务器是否正在运行. 该探针用于了解 Rails 控制器是否不会由于多线程而死锁.

  1. GET /-/liveness

请求示例：

  1. curl 'https://gitlab.example.com/-/liveness'

响应示例：

成功后，端点将返回200 HTTP 状态代码和如下响应.

  1. {  "status":  "ok"  }

失败时，端点将返回503 HTTP 状态代码.

此检查不受机架攻击.

Access token (Deprecated)

注意：在 GitLab 9.4 中不赞成使用访问令牌，而推荐使用IP 白名单 .

访问探针端点时需要提供访问令牌. 当前接受的令牌可以在您的 GitLab 实例的管理区域>监视>运行状况检查 （ admin/health_check ）页面下找到.

access token

可以将访问令牌作为 URL 参数传递：

  1. https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN

注意：如果无法访问数据库或 Redis 服务，则不能保证探针端点响应正确. 您应该从已弃用的访问令牌切换到IP 白名单 ，以避免出现这种情况.