fix mistakes in docs

This commit is contained in:
tarat44 2021-10-07 02:29:41 -04:00
parent ecdcfd6360
commit e52f5071d0
2 changed files with 10 additions and 7 deletions

View File

@ -186,7 +186,10 @@ The table below shows this endpoint's support for
- `H2PING` `(string "")` - Specifies an address that uses http2 to run a ping check on.
At the specified `Interval`, a connection is made to the address, and a ping is sent.
If the ping is successful, the check will be classified as `passing`, otherwise it will be marked as `critical`.
TLS is used by default. To disable TLS and use h2c, set `H2PINGUseTLS` to `false`.
TLS is used by default. To disable TLS and use h2c, set `H2PingUseTLS` to `false`.
If TLS is enabled, a valid SSL certificate is required by default, but verification can be removed with `TLSSkipVerify`.
- `H2PingUseTLS` `(bool: true)` - Specifies if TLS should be used for H2PING check.
If TLS is enabled, a valid SSL certificate is required by default, but verification can be removed with `TLSSkipVerify`.
- `HTTP` `(string: "")` - Specifies an `HTTP` check to perform a `GET` request

View File

@ -122,7 +122,7 @@ There are several different kinds of checks:
- `H2ping + Interval` - These checks test an endpoint that uses http2
by connecting to the endpoint and sending a ping frame. TLS is assumed to be configured by default.
To disable TLS and use h2c, set `h2ping_enable_tls` to `false`. If the ping is successful
To disable TLS and use h2c, set `h2ping_use_tls` to `false`. If the ping is successful
within a specified timeout, then the check is updated as passing.
The timeout defaults to 10 seconds, but is configurable using the `timeout` field. If TLS is enabled a valid
certificate is required, unless `tls_skip_verify` is set to `true`.
@ -165,7 +165,7 @@ A HTTP check:
"tls_server_name": "",
"tls_skip_verify": false,
"method": "POST",
"header": {"Content-Type": ["application/json"]},
"header": { "Content-Type": ["application/json"] },
"body": "{\"method\":\"health\"}",
"interval": "10s",
"timeout": "1s"
@ -422,14 +422,14 @@ a health check may be configured to become passing/warning/critical only after a
specified number of consecutive checks return passing/critical.
The status will not transition states until the configured threshold is reached.
* `success_before_passing` - Number of consecutive successful results required
before check status transitions to passing. Defaults to `0`. Added in Consul 1.7.0.
* `failures_before_warning` - Number of consecutive unsuccessful results required
- `success_before_passing` - Number of consecutive successful results required
before check status transitions to passing. Defaults to `0`. Added in Consul 1.7.0.
- `failures_before_warning` - Number of consecutive unsuccessful results required
before check status transitions to warning. Defaults to the same value as that of
`failures_before_critical` to maintain the expected behavior of not changing the
status of serivce checks to `warning` before `critical` unless configured to do so.
Values higher than `failures_before_critical` are invalid. Added in Consul 1.11.0.
* `failures_before_critical` - Number of consecutive unsuccessful results required
- `failures_before_critical` - Number of consecutive unsuccessful results required
before check status transitions to critical. Defaults to `0`. Added in Consul 1.7.0.
This feature is available for HTTP, TCP, gRPC, Docker & Monitor checks.