From 4641eab54999fb7a1fd5c2d1c2909fd6ddb82671 Mon Sep 17 00:00:00 2001 From: May Lee Date: Thu, 20 Aug 2026 16:33:51 -0400 Subject: [PATCH 1/2] [DOCS-13310] Cross-link load balancer health check guidance for VM-based Workers Link the load balancer health check recommendation in the scaling guide to the existing health check endpoint setup steps, and add a reverse link back. Also clarify that the default Kubernetes probes use a TCP socket check rather than the /health endpoint. --- .../install_the_worker/advanced_worker_configurations.md | 5 +++-- .../best_practices_for_scaling_observability_pipelines.md | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md index b11b7325e40..743eeb34290 100644 --- a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md +++ b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md @@ -104,9 +104,9 @@ Use the `VECTOR_HOSTNAME` environment variable to assign a unique hostname and h ## Enable the health check endpoint and the liveness and readiness probes -Configure your load balancer's health check with the `/health` endpoint to check that the Worker is up and running. +Configure your load balancer's health check with the `/health` endpoint to check that the Worker is up and running. See [Load balancer configurations][13] for more recommendations on setting up a load balancer in front of the Worker. -For Kubernetes, the liveness and readiness probes are already enabled in the [helm chart][9] and [values.yaml][10] file. +For Kubernetes, the liveness and readiness probes are already enabled in the [helm chart][9] and [values.yaml][10] file. By default, these probes check a TCP socket on the Worker API port instead of the `/health` endpoint. For other installations such as VM-based ones, you must set `DD_OP_API_ENABLED` to `true` and set `DD_OP_API_ADDRESS` to `0.0.0.0:8686` to expose the `/health` endpoint. An example configuration: @@ -132,3 +132,4 @@ api: [10]: https://github.com/DataDog/helm-charts/blob/main/charts/observability-pipelines-worker/values.yaml#L303-L329 [11]: /remote_configuration/#security-considerations [12]: /observability_pipelines/configuration/secrets_management/ +[13]: /observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines/#load-balancer-configurations diff --git a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md index 6d09e5a5831..fd15bc66e76 100644 --- a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md +++ b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md @@ -185,7 +185,7 @@ When configuring clients and load balancers, Datadog recommends the following ge - Use a simple round-robin load balancing strategy. - Do not enable cross-zone load balancing unless the traffic across zones is very imbalanced. -- Configure load balancers to use Observability Pipelines Worker's health API endpoint for target health. +- Configure load balancers to use Observability Pipelines Worker's health API endpoint for target health. See [Enable the health check endpoint and the liveness and readiness probes][11] to set up the `/health` endpoint. - Ensure that your Observability Pipelines Worker instances automatically register or de-register as they scale. - Enable keep-alive with no more than one minute idle timeout for both your clients and load balancers. - If supported, enable connection concurrency and pooling on your agents. If that is not supported, consider the unified architecture which deploys Observability Pipelines Worker at the edge. Connection pooling ensures large volumes of data are spread across multiple connections to help balance traffic. @@ -227,3 +227,4 @@ Auto-scaling should be based on average CPU utilization. For the vast majority o [8]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html [9]: https://www.datadoghq.com/architecture/op-vm-deployment/ [10]: https://www.datadoghq.com/architecture/observability-pipelines-kubernetes-deployment/ +[11]: /observability_pipelines/configuration/install_the_worker/advanced_worker_configurations/#enable-the-health-check-endpoint-and-the-liveness-and-readiness-probes From a38a3c37b682f35ce82c1347accdec55a95aa2e9 Mon Sep 17 00:00:00 2001 From: May Lee Date: Thu, 20 Aug 2026 16:39:19 -0400 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: May Lee --- .../install_the_worker/advanced_worker_configurations.md | 2 +- .../best_practices_for_scaling_observability_pipelines.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md index 743eeb34290..129725d66f5 100644 --- a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md +++ b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md @@ -106,7 +106,7 @@ Use the `VECTOR_HOSTNAME` environment variable to assign a unique hostname and h Configure your load balancer's health check with the `/health` endpoint to check that the Worker is up and running. See [Load balancer configurations][13] for more recommendations on setting up a load balancer in front of the Worker. -For Kubernetes, the liveness and readiness probes are already enabled in the [helm chart][9] and [values.yaml][10] file. By default, these probes check a TCP socket on the Worker API port instead of the `/health` endpoint. +For Kubernetes, the liveness and readiness probes are enabled in the [helm chart][9] and [values.yaml][10] file by default. These probes check a TCP socket on the Worker API port instead of the `/health` endpoint. For other installations such as VM-based ones, you must set `DD_OP_API_ENABLED` to `true` and set `DD_OP_API_ADDRESS` to `0.0.0.0:8686` to expose the `/health` endpoint. An example configuration: diff --git a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md index fd15bc66e76..d6085b1486f 100644 --- a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md +++ b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md @@ -185,7 +185,7 @@ When configuring clients and load balancers, Datadog recommends the following ge - Use a simple round-robin load balancing strategy. - Do not enable cross-zone load balancing unless the traffic across zones is very imbalanced. -- Configure load balancers to use Observability Pipelines Worker's health API endpoint for target health. See [Enable the health check endpoint and the liveness and readiness probes][11] to set up the `/health` endpoint. +- Configure load balancers to use Observability Pipelines Worker's health API endpoint for target health. See [Enable the health check endpoint and the liveness and readiness probes][11] for more information. - Ensure that your Observability Pipelines Worker instances automatically register or de-register as they scale. - Enable keep-alive with no more than one minute idle timeout for both your clients and load balancers. - If supported, enable connection concurrency and pooling on your agents. If that is not supported, consider the unified architecture which deploys Observability Pipelines Worker at the edge. Connection pooling ensures large volumes of data are spread across multiple connections to help balance traffic.