diff --git a/changelog/v1.19.0-beta10/docs-ai-gw.yaml b/changelog/v1.19.0-beta10/docs-ai-gw.yaml new file mode 100644 index 00000000000..9623cd17713 --- /dev/null +++ b/changelog/v1.19.0-beta10/docs-ai-gw.yaml @@ -0,0 +1,5 @@ +changelog: + - type: NON_USER_FACING + resolvesIssue: true + description: >- + Weekly doc fixes and minor updates. \ No newline at end of file diff --git a/docs/content/guides/security/access_logging/_index.md b/docs/content/guides/security/access_logging/_index.md index e3c21d8fd58..117b68a2800 100644 --- a/docs/content/guides/security/access_logging/_index.md +++ b/docs/content/guides/security/access_logging/_index.md @@ -411,14 +411,14 @@ You can apply different filters on your access logs to reduce and optimize the n ### Using status code filters -You can apply access log filters to requests that match a specific HTTP status code by using the `defaultValue` or `runtimeKey` option. +You can apply access log filters to requests that match a specific HTTP status code by using the `defaultValue` and `runtimeKey` option. **Option 1: Use `defaultValue`**
Use the `defaultValue` option in the Gateway resource to specify the HTTP status code for which you want to apply the access log filter. Note that the `defaultValue` is set for a specific Gateway only. To apply the same HTTP status code to multiple Gateway resources, see `Option 2: Override the default value with a runtime key-value pair`. 1. Follow the steps in [File-based](#file-based-access-logging) or [gRPC](#grpc-access-logging) access logging to enable access logging for your gateway. -2. To apply additional filters to your access logs, you create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to 400. +2. To apply additional filters to your access logs, you create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to 400. Note that the `runtimeKey` overrides any settings in `defaultValue`, so in this example, the `runtimeKey` is also set to 400. ```yaml apiVersion: gateway.solo.io/v1 kind: Gateway @@ -445,6 +445,7 @@ Use the `defaultValue` option in the Gateway resource to specify the HTTP status op: GE value: defaultValue: 400 + runtimeKey: "400" proxyNames: - gateway-proxy ssl: false @@ -467,7 +468,7 @@ Note that the `runtimeKey` is enforced only if it matches a key that is defined 3. Create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to what is defined in the `access_log_status_filter` runtime value. {{% notice note %}} - Note that the `runtimeKey` overrides any settings in `defaultValue` + Note that the `runtimeKey` overrides any settings in `defaultValue`. {{% /notice %}} ```yaml diff --git a/docs/content/guides/traffic_management/request_processing/upstream_health_checks/_index.md b/docs/content/guides/traffic_management/request_processing/upstream_health_checks/_index.md index 4b16b53ae00..c1d595d989d 100644 --- a/docs/content/guides/traffic_management/request_processing/upstream_health_checks/_index.md +++ b/docs/content/guides/traffic_management/request_processing/upstream_health_checks/_index.md @@ -4,20 +4,21 @@ weight: 50 description: Automatically monitor the status of Upstreams by configuring health checks for them --- -As part of configuring an Upstream, Gloo Gateway provides the option of adding *health checks* that periodically assess the readiness of the Upstream to receive requests. See the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/v1.14.1/intro/arch_overview/upstream/health_checking#arch-overview-health-checking) for more information. +As part of configuring an Upstream, Gloo Gateway provides the option of adding *health checks* that periodically assess the readiness of the Upstream to receive requests. For more information, see the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/v1.14.1/intro/arch_overview/upstream/health_checking#arch-overview-health-checking). {{% notice note %}} -Upstreams with working health checks will not be removed from Envoy's service directory, even due to configuration changes. To allow them to be removed, set `ignoreHealthOnHostRemoval` in the Upstream's configuration. +Upstreams with working health checks are not removed from Envoy's service directory, even due to configuration changes. To allow removal in such cases, set `ignoreHealthOnHostRemoval` in the Upstream's configuration. {{% /notice %}} + ## Configuration -Descriptions of the options available for configuring health checks can be found {{< protobuf name="solo.io.envoy.api.v2.core.HealthCheck" display="here" >}}. +Review the following sections for example configuration settings of common use cases. For descriptions of each field, refer to the [API documentation]({{% versioned_link_path fromRoot="/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/options/healthcheck/healthcheck.proto.sk/" %}}). ### Custom paths for HttpHealthChecks -There is a way to add custom paths to health check requests shown in the example below. +To add custom paths to health check requests, review the following example. -{{< highlight yaml >}} +```yaml spec: healthChecks: - healthyThreshold: 1 @@ -26,6 +27,12 @@ spec: interval: 30s timeout: 10s unhealthyThreshold: 1 -{{< /highlight >}} +``` -A `path` represents an explicitly-specified path to check the health of the upstream. The `timeout` declares how much time between checks there should be. An `unhealthyThreshold` is the limit of checks that are allowed to fail before declaring the upstream unhealthy. A `healthyThreshold` is the limit of checks that are allowed to pass before declaring an upstream healthy. The `interval` is the interval of time that you send `healthchecks` as to not overload your upstream service. +| Setting | Description | +| --- | --- | +| `path` | The specific path to send the health check request to the upstream. Make sure that the backing destination handles health checks along this path. | +| `timeout` | The amount of time that the health check waits for a response before considering the request unsuccessful and timing out. | +| `unhealthyThreshold` | The number of checks that can fail before the upstream is considered unhealthy. The example allows only one failed health check. | +| `healthyThreshold` | The number of checks that must succeed before an upstream is considered healthy. The example requires only one successful health check. +| `interval` | How often the health check sends requests. Set a value that will not overload your upstream service. | diff --git a/docs/content/operations/production_deployment/_index.md b/docs/content/operations/production_deployment/_index.md index e4dfb9b8bad..ab44e070301 100644 --- a/docs/content/operations/production_deployment/_index.md +++ b/docs/content/operations/production_deployment/_index.md @@ -214,7 +214,7 @@ global: extAuth: signingKey: name: extauth-signing-key - signing-key: + key: ``` #### Pod Disruption Budgets and Affinity/Anti-Affinity rules diff --git a/docs/content/reference/api/_index.md b/docs/content/reference/api/_index.md index 87d408f1a63..868f2b16e96 100644 --- a/docs/content/reference/api/_index.md +++ b/docs/content/reference/api/_index.md @@ -19,7 +19,7 @@ Gloo Edge is a high-performance, plugin-extendable, platform-agnostic API Gatewa Gateway - Gateway: {{< protobuf name="gateway.solo.io.Gateway" >}} - HTTPGateway: {{< protobuf name="gateway.solo.io.HttpGateway" >}} -- HTTPListenerOptions: {{< protobuf name="gloo.solo.io.HTTPListenerOptions" >}} +- HTTPListenerOptions: {{< protobuf name="gloo.solo.io.HttpListenerOptions" >}} - ListenerOptions: {{< protobuf name="gloo.solo.io.ListenerOptions" >}} - TCPGateway: {{< protobuf name="gateway.solo.io.TcpGateway" >}}