diff options
Diffstat (limited to 'doc/user/admin_area/monitoring/health_check.md')
| -rw-r--r-- | doc/user/admin_area/monitoring/health_check.md | 57 |
1 files changed, 33 insertions, 24 deletions
diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md index c22982ac190..ff056490653 100644 --- a/doc/user/admin_area/monitoring/health_check.md +++ b/doc/user/admin_area/monitoring/health_check.md @@ -1,12 +1,14 @@ +--- +type: concepts, howto +--- + # Health Check -> **Notes:** -> - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1. -> - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will -> be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior) -> section. -> - [Access token](#access-token) has been deprecated in GitLab 9.4 -> in favor of [IP whitelist](#ip-whitelist) +> - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1. +> - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was +> be deprecated in GitLab 9.1. +> - [Access token](#access-token-deprecated) has been deprecated in GitLab 9.4 +> in favor of [IP whitelist](#ip-whitelist). GitLab provides liveness and readiness probes to indicate service health and reachability to required services. These probes report on the status of the @@ -16,31 +18,28 @@ traffic until the system is ready or restart the container as needed. ## IP whitelist -To access monitoring resources, the client IP needs to be included in a whitelist. - -[Read how to add IPs to a whitelist for the monitoring endpoints][admin]. +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). ## Using the endpoints -With default whitelist settings, the probes can be accessed from localhost: +With default whitelist settings, the probes can be accessed from localhost using the following URLs: - `http://localhost/-/health` - `http://localhost/-/readiness` - `http://localhost/-/liveness` -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: +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 GitLab OK ``` The readiness and liveness probes will provide a report of system health in JSON format. -Readiness example output: +`readiness` probe example output: -``` +```json { "queues_check" : { "status" : "ok" @@ -60,9 +59,9 @@ Readiness example output: } ``` -Liveness example output: +`liveness` probe example output: -``` +```json { "cache_check" : { "status" : "ok" @@ -89,9 +88,8 @@ will return a valid successful HTTP status code, and a `success` message. ## Access token (Deprecated) ->**Note:** -Access token has been deprecated in GitLab 9.4 -in favor of [IP whitelist](#ip-whitelist) +> NOTE: **Note:** +> Access token has been deprecated in GitLab 9.4 in favor of [IP whitelist](#ip-whitelist). An access token needs to be provided while accessing the probe endpoints. The current accepted token can be found under the **Admin area ➔ Monitoring ➔ Health check** @@ -101,14 +99,25 @@ accepted token can be found under the **Admin area ➔ Monitoring ➔ Health che The access token can be passed as a URL parameter: -``` +```text https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN ``` +<!-- ## Troubleshooting + +Include any troubleshooting steps that you can foresee. If you know beforehand what issues +one might have when setting this up, or when something is changed, or on upgrading, it's +important to describe those, too. Think of things that may go wrong and include them here. +This is important to minimize requests for support, and to avoid doc comments with +questions that you know someone might ask. + +Each scenario can be a third-level heading, e.g. `### Getting error message X`. +If you have none to add when creating a doc, leave this section in place +but commented out to help encourage others to add to it in the future. --> + [ce-10416]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10416 [ce-3888]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3888 [pingdom]: https://www.pingdom.com [nagios-health]: https://nagios-plugins.org/doc/man/check_http.html [newrelic-health]: https://docs.newrelic.com/docs/alerts/alert-policies/downtime-alerts/availability-monitoring [kubernetes]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ -[admin]: ../../../administration/monitoring/ip_whitelist.md |