Commit 4ac0cc00 authored by GitLab Bot's avatar GitLab Bot

Automatic merge of gitlab-org/gitlab-ce master

parents ebdb9855 fdcfae2a
...@@ -82,6 +82,9 @@ library. `tls` corresponds to StartTLS, not to be confused with regular TLS. ...@@ -82,6 +82,9 @@ library. `tls` corresponds to StartTLS, not to be confused with regular TLS.
Normally, if you specify `ssl` it will be on port 636, while `tls` (StartTLS) Normally, if you specify `ssl` it will be on port 636, while `tls` (StartTLS)
would be on port 389. `plain` also operates on port 389. would be on port 389. `plain` also operates on port 389.
NOTE: **Note:**
LDAP users must have an email address set, regardless of whether it is used to log in.
**Omnibus configuration** **Omnibus configuration**
```ruby ```ruby
......
# Health Check # Health Check
> **Notes:** > **Notes:**
> - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1. > - 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 > - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was
> be deprecated in GitLab 9.1. > be deprecated in GitLab 9.1.
...@@ -15,21 +16,19 @@ traffic until the system is ready or restart the container as needed. ...@@ -15,21 +16,19 @@ traffic until the system is ready or restart the container as needed.
## IP whitelist ## IP whitelist
To access monitoring resources, the client IP needs to be included in a whitelist. To access monitoring resources, the requesting client IP needs to be included in a whitelist.
[Read how to add IPs to a whitelist for the monitoring endpoints][admin]. [Read how to add IPs to a whitelist for the monitoring endpoints][admin].
## Using the endpoints ## 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/-/health`
- `http://localhost/-/readiness` - `http://localhost/-/readiness`
- `http://localhost/-/liveness` - `http://localhost/-/liveness`
The first endpoint, `/-/health/`, only checks whether the application server is running. It does 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:
-not verify the database or other services are running. A successful response will return
a 200 status code with the following message:
``` ```
GitLab OK GitLab OK
...@@ -37,9 +36,9 @@ GitLab OK ...@@ -37,9 +36,9 @@ GitLab OK
The readiness and liveness probes will provide a report of system health in JSON format. 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" : { "queues_check" : {
"status" : "ok" "status" : "ok"
...@@ -59,9 +58,9 @@ Readiness example output: ...@@ -59,9 +58,9 @@ Readiness example output:
} }
``` ```
Liveness example output: `liveness` probe example output:
``` ```json
{ {
"cache_check" : { "cache_check" : {
"status" : "ok" "status" : "ok"
......
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