[DOCS-13310] Cross-link load balancer health check guidance

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 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

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] 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.
@@ -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