Commit fc9ad598 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

Merge branch 'docs-health-check-failure-examples' into 'master'

Docs health check failure examples

Closes #64193

See merge request gitlab-org/gitlab-ce!31945
parents 2abeb0c3 3d460a51
...@@ -21,28 +21,71 @@ traffic until the system is ready or restart the container as needed. ...@@ -21,28 +21,71 @@ traffic until the system is ready or restart the container as needed.
To access monitoring resources, the requesting client IP needs to be included in a whitelist. To access monitoring resources, the requesting client IP needs to be included in a whitelist.
For details, see [how to add IPs to a whitelist for the monitoring endpoints](../../../administration/monitoring/ip_whitelist.md). For details, see [how to add IPs to a whitelist for the monitoring endpoints](../../../administration/monitoring/ip_whitelist.md).
## Using the endpoints ## Using the endpoints locally
With default whitelist settings, the probes can be accessed from localhost using the following URLs: With default whitelist settings, the probes can be accessed from localhost using the following URLs:
- `http://localhost/-/health` ```text
- `http://localhost/-/readiness` GET http://localhost/-/health
- `http://localhost/-/liveness` ```
```text
GET http://localhost/-/readiness
```
```text
GET http://localhost/-/liveness
```text
GET http://localhost/-/health
```
```text
GET http://localhost/-/readiness
```
The first endpoint, `health`, only checks whether the application server is running. It does not verify the database or other services are running. A successful response will return a 200 status code with the following message: ```text
GET http://localhost/-/liveness
```
## Health
Checks whether the application server is running. It does not verify the database or other services are running.
```text
GET /-/health
```
Example request:
```sh
curl 'https://gitlab.example.com/-/health'
```
Example response:
```text ```text
GitLab OK GitLab OK
``` ```
The readiness and liveness probes will provide a report of system health in JSON format. ## Readiness
The readiness probe checks whether the Gitlab instance is ready to use. It checks the dependent services (Database, Redis, Gitaly etc.) and gives a status for each.
```text
GET /-/readiness
```
Example request:
```sh
curl 'https://gitlab.example.com/-/readiness'
```
`readiness` probe example output: Example response:
```json ```json
{ {
"db_check":{ "db_check":{
"status":"ok" "status":"failed",
"message": "unexpected Db check result: 0"
}, },
"redis_check":{ "redis_check":{
"status":"ok" "status":"ok"
...@@ -65,7 +108,23 @@ The readiness and liveness probes will provide a report of system health in JSON ...@@ -65,7 +108,23 @@ The readiness and liveness probes will provide a report of system health in JSON
} }
``` ```
`liveness` probe example output: ## Liveness
The liveness probe checks whether the application server is alive. Unlike the [`health`](#health) check, this check hits the database.
```text
GET /-/liveness
```
Example request:
```sh
curl 'https://gitlab.example.com/-/liveness'
```
Example response:
On success, the endpoint will return a valid successful HTTP status code, and a response like below.
```json ```json
{ {
...@@ -90,10 +149,7 @@ The readiness and liveness probes will provide a report of system health in JSON ...@@ -90,10 +149,7 @@ The readiness and liveness probes will provide a report of system health in JSON
} }
``` ```
## Status On failure, the endpoint will return a `500` HTTP status code.
On failure, the endpoint will return a `500` HTTP status code. On success, the endpoint
will return a valid successful HTTP status code, and a `success` message.
## Access token (Deprecated) ## Access token (Deprecated)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment