+ 1 The ACL required depends on the config entry kind being updated: +
| Config Entry Kind | Required ACL | | ----------------- | ---------------- | @@ -221,9 +224,9 @@ The table below shows this endpoint's support for [agent caching](/api/features/caching.html), and [required ACLs](/api/index.html#authentication). -| Blocking Queries | Consistency Modes | Agent Caching | ACL Required | -| ---------------- | ----------------- | ------------- | ----------------------------------------------- | -| `NO` | `none` | `none` | `service:write`+ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -106,8 +113,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ----------------------------- | | `YES` | `all` | `none` | `intentions:read`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -162,8 +175,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ----------------------------- | | `YES` | `all` | `none` | `intentions:read`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -241,8 +260,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ------------------------------ | | `NO` | `none` | `none` | `intentions:write`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -289,8 +314,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ------------------------------ | | `NO` | `none` | `none` | `intentions:write`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -329,8 +360,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ----------------------------- | | `NO` | `none` | `none` | `intentions:read`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters @@ -376,8 +413,14 @@ The table below shows this endpoint's support for | ---------------- | ----------------- | ------------- | ----------------------------- | | `NO` | `none` | `none` | `intentions:read`1 | -1 Intention ACL rules are specified as part of a `service` rule. -See [Intention Management Permissions](/docs/connect/intentions.html#intention-management-permissions) for more details. ++ 1 Intention ACL rules are specified as part of a `service` rule. + See{' '} + + Intention Management Permissions + {' '} + for more details. +
### Parameters diff --git a/website/pages/api-docs/coordinate.html.md b/website/pages/api-docs/coordinate.mdx similarity index 99% rename from website/pages/api-docs/coordinate.html.md rename to website/pages/api-docs/coordinate.mdx index ffe485ce0..e64737adb 100644 --- a/website/pages/api-docs/coordinate.html.md +++ b/website/pages/api-docs/coordinate.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Coordinate - HTTP API +sidebar_title: 'Coordinates' sidebar_current: api-coordinate description: |- The /coordinate endpoints query for the network coordinates for nodes in the diff --git a/website/pages/api-docs/discovery-chain.html.md b/website/pages/api-docs/discovery-chain.mdx similarity index 98% rename from website/pages/api-docs/discovery-chain.html.md rename to website/pages/api-docs/discovery-chain.mdx index bfc9045b7..acff9f737 100644 --- a/website/pages/api-docs/discovery-chain.html.md +++ b/website/pages/api-docs/discovery-chain.mdx @@ -1,9 +1,9 @@ --- layout: api page_title: Discovery Chain - HTTP API +sidebar_title: 'Discovery Chain' sidebar_current: api-discovery-chain -description: |- - The /discovery-chain endpoints are for interacting with the discovery chain. +description: The /discovery-chain endpoints are for interacting with the discovery chain. --- -> **1.6.0+:** The discovery chain API is available in Consul versions 1.6.0 and newer. @@ -33,8 +33,11 @@ the `POST` method must be used, otherwise `GET` is sufficient. | `GET` | `/discovery-chain/:service` | `application/json` | | `POST`1 | `/discovery-chain/:service` | `application/json` | -1 Both GET and POST are for **read** operations. GET requests do not -permit request bodies so a POST is required if override parameters are needed. ++ 1 Both GET and POST are for read operations. GET + requests do not permit request bodies so a POST is required if override + parameters are needed. +
The table below shows this endpoint's support for [blocking queries](/api/features/blocking.html), diff --git a/website/pages/api-docs/event.html.md b/website/pages/api-docs/event.mdx similarity index 99% rename from website/pages/api-docs/event.html.md rename to website/pages/api-docs/event.mdx index a13a1cafa..b2027cd60 100644 --- a/website/pages/api-docs/event.html.md +++ b/website/pages/api-docs/event.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Events - HTTP API +sidebar_title: 'Events' sidebar_current: api-event description: |- The /event endpoints fire new events and to query the available events in diff --git a/website/pages/api-docs/features/blocking.html.md b/website/pages/api-docs/features/blocking.mdx similarity index 99% rename from website/pages/api-docs/features/blocking.html.md rename to website/pages/api-docs/features/blocking.mdx index 1b314aa15..ec8742896 100644 --- a/website/pages/api-docs/features/blocking.html.md +++ b/website/pages/api-docs/features/blocking.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Blocking Queries +sidebar_title: 'Blocking Queries' sidebar_current: api-features-blocking description: |- Many endpoints in Consul support a feature known as "blocking queries". A diff --git a/website/pages/api-docs/features/caching.html.md b/website/pages/api-docs/features/caching.mdx similarity index 99% rename from website/pages/api-docs/features/caching.html.md rename to website/pages/api-docs/features/caching.mdx index 1d77e3596..4b951d2d3 100644 --- a/website/pages/api-docs/features/caching.html.md +++ b/website/pages/api-docs/features/caching.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Agent Caching +sidebar_title: 'Agent Caching' sidebar_current: api-features-caching description: |- Some read endpoints support agent caching. They are clearly marked in the diff --git a/website/pages/api-docs/features/consistency.html.md b/website/pages/api-docs/features/consistency.mdx similarity index 91% rename from website/pages/api-docs/features/consistency.html.md rename to website/pages/api-docs/features/consistency.mdx index 695e4f562..51d223022 100644 --- a/website/pages/api-docs/features/consistency.html.md +++ b/website/pages/api-docs/features/consistency.mdx @@ -1,9 +1,13 @@ --- layout: api page_title: Consistency Modes +sidebar_title: 'API Features' sidebar_current: api-features-consistency -description: |- - Most of the read query endpoints support multiple levels of consistency. Since no policy will suit all clients' needs, these consistency modes allow the user to have the ultimate say in how to balance the trade-offs inherent in a distributed system. +description: >- + Most of the read query endpoints support multiple levels of consistency. Since + no policy will suit all clients' needs, these consistency modes allow the user + to have the ultimate say in how to balance the trade-offs inherent in a + distributed system. --- # Consistency Modes diff --git a/website/pages/api-docs/features/filtering.html.md b/website/pages/api-docs/features/filtering.mdx similarity index 99% rename from website/pages/api-docs/features/filtering.html.md rename to website/pages/api-docs/features/filtering.mdx index caccae200..de0164579 100644 --- a/website/pages/api-docs/features/filtering.html.md +++ b/website/pages/api-docs/features/filtering.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Filtering +sidebar_title: 'Filtering' sidebar_current: api-features-filtering description: |- Consul exposes a RESTful HTTP API to control almost every aspect of the diff --git a/website/pages/api-docs/features/index.mdx b/website/pages/api-docs/features/index.mdx new file mode 100644 index 000000000..384f5b678 --- /dev/null +++ b/website/pages/api-docs/features/index.mdx @@ -0,0 +1,7 @@ +--- +layout: api +page_title: API Features +sidebar_title: 'API Features' +--- + +Placeholder diff --git a/website/pages/api-docs/health.html.md b/website/pages/api-docs/health.mdx similarity index 99% rename from website/pages/api-docs/health.html.md rename to website/pages/api-docs/health.mdx index b7acee6d7..92cbf31c2 100644 --- a/website/pages/api-docs/health.html.md +++ b/website/pages/api-docs/health.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Health - HTTP API +sidebar_title: 'Health' sidebar_current: api-health description: |- The /health endpoints query health-related information for services and checks diff --git a/website/pages/api-docs/index.html.md b/website/pages/api-docs/index.mdx similarity index 98% rename from website/pages/api-docs/index.html.md rename to website/pages/api-docs/index.mdx index a17eadb13..30ea28659 100644 --- a/website/pages/api-docs/index.html.md +++ b/website/pages/api-docs/index.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: HTTP API +sidebar_title: 'API Introduction' sidebar_current: api-introduction description: |- Consul exposes a RESTful HTTP API to control almost every aspect of the diff --git a/website/pages/api-docs/kv.html.md b/website/pages/api-docs/kv.mdx similarity index 99% rename from website/pages/api-docs/kv.html.md rename to website/pages/api-docs/kv.mdx index 64f7be17b..73560980c 100644 --- a/website/pages/api-docs/kv.html.md +++ b/website/pages/api-docs/kv.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: KV Store - HTTP API +sidebar_title: 'KV Store' sidebar_current: api-kv-store description: |- The /kv endpoints access Consul's simple key/value store, useful for storing diff --git a/website/pages/api-docs/libraries-and-sdks.html.md b/website/pages/api-docs/libraries-and-sdks.mdx similarity index 56% rename from website/pages/api-docs/libraries-and-sdks.html.md rename to website/pages/api-docs/libraries-and-sdks.mdx index 71f82e134..e202c343c 100644 --- a/website/pages/api-docs/libraries-and-sdks.html.md +++ b/website/pages/api-docs/libraries-and-sdks.mdx @@ -1,6 +1,7 @@ --- layout: api page_title: Libraries and SDKs - HTTP API +sidebar_title: 'Libraries & SDKs' sidebar_current: api-libraries-and-sdks description: |- There are many third-party libraries for interacting with Consul's HTTP API. @@ -16,76 +17,112 @@ the community.
+ 1 For read-only transactions
+
+ 2 The ACL required depends on the operations in the transaction.
+
| Operation | -Version <= 0.6.3 | -Version > 0.6.3 | -
|---|---|---|
| Create static query without `Name` | -The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. | -No ACL policies are used as long as no `Name` is defined. No `Token` is captured by default unless specifically supplied by the client when creating the query. | -
| Create static query with `Name` | -The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. | -The client token's `query` ACL policy is used to determine if the client is allowed to register a query for the given `Name`. No `Token` is captured by default unless specifically supplied by the client when creating the query. | -
| Manage static query without `Name` | -The ACL Token used to create the query, or a management token must be supplied in order to perform these operations. | -Any client with the ID of the query can perform these operations. | -
| Manage static query with a `Name` | -The ACL token used to create the query, or a management token must be supplied in order to perform these operations. | -Similar to create, the client token's `query` ACL policy is used to determine if these operations are allowed. | -
| List queries | -A management token is required to list any queries. | -The client token's `query` ACL policy is used to determine which queries they can see. Only management tokens can see prepared queries without `Name`. | -
| Execute query | -Since a `Token` is always captured when a query is created, that is used to check access to the service being queried. Any token supplied by the client is ignored. | -The captured token, client's token, or anonymous token is used to filter the results, as described above. | -
| Operation | -Version <= 0.6.3 | -Version > 0.6.3 | -
|---|---|---|
| Create static query without `Name` | -The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. | -No ACL policies are used as long as no `Name` is defined. No `Token` is captured by default unless specifically supplied by the client when creating the query. | -
| Create static query with `Name` | -The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. | -The client token's `query` ACL policy is used to determine if the client is allowed to register a query for the given `Name`. No `Token` is captured by default unless specifically supplied by the client when creating the query. | -
| Manage static query without `Name` | -The ACL Token used to create the query or a token with management privileges must be supplied in order to perform these operations. | -Any client with the ID of the query can perform these operations. | -
| Manage static query with a `Name` | -The ACL token used to create the query or a token with management privileges must be supplied in order to perform these operations. | -Similar to create, the client token's `query` ACL policy is used to determine if these operations are allowed. | -
| List queries | -A token with management privileges is required to list any queries. | -The client token's `query` ACL policy is used to determine which queries they can see. Only tokens with management privileges can see prepared queries without `Name`. | -
| Execute query | -Since a `Token` is always captured when a query is created, that is used to check access to the service being queried. Any token supplied by the client is ignored. | -The captured token, client's token, or anonymous token is used to filter the results, as described above. | -
datacenter (required) - the name of the datacenter to auto-join in.
+-
+
+ datacenter
+ (required) - the name of the datacenter to auto-join in.
- `tag_value` (required) - the value of the tag to auto-join on.
- `username` (required) - the username to use for auth.
- `api_key` (required) - the api key to use for auth.
diff --git a/website/pages/docs/agent/config-entries/proxy-defaults.html.md b/website/pages/docs/agent/config-entries/proxy-defaults.mdx
similarity index 94%
rename from website/pages/docs/agent/config-entries/proxy-defaults.html.md
rename to website/pages/docs/agent/config-entries/proxy-defaults.mdx
index 6db5e35a5..e6d793529 100644
--- a/website/pages/docs/agent/config-entries/proxy-defaults.html.md
+++ b/website/pages/docs/agent/config-entries/proxy-defaults.mdx
@@ -1,9 +1,11 @@
---
-layout: 'docs'
+layout: docs
page_title: 'Configuration Entry Kind: Proxy Defaults'
-sidebar_current: 'docs-agent-cfg_entries-proxy_defaults'
-description: |-
- The proxy-defaults config entry kind allows for configuring global config defaults across all services for Connect proxy configuration. Currently, only one global entry is supported.
+sidebar_current: docs-agent-cfg_entries-proxy_defaults
+description: >-
+ The proxy-defaults config entry kind allows for configuring global config
+ defaults across all services for Connect proxy configuration. Currently, only
+ one global entry is supported.
---
# Proxy Defaults
diff --git a/website/pages/docs/agent/config-entries/service-defaults.html.md b/website/pages/docs/agent/config-entries/service-defaults.mdx
similarity index 96%
rename from website/pages/docs/agent/config-entries/service-defaults.html.md
rename to website/pages/docs/agent/config-entries/service-defaults.mdx
index 6a04f4b7a..e9456ffcc 100644
--- a/website/pages/docs/agent/config-entries/service-defaults.html.md
+++ b/website/pages/docs/agent/config-entries/service-defaults.mdx
@@ -1,9 +1,10 @@
---
-layout: 'docs'
+layout: docs
page_title: 'Configuration Entry Kind: Service Defaults'
-sidebar_current: 'docs-agent-cfg_entries-service_defaults'
-description: |-
- The service-defaults config entry kind controls default global values for a service, such as its protocol.
+sidebar_current: docs-agent-cfg_entries-service_defaults
+description: >-
+ The service-defaults config entry kind controls default global values for a
+ service, such as its protocol.
---
# Service Defaults
diff --git a/website/pages/docs/agent/config-entries/service-resolver.html.md b/website/pages/docs/agent/config-entries/service-resolver.mdx
similarity index 97%
rename from website/pages/docs/agent/config-entries/service-resolver.html.md
rename to website/pages/docs/agent/config-entries/service-resolver.mdx
index c5781c342..0259e1df5 100644
--- a/website/pages/docs/agent/config-entries/service-resolver.html.md
+++ b/website/pages/docs/agent/config-entries/service-resolver.mdx
@@ -1,9 +1,10 @@
---
-layout: 'docs'
+layout: docs
page_title: 'Configuration Entry Kind: Service Resolver'
-sidebar_current: 'docs-agent-cfg_entries-service_resolver'
-description: |-
- The `service-resolver` config entry kind controls which service instances should satisfy Connect upstream discovery requests for a given service name.
+sidebar_current: docs-agent-cfg_entries-service_resolver
+description: >-
+ The `service-resolver` config entry kind controls which service instances
+ should satisfy Connect upstream discovery requests for a given service name.
---
-> **1.6.0+:** This config entry is available in Consul versions 1.6.0 and newer.
diff --git a/website/pages/docs/agent/config-entries/service-router.html.md b/website/pages/docs/agent/config-entries/service-router.mdx
similarity index 98%
rename from website/pages/docs/agent/config-entries/service-router.html.md
rename to website/pages/docs/agent/config-entries/service-router.mdx
index d47ca4d31..d023b6b70 100644
--- a/website/pages/docs/agent/config-entries/service-router.html.md
+++ b/website/pages/docs/agent/config-entries/service-router.mdx
@@ -1,9 +1,10 @@
---
-layout: 'docs'
+layout: docs
page_title: 'Configuration Entry Kind: Service Router'
-sidebar_current: 'docs-agent-cfg_entries-service_router'
-description: |-
- The service-router config entry kind controls Connect traffic routing and manipulation at networking layer 7 (e.g. HTTP).
+sidebar_current: docs-agent-cfg_entries-service_router
+description: >-
+ The service-router config entry kind controls Connect traffic routing and
+ manipulation at networking layer 7 (e.g. HTTP).
---
-> **1.6.0+:** This config entry is available in Consul versions 1.6.0 and newer.
diff --git a/website/pages/docs/agent/config-entries/service-splitter.html.md b/website/pages/docs/agent/config-entries/service-splitter.mdx
similarity index 91%
rename from website/pages/docs/agent/config-entries/service-splitter.html.md
rename to website/pages/docs/agent/config-entries/service-splitter.mdx
index c744d0ff6..584600f77 100644
--- a/website/pages/docs/agent/config-entries/service-splitter.html.md
+++ b/website/pages/docs/agent/config-entries/service-splitter.mdx
@@ -1,9 +1,12 @@
---
-layout: 'docs'
+layout: docs
page_title: 'Configuration Entry Kind: Service Splitter'
-sidebar_current: 'docs-agent-cfg_entries-service_splitter'
-description: |-
- The service-splitter config entry kind controls how to split incoming Connect requests across different subsets of a single service (like during staged canary rollouts), or perhaps across different services (like during a v2 rewrite or other type of codebase migration).
+sidebar_current: docs-agent-cfg_entries-service_splitter
+description: >-
+ The service-splitter config entry kind controls how to split incoming Connect
+ requests across different subsets of a single service (like during staged
+ canary rollouts), or perhaps across different services (like during a v2
+ rewrite or other type of codebase migration).
---
-> **1.6.0+:** This config entry is available in Consul versions 1.6.0 and newer.
diff --git a/website/pages/docs/agent/config_entries.html.md b/website/pages/docs/agent/config_entries.mdx
similarity index 96%
rename from website/pages/docs/agent/config_entries.html.md
rename to website/pages/docs/agent/config_entries.mdx
index 404c770b0..7cf15f47d 100644
--- a/website/pages/docs/agent/config_entries.html.md
+++ b/website/pages/docs/agent/config_entries.mdx
@@ -1,9 +1,10 @@
---
-layout: 'docs'
-page_title: 'Configuration Entry Definitions'
-sidebar_current: 'docs-agent-cfg_entries'
-description: |-
- Consul allows storing configuration entries centrally to be used as defaults for configuring other aspects of Consul.
+layout: docs
+page_title: Configuration Entry Definitions
+sidebar_current: docs-agent-cfg_entries
+description: >-
+ Consul allows storing configuration entries centrally to be used as defaults
+ for configuring other aspects of Consul.
---
# Configuration Entries
diff --git a/website/pages/docs/agent/dns.html.md b/website/pages/docs/agent/dns.mdx
similarity index 95%
rename from website/pages/docs/agent/dns.html.md
rename to website/pages/docs/agent/dns.mdx
index 0c2bffbe3..d9684be69 100644
--- a/website/pages/docs/agent/dns.html.md
+++ b/website/pages/docs/agent/dns.mdx
@@ -1,9 +1,11 @@
---
-layout: 'docs'
-page_title: 'DNS Interface'
-sidebar_current: 'docs-agent-dns'
-description: |-
- One of the primary query interfaces for Consul is DNS. The DNS interface allows applications to make use of service discovery without any high-touch integration with Consul.
+layout: docs
+page_title: DNS Interface
+sidebar_current: docs-agent-dns
+description: >-
+ One of the primary query interfaces for Consul is DNS. The DNS interface
+ allows applications to make use of service discovery without any high-touch
+ integration with Consul.
---
# DNS Interface
@@ -48,7 +50,9 @@ To resolve names, Consul relies on a very specific format for queries.
There are fundamentally two types of queries: node lookups and service lookups.
A node lookup, a simple query for the address of a named node, looks like this:
- There are also a number of common configuration options supported by all providers:
- - - `csr_max_concurrent` Sets a limit - on how many Certificate Signing Requests will be processed - concurrently. Defaults to 0 (disabled). This is useful when you have - more than one or two cores available to the server. For example on an - 8 core server, setting this to 1 will ensure that even during a CA - rotation no more than one server core on the leader will be consumed - at a time with generating new certificates. Setting this is - recommended _instead_ of `csr_max_per_second` where you know there are - multiple cores available since it is simpler to reason about limiting - CSR resources this way without artificially slowing down rotations. - Added in 1.4.1. - - - `csr_max_per_second` Sets a rate - limit on the maximum number of Certificate Signing Requests (CSRs) the - servers will accept. This is used to prevent CA rotation from causing - unbounded CPU usage on servers. It defaults to 50 which is - conservative - a 2017 Macbook can process about 100 per second using - only ~40% of one CPU core - but sufficient for deployments up to ~1500 - service instances before the time it takes to rotate is impacted. For - larger deployments we recommend increasing this based on the expected - number of server instances and server resources, or use - `csr_max_concurrent` instead if servers have more than one core. - Setting this to zero disables rate limiting. Added in 1.4.1. - - - `leaf_cert_ttl` The upper bound on the - lease duration of a leaf certificate issued for a service. In most - cases a new leaf certificate will be requested by a proxy before this - limit is reached. This is also the effective limit on how long a - server outage can last (with no leader) before network connections - will start being rejected, and as a result the defaults is `72h` to - last through a weekend without intervention. This value cannot be - lower than 1 hour or higher than 1 year. - - This value is also used when rotating out old root certificates from - the cluster. When a root certificate has been inactive (rotated out) - for more than twice the _current_ `leaf_cert_ttl`, it will be removed - from the trusted list. - - - `private_key_type` The type of key to - generate for this CA. This is only used when the provider is - generating a new key. If `private_key` is set for the Consul provider, - or existing root or intermediate PKI paths given for Vault then this - will be ignored. Currently supported options are `ec` or `rsa`. - Default is `ec`. - - It is required that all servers in a Datacenter have - the same config for the CA. It is recommended that servers in - different Datacenters have the same CA config for key type and size - although the built-in CA and Vault provider will both allow mixed CA - key types. - - Some CA providers (currently Vault) will not allow cross-signing a - new CA certificate with a different key type. This means that if you - migrate from an RSA-keyed Vault CA to an EC-keyed CA from any - provider, you may have to proceed without cross-signing which risks - temporary connection issues for workloads during the new certificate - rollout. We highly recommend testing this outside of production to - understand the impact and suggest sticking to same key type where - possible. - - Note that this only affects _CA_ keys generated by the provider. - Leaf certificate keys are always EC 256 regardless of the CA - configuration. - - - `private_key_bits` The length of key - to generate for this CA. This is only used when the provider is - generating a new key. If `private_key` is set for the Consul provider, - or existing root or intermediate PKI paths given for Vault then this - will be ignored. - - Currently supported values are: - - - `private_key_type = ec` (default): `224, 256, 384, 521` - corresponding to the NIST P-\* curves of the same name. - - `private_key_type = rsa`: `2048, 4096` - -- `datacenter` Equivalent to the - [`-datacenter` command-line flag](#_datacenter). - -- `data_dir` Equivalent to the - [`-data-dir` command-line flag](#_data_dir). - -- - `disable_anonymous_signature` Disables providing an anonymous signature for de-duplication - with the update check. See [`disable_update_check`](#disable_update_check). - -- `disable_host_node_id` - Equivalent to the [`-disable-host-node-id` command-line flag](#_disable_host_node_id). - -- `disable_http_unprintable_char_filter` - Defaults to false. Consul 1.0.3 fixed a potential security vulnerability where - malicious users could craft KV keys with unprintable chars that would confuse - operators using the CLI or UI into taking wrong actions. Users who had data - written in older versions of Consul that did not have this restriction will be - unable to delete those values by default in 1.0.3 or later. This setting - enables those users to _temporarily_ disable the filter such that delete - operations can work on those keys again to get back to a healthy state. It is - strongly recommended that this filter is not disabled permanently as it - exposes the original security vulnerability. - -- `disable_remote_exec` - Disables support for remote execution. When set to true, the agent will ignore any incoming - remote exec requests. In versions of Consul prior to 0.8, this defaulted to false. In Consul - 0.8 the default was changed to true, to make remote exec opt-in instead of opt-out. - -- `disable_update_check` - Disables automatic checking for security bulletins and new version releases. This is disabled in - Consul Enterprise. - -- `discard_check_output` - Discards the output of health checks before storing them. This reduces the number of writes - to the Consul raft log in environments where health checks have volatile output like - timestamps, process ids, ... - -- `discovery_max_stale` - Enables - stale requests for all service discovery HTTP endpoints. This is equivalent to the - [`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service - discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server - can handle the service discovery request. If a Consul server is behind the leader by more than `discovery_max_stale`, - the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new - `X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale` - was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level, - and defaults to zero which matches default consistency behavior in earlier Consul versions. - -- `dns_config` This object allows a number - of sub-keys to be set which can tune how DNS queries are serviced. See this guide on - [DNS caching](https://learn.hashicorp.com/consul/security-networking/dns-caching) for more detail. - - The following sub-keys are available: - - - `allow_stale` - Enables a stale query - for DNS information. This allows any Consul server, rather than only the leader, to service - the request. The advantage of this is you get linear read scalability with Consul servers. - In versions of Consul prior to 0.7, this defaulted to false, meaning all requests are serviced - by the leader, providing stronger consistency but less throughput and higher latency. In Consul - 0.7 and later, this defaults to true for better utilization of available servers. - - - `max_stale` - When [`allow_stale`](#allow_stale) - is specified, this is used to limit how stale results are allowed to be. If a Consul server is - behind the leader by more than `max_stale`, the query will be re-evaluated on the leader to get - more up-to-date results. Prior to Consul 0.7.1 this defaulted to 5 seconds; in Consul 0.7.1 - and later this defaults to 10 years ("87600h") which effectively allows DNS queries to be answered - by any server, no matter how stale. In practice, servers are usually only milliseconds behind the - leader, so this lets Consul continue serving requests in long outage scenarios where no leader can - be elected. - - - `node_ttl` - By default, this is "0s", so all - node lookups are served with a 0 TTL value. DNS caching for node lookups can be enabled by - setting this value. This should be specified with the "s" suffix for second or "m" for minute. - - - `service_ttl` - This is a sub-object - which allows for setting a TTL on service lookups with a per-service policy. The "\*" wildcard - service can be used when there is no specific policy available for a service. By default, all - services are served with a 0 TTL value. DNS caching for service lookups can be enabled by - setting this value. - - - `enable_truncate` - If set to - true, a UDP DNS query that would return more than 3 records, or more than would fit into a valid - UDP response, will set the truncated flag, indicating to clients that they should re-query - using TCP to get the full set of records. - - - `only_passing` - If set to true, any - nodes whose health checks are warning or critical will be excluded from DNS results. If false, - the default, only nodes whose healthchecks are failing as critical will be excluded. For - service lookups, the health checks of the node itself, as well as the service-specific checks - are considered. For example, if a node has a health check that is critical then all services on - that node will be excluded because they are also considered critical. - - - `recursor_timeout` - Timeout used - by Consul when recursively querying an upstream DNS server. See `recursors` - for more details. Default is 2s. This is available in Consul 0.7 and later. - - - `disable_compression` - If - set to true, DNS responses will not be compressed. Compression was added and enabled by default - in Consul 0.7. - - - `udp_answer_limit` - Limit the number of - resource records contained in the answer section of a UDP-based DNS - response. This parameter applies only to UDP DNS queries that are less than 512 bytes. This setting is deprecated - and replaced in Consul 1.0.7 by `a_record_limit`. - - - `a_record_limit` - Limit the number of - resource records contained in the answer section of a A, AAAA or ANY DNS response (both TCP and UDP). - When answering a question, Consul will use the complete list of - matching hosts, shuffle the list randomly, and then limit the number of - answers to `a_record_limit` (default: no limit). This limit does not apply to SRV records. - - In environments where [RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9 - is implemented and enforced (i.e. DNS answers are always sorted and - therefore never random), clients may need to set this value to `1` to - preserve the expected randomized distribution behavior (note: - [RFC 3484](https://tools.ietf.org/html/rfc3484) has been obsoleted by - [RFC 6724](https://tools.ietf.org/html/rfc6724) and as a result it should - be increasingly uncommon to need to change this value with modern - resolvers). - - - `enable_additional_node_meta_txt` - - When set to true, Consul will add TXT records for Node metadata into the Additional section of the DNS responses for several - query types such as SRV queries. When set to false those records are not emitted. This does not impact the behavior of those - same TXT records when they would be added to the Answer section of the response like when querying with type TXT or ANY. This - defaults to true. - - - `soa` Allow to tune the setting set up in SOA. - Non specified values fallback to their default values, all values are integers and - expressed as seconds. -+ There are also a number of common configuration options supported by all + providers: +
+ + - + `csr_max_concurrent` Sets a limit on how + many Certificate Signing Requests will be processed concurrently. Defaults + to 0 (disabled). This is useful when you have more than one or two cores available + to the server. For example on an 8 core server, setting this to 1 will ensure + that even during a CA rotation no more than one server core on the leader will + be consumed at a time with generating new certificates. Setting this is recommended + _instead_ of `csr_max_per_second` where you know there are multiple cores available + since it is simpler to reason about limiting CSR resources this way without + artificially slowing down rotations. Added in 1.4.1. + + - + `csr_max_per_second` Sets a rate limit + on the maximum number of Certificate Signing Requests (CSRs) the servers will + accept. This is used to prevent CA rotation from causing unbounded CPU usage + on servers. It defaults to 50 which is conservative - a 2017 Macbook can process + about 100 per second using only ~40% of one CPU core - but sufficient for deployments + up to ~1500 service instances before the time it takes to rotate is impacted. + For larger deployments we recommend increasing this based on the expected number + of server instances and server resources, or use `csr_max_concurrent` instead + if servers have more than one core. Setting this to zero disables rate limiting. + Added in 1.4.1. + + - + `leaf_cert_ttl` The upper bound on the lease + duration of a leaf certificate issued for a service. In most cases a new leaf + certificate will be requested by a proxy before this limit is reached. This + is also the effective limit on how long a server outage can last (with no leader) + before network connections will start being rejected, and as a result the defaults + is `72h` to last through a weekend without intervention. This value cannot + be lower than 1 hour or higher than 1 year. + + This value is also used when rotating out old root certificates from + the cluster. When a root certificate has been inactive (rotated out) + for more than twice the _current_ `leaf_cert_ttl`, it will be removed + from the trusted list. + + - + `private_key_type` The type of key to generate + for this CA. This is only used when the provider is generating a new key. If + `private_key` is set for the Consul provider, or existing root or intermediate + PKI paths given for Vault then this will be ignored. Currently supported options + are `ec` or `rsa`. Default is `ec`. + + It is required that all servers in a Datacenter have + the same config for the CA. It is recommended that servers in + different Datacenters have the same CA config for key type and size + although the built-in CA and Vault provider will both allow mixed CA + key types. + + Some CA providers (currently Vault) will not allow cross-signing a + new CA certificate with a different key type. This means that if you + migrate from an RSA-keyed Vault CA to an EC-keyed CA from any + provider, you may have to proceed without cross-signing which risks + temporary connection issues for workloads during the new certificate + rollout. We highly recommend testing this outside of production to + understand the impact and suggest sticking to same key type where + possible. + + Note that this only affects _CA_ keys generated by the provider. + Leaf certificate keys are always EC 256 regardless of the CA + configuration. + + - + `private_key_bits` The length of key to + generate for this CA. This is only used when the provider is generating a new + key. If `private_key` is set for the Consul provider, or existing root or intermediate + PKI paths given for Vault then this will be ignored. + + Currently supported values are: + + - `private_key_type = ec` (default): `224, 256, 384, 521` + corresponding to the NIST P-\* curves of the same name. + - `private_key_type = rsa`: `2048, 4096` + +- + `datacenter` Equivalent to the [`-datacenter` command-line + flag](#_datacenter). + +- + `data_dir` Equivalent to the [`-data-dir` command-line + flag](#_data_dir). + +- + + `disable_anonymous_signature` + Disables providing an anonymous signature for de-duplication with the update + check. See [`disable_update_check`](#disable_update_check). + +- + `disable_host_node_id` + Equivalent to the [`-disable-host-node-id` command-line flag](#_disable_host_node_id). + +- + + `disable_http_unprintable_char_filter` + + Defaults to false. Consul 1.0.3 fixed a potential security vulnerability where + malicious users could craft KV keys with unprintable chars that would confuse operators + using the CLI or UI into taking wrong actions. Users who had data written in older + versions of Consul that did not have this restriction will be unable to delete + those values by default in 1.0.3 or later. This setting enables those users to + _temporarily_ disable the filter such that delete operations can work on those + keys again to get back to a healthy state. It is strongly recommended that this + filter is not disabled permanently as it exposes the original security vulnerability. + +- + `disable_remote_exec` + Disables support for remote execution. When set to true, the agent will ignore + any incoming remote exec requests. In versions of Consul prior to 0.8, this defaulted + to false. In Consul 0.8 the default was changed to true, to make remote exec opt-in + instead of opt-out. + +- + `disable_update_check` + Disables automatic checking for security bulletins and new version releases. This + is disabled in Consul Enterprise. + +- + `discard_check_output` + Discards the output of health checks before storing them. This reduces the number + of writes to the Consul raft log in environments where health checks have volatile + output like timestamps, process ids, ... + +- + `discovery_max_stale` - Enables stale requests + for all service discovery HTTP endpoints. This is equivalent to the [`max_stale`](#max_stale) + configuration for DNS requests. If this value is zero (default), all service discovery + HTTP endpoints are forwarded to the leader. If this value is greater than zero, + any Consul server can handle the service discovery request. If a Consul server + is behind the leader by more than `discovery_max_stale`, the query will be re-evaluated + on the leader to get more up-to-date results. Consul agents also add a new `X-Consul-Effective-Consistency` + response header which indicates if the agent did a stale read. `discover-max-stale` + was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests + from clients at the agent level, and defaults to zero which matches default consistency + behavior in earlier Consul versions. + +- + `dns_config` This object allows a number of sub-keys + to be set which can tune how DNS queries are serviced. See this guide on [DNS caching](https://learn.hashicorp.com/consul/security-networking/dns-caching) + for more detail. + + The following sub-keys are available: + + - + `allow_stale` - Enables a stale query for DNS information. + This allows any Consul server, rather than only the leader, to service the request. + The advantage of this is you get linear read scalability with Consul servers. + In versions of Consul prior to 0.7, this defaulted to false, meaning all requests + are serviced by the leader, providing stronger consistency but less throughput + and higher latency. In Consul 0.7 and later, this defaults to true for better + utilization of available servers. + + - + `max_stale` - When [`allow_stale`](#allow_stale) is + specified, this is used to limit how stale results are allowed to be. If a Consul + server is behind the leader by more than `max_stale`, the query will be re-evaluated + on the leader to get more up-to-date results. Prior to Consul 0.7.1 this defaulted + to 5 seconds; in Consul 0.7.1 and later this defaults to 10 years ("87600h") + which effectively allows DNS queries to be answered by any server, no matter + how stale. In practice, servers are usually only milliseconds behind the leader, + so this lets Consul continue serving requests in long outage scenarios where + no leader can be elected. + + - + `node_ttl` - By default, this is "0s", so all node lookups + are served with a 0 TTL value. DNS caching for node lookups can be enabled by + setting this value. This should be specified with the "s" suffix for second or + "m" for minute. + + - + `service_ttl` - This is a sub-object which allows + for setting a TTL on service lookups with a per-service policy. The "\*" wildcard + service can be used when there is no specific policy available for a service. + By default, all services are served with a 0 TTL value. DNS caching for service + lookups can be enabled by setting this value. + + - + `enable_truncate` - If set to true, a UDP DNS + query that would return more than 3 records, or more than would fit into a valid + UDP response, will set the truncated flag, indicating to clients that they should + re-query using TCP to get the full set of records. + + - + `only_passing` - If set to true, any nodes whose + health checks are warning or critical will be excluded from DNS results. If false, + the default, only nodes whose healthchecks are failing as critical will be excluded. + For service lookups, the health checks of the node itself, as well as the service-specific + checks are considered. For example, if a node has a health check that is critical + then all services on that node will be excluded because they are also considered + critical. + + - + `recursor_timeout` - Timeout used by Consul when + recursively querying an upstream DNS server. See + `recursors` + + for more details. Default is 2s. This is available in Consul 0.7 and later. + + - + `disable_compression` - If set to true, DNS + responses will not be compressed. Compression was added and enabled by default + in Consul 0.7. + + - + `udp_answer_limit` - Limit the number of resource + records contained in the answer section of a UDP-based DNS response. This parameter + applies only to UDP DNS queries that are less than 512 bytes. This setting is + deprecated and replaced in Consul 1.0.7 by + `a_record_limit` + + . + + - + `a_record_limit` - Limit the number of resource + records contained in the answer section of a A, AAAA or ANY DNS response (both + TCP and UDP). When answering a question, Consul will use the complete list of + matching hosts, shuffle the list randomly, and then limit the number of answers + to `a_record_limit` (default: no limit). This limit does not apply to SRV records. + + In environments where [RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9 + is implemented and enforced (i.e. DNS answers are always sorted and + therefore never random), clients may need to set this value to `1` to + preserve the expected randomized distribution behavior (note: + [RFC 3484](https://tools.ietf.org/html/rfc3484) has been obsoleted by + [RFC 6724](https://tools.ietf.org/html/rfc6724) and as a result it should + be increasingly uncommon to need to change this value with modern + resolvers). + + - + + `enable_additional_node_meta_txt` + - When set to true, Consul will add TXT records for Node metadata into the + Additional section of the DNS responses for several query types such as SRV queries. + When set to false those records are not emitted. This does not impact the behavior + of those same TXT records when they would be added to the Answer section of the + response like when querying with type TXT or ANY. This defaults to true. + + - + `soa` Allow to tune the setting set up in SOA. Non specified + values fallback to their default values, all values are integers and expressed + as seconds. +| Metric | -Description | -Unit | -Type | -
|---|---|---|---|
| `consul.acl.blocked.service.registration` | -This increments whenever a deregistration fails for a service (blocked by an ACL) | -requests | -counter | -
| `consul.acl.blocked. |
- This increments whenever a registration fails for an entity (check, node or service) is blocked by an ACL | -requests | -counter | -
| `consul.client.rpc` | -This increments whenever a Consul agent in client mode makes an RPC request to a Consul server. This gives a measure of how much a given agent is loading the Consul servers. Currently, this is only generated by agents in client mode, not Consul servers. | -requests | -counter | -
| `consul.client.rpc.exceeded` | -This increments whenever a Consul agent in client mode makes an RPC request to a Consul server gets rate limited by that agent's [`limits`](/docs/agent/options.html#limits) configuration. This gives an indication that there's an abusive application making too many requests on the agent, or that the rate limit needs to be increased. Currently, this only applies to agents in client mode, not Consul servers. | -rejected requests | -counter | -
| `consul.client.rpc.failed` | -This increments whenever a Consul agent in client mode makes an RPC request to a Consul server and fails. | -requests | -counter | -
| `consul.client.api.catalog_register. |
- This increments whenever a Consul agent receives a catalog register request. | -requests | -counter | -
| `consul.client.api.success.catalog_register. |
- This increments whenever a Consul agent successfully responds to a catalog register request. | -requests | -counter | -
| `consul.client.rpc.error.catalog_register. |
- This increments whenever a Consul agent receives an RPC error for a catalog register request. | -errors | -counter | -
| `consul.client.api.catalog_deregister. |
- This increments whenever a Consul agent receives a catalog de-register request. | -requests | -counter | -
| `consul.client.api.success.catalog_deregister. |
- This increments whenever a Consul agent successfully responds to a catalog de-register request. | -requests | -counter | -
| `consul.client.rpc.error.catalog_deregister. |
- This increments whenever a Consul agent receives an RPC error for a catalog de-register request. | -errors | -counter | -
| `consul.client.api.catalog_datacenters. |
- This increments whenever a Consul agent receives a request to list datacenters in the catalog. | -requests | -counter | -
| `consul.client.api.success.catalog_datacenters. |
- This increments whenever a Consul agent successfully responds to a request to list datacenters. | -requests | -counter | -
| `consul.client.rpc.error.catalog_datacenters. |
- This increments whenever a Consul agent receives an RPC error for a request to list datacenters. | -errors | -counter | -
| `consul.client.api.catalog_nodes. |
- This increments whenever a Consul agent receives a request to list nodes from the catalog. | -requests | -counter | -
| `consul.client.api.success.catalog_nodes. |
- This increments whenever a Consul agent successfully responds to a request to list nodes. | -requests | -counter | -
| `consul.client.rpc.error.catalog_nodes. |
- This increments whenever a Consul agent receives an RPC error for a request to list nodes. | -errors | -counter | -
| `consul.client.api.catalog_services. |
- This increments whenever a Consul agent receives a request to list services from the catalog. | -requests | -counter | -
| `consul.client.api.success.catalog_services. |
- This increments whenever a Consul agent successfully responds to a request to list services. | -requests | -counter | -
| `consul.client.rpc.error.catalog_services. |
- This increments whenever a Consul agent receives an RPC error for a request to list services. | -errors | -counter | -
| `consul.client.api.catalog_service_nodes. |
- This increments whenever a Consul agent receives a request to list nodes offering a service. | -requests | -counter | -
| `consul.client.api.success.catalog_service_nodes. |
- This increments whenever a Consul agent successfully responds to a request to list nodes offering a service. | -requests | -counter | -
| `consul.client.rpc.error.catalog_service_nodes. |
- This increments whenever a Consul agent receives an RPC error for a request to list nodes offering a service. | -errors | -counter | -
| `consul.client.api.catalog_node_services. |
- This increments whenever a Consul agent receives a request to list services registered in a node. | -requests | -counter | -
| `consul.client.api.success.catalog_node_services. |
- This increments whenever a Consul agent successfully responds to a request to list services in a service. | -requests | -counter | -
| `consul.client.rpc.error.catalog_node_services. |
- This increments whenever a Consul agent receives an RPC error for a request to list services in a service. | -errors | -counter | -
| `consul.runtime.num_goroutines` | -This tracks the number of running goroutines and is a general load pressure indicator. This may burst from time to time but should return to a steady state value. | -number of goroutines | -gauge | -
| `consul.runtime.alloc_bytes` | -This measures the number of bytes allocated by the Consul process. This may burst from time to time but should return to a steady state value. | -bytes | -gauge | -
| `consul.runtime.heap_objects` | -This measures the number of objects allocated on the heap and is a general memory pressure indicator. This may burst from time to time but should return to a steady state value. | -number of objects | -gauge | -
| `consul.acl.cache_hit` | -The number of ACL cache hits. | -hits | -counter | -
| `consul.acl.cache_miss` | -The number of ACL cache misses. | -misses | -counter | -
| `consul.acl.replication_hit` | -The number of ACL replication cache hits (when not running in the ACL datacenter). | -hits | -counter | -
| `consul.dns.stale_queries` | -This increments when an agent serves a query within the allowed stale threshold. | -queries | -counter | -
| `consul.dns.ptr_query. |
- This measures the time spent handling a reverse DNS query for the given node. | -ms | -timer | -
| `consul.dns.domain_query. |
- This measures the time spent handling a domain query for the given node. | -ms | -timer | -
| `consul.http. |
- This tracks how long it takes to service the given HTTP request for the given verb and path. Paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`) | -ms | -timer | -
| Metric | -Description | -Unit | -Type | -
|---|---|---|---|
| `consul.memberlist.degraded.probe` | -This metric counts the number of times the agent has performed failure detection on another agent at a slower probe rate. The agent uses its own health metric as an indicator to perform this action. (If its health score is low, means that the node is healthy, and vice versa.) | -probes / interval | -counter | -
| `consul.memberlist.degraded.timeout` | -This metric counts the number of times an agent was marked as a dead node, whilst not getting enough confirmations from a randomly selected list of agent nodes in an agent's membership. | -occurrence / interval | -counter | -
| `consul.memberlist.msg.dead` | -This metric counts the number of times an agent has marked another agent to be a dead node. | -messages / interval | -counter | -
| `consul.memberlist.health.score` | -This metric describes a node's perception of its own health based on how well it is meeting the soft real-time requirements of the protocol. This metric ranges from 0 to 8, where 0 indicates "totally healthy". This health score is used to scale the time between outgoing probes, and higher scores translate into longer probing intervals. For more details see section IV of the Lifeguard paper: https://arxiv.org/pdf/1707.00788.pdf | -score | -gauge | -
| `consul.memberlist.msg.suspect` | -This increments when an agent suspects another as failed when executing random probes as part of the gossip protocol. These can be an indicator of overloaded agents, network problems, or configuration errors where agents can not connect to each other on the [required ports](/docs/agent/options.html#ports). | -suspect messages received / interval | -counter | -
| `consul.memberlist.tcp.accept` | -This metric counts the number of times an agent has accepted an incoming TCP stream connection. | -connections accepted / interval | -counter | -
| `consul.memberlist.udp.sent/received` | -This metric measures the total number of bytes sent/received by an agent through the UDP protocol. | -bytes sent or bytes received / interval | -counter | -
| `consul.memberlist.tcp.connect` | -This metric counts the number of times an agent has initiated a push/pull sync with an other agent. | -push/pull initiated / interval | -counter | -
| `consul.memberlist.tcp.sent` | -This metric measures the total number of bytes sent by an agent through the TCP protocol | -bytes sent / interval | -counter | -
| `consul.memberlist.gossip` | -This metric gives the number of gossips (messages) broadcasted to a set of randomly selected nodes. | -messages / Interval | -counter | -
| `consul.memberlist.msg_alive` | -This metric counts the number of alive agents, that the agent has mapped out so far, based on the message information given by the network layer. | -nodes / Interval | -counter | -
| `consul.memberlist.msg_dead` | -This metric gives the number of dead agents, that the agent has mapped out so far, based on the message information given by the network layer. | -nodes / Interval | -counter | -
| `consul.memberlist.msg_suspect` | -This metric gives the number of suspect nodes, that the agent has mapped out so far, based on the message information given by the network layer. | -nodes / Interval | -counter | -
| `consul.memberlist.probeNode` | -This metric measures the time taken to perform a single round of failure detection on a select agent. | -nodes / Interval | -counter | -
| `consul.memberlist.pushPullNode` | -This metric measures the number of agents that have exchanged state with this agent. | -nodes / Interval | -counter | -
| `consul.serf.member.failed` | -This increments when an agent is marked dead. This can be an indicator of overloaded agents, network problems, or configuration errors where agents cannot connect to each other on the [required ports](/docs/agent/options.html#ports). | -failures / interval | -counter | -
| `consul.serf.member.flap` | -Available in Consul 0.7 and later, this increments when an agent is marked dead and then recovers within a short time period. This can be an indicator of overloaded agents, network problems, or configuration errors where agents cannot connect to each other on the [required ports](/docs/agent/options.html#ports). | -flaps / interval | -counter | -
| `consul.serf.member.join` | -This increments when an agent joins the cluster. If an agent flapped or failed this counter also increments when it re-joins. | -joins / interval | -counter | -
| `consul.serf.member.left` | -This increments when an agent leaves the cluster. | -leaves / interval | -counter | -
| `consul.serf.events` | -This increments when an agent processes an [event](/docs/commands/event.html). Consul uses events internally so there may be additional events showing in telemetry. There are also a per-event counters emitted as `consul.serf.events. |
- events / interval | -counter | -
| `consul.autopilot.failure_tolerance` | -This tracks the number of voting servers that the cluster can lose while continuing to function. | -servers | -gauge | -
| `consul.autopilot.healthy` | -This tracks the overall health of the local server cluster. If all servers are considered healthy by Autopilot, this will be set to 1. If any are unhealthy, this will be 0. | -boolean | -gauge | -
| `consul.session_ttl.active` | -This tracks the active number of sessions being tracked. | -sessions | -gauge | -
| `consul.catalog.service.query. |
- This increments for each catalog query for the given service. | -queries | -counter | -
| `consul.catalog.service.query-tag. |
- This increments for each catalog query for the given service with the given tag. | -queries | -counter | -
| `consul.catalog.service.query-tags. |
- This increments for each catalog query for the given service with the given tags. | -queries | -counter | -
| `consul.catalog.service.not-found. |
- This increments for each catalog query where the given service could not be found. | -queries | -counter | -
| `consul.health.service.query. |
- This increments for each health query for the given service. | -queries | -counter | -
| `consul.health.service.query-tag. |
- This increments for each health query for the given service with the given tag. | -queries | -counter | -
| `consul.health.service.query-tags. |
- This increments for each health query for the given service with the given tags. | -queries | -counter | -
| `consul.health.service.not-found. |
- This increments for each health query where the given service could not be found. | -queries | -counter | -
| Metric | -Description | -Unit | -Type | -
|---|---|---|---|
| `consul.proxy.web.runtime.*` | -The same go runtime metrics as documented for the agent above. | -mixed | -mixed | -
| `consul.proxy.web.inbound.conns` | -Shows the current number of connections open from inbound requests to - the proxy. Where supported a `dst` label is added indicating the - service name the proxy represents. | -connections | -gauge | -
| `consul.proxy.web.inbound.rx_bytes` | -This increments by the number of bytes received from an inbound client - connection. Where supported a `dst` label is added indicating the - service name the proxy represents. | -bytes | -counter | -
| `consul.proxy.web.inbound.tx_bytes` | -This increments by the number of bytes transferred to an inbound client - connection. Where supported a `dst` label is added indicating the - service name the proxy represents. | -bytes | -counter | -
| `consul.proxy.web.upstream.conns` | -Shows the current number of connections open from a proxy instance to an - upstream. Where supported a `src` label is added indicating the - service name the proxy represents, and a `dst` label is added indicating the - service name the upstream is connecting to. | -connections | -gauge | -
| `consul.proxy.web.inbound.rx_bytes` | -This increments by the number of bytes received from an upstream - connection. Where supported a `src` label is added indicating the - service name the proxy represents, and a `dst` label is added indicating the - service name the upstream is connecting to. | -bytes | -counter | -
| `consul.proxy.web.inbound.tx_bytes` | -This increments by the number of bytes transferred to an upstream - connection. Where supported a `src` label is added indicating the - service name the proxy represents, and a `dst` label is added indicating the - service name the upstream is connecting to. | -bytes | -counter | -