The Relay Proxy exposes a status resource containing details about its health. To learn about the status resource, read the Relay Proxy GitHub repository’s Status (health check).
Fluctuating network conditions can cause a temporary loss of connection. The Relay proxy is self-healing and will re-establish connectivity with LaunchDarkly automatically.You can check your Relay Proxy configuration using status requests and flag evaluation tests.
You can make a GET request to the /status URL path for information about the Relay Proxy’s configured environments. There is no authentication required for this request.Here’s how:
curl -X GET localhost:8030/status \
To view an example output for this request, read the Relay Proxy GitHub repository’s Service endpoints.In version 9.0 and later, you can also request the status of a single environment at /status/{identifier}. The identifier is the environment’s configured name or its environment ID. With automatic configuration, you can also use /status/{projKey}/{envKey}.
In version 9.0 and later, every status route accepts an expect query parameter. Each expect clause names a field in the response, a comparison, and an expected value. The Relay Proxy responds with a 200 status code if every clause is true, and a 412 status code if any clause is false. A load balancer, a Kubernetes probe, or a monitoring script can check health from the status code, without parsing the JSON response.Here are some examples:
# Is the whole Relay Proxy healthy?curl -fsS 'http://localhost:8030/status?expect=status=healthy'# Is the environment named Production connected?curl -fsS 'http://localhost:8030/status/Production?expect=status=connected'
The Relay Proxy Docker images have no shell, so health checks must use HTTP. Use a Kubernetes httpGet probe instead of an exec probe.Don’t base a readiness probe on expect=status=healthy. The top-level status becomes degraded when an environment stays disconnected for longer than disconnectedStatusTime, which defaults to one minute. During a LaunchDarkly outage, every pod would fail the probe and leave the Kubernetes Service at once, even though each pod can still serve the flag data it already has. Instead, check only that startup has finished.Here is a readiness probe that marks a pod ready when the Relay Proxy has at least one environment and no environment is still initializing:
The autoConfigStatus clause applies only to automatic configuration. If you use manual configuration, remove that clause, because the field is absent and the probe would always fail. To learn more about expect clauses, read the Relay Proxy GitHub repository’s Health assertions.
If your environment configurations are valid, you can check your connection by evaluating a feature flag.Here’s how to test your connection and evaluate a flag:
Start your SDK. If the SDK connects successfully, the Relay Proxy is working.
Look for connection or environment-related errorsError messages on initialization, including messages saying an environment was not found, may indicate that you configured the Relay Proxy incorrectly. These messages may appear when LaunchDarkly cannot validate an SDK key or when there is a connection issue to LaunchDarkly.
In the LaunchDarkly user interface (UI), change the value of a feature flag so you will receive a different variation in production.
Verify in your application that the flag value has changed.
Alternatively, you can validate your Relay Proxy with curl. You must specify your Relay Proxy base URI, SDK key, and evaluation context in the command.Here’s how:
Load tests designed to measure the Relay Proxy’s performance under load should initialize LaunchDarkly client instances and connect them to your Relay Proxy hardware.
The load testing framework is unsupportedLaunchDarkly does not provide official support for the load testing framework. We do provide guidance on how to use it, described below, but we don’t officially support or update the framework.
We developed a load testing framework for the Relay Proxy based on Locust. You can find it on in the LaunchDarkly Labs GitHub repository. Locust tests events, client-side SDKs, and server-side SDKs. Locust’s internal nomenclature uses the term “users” to refer to simulated SDKs. Do not mistake Locust’s “users” with LaunchDarkly’s user contexts. They are not the same thing.The Relay Proxy instance you test against should be:
Deployed on the same type of hardware you intend to use for your production deployment
Configured to manage LaunchDarkly environments comparable to production
Performance is always dependent on specific workload and environment. You can run benchmarks against your own infrastructure and LaunchDarkly configuration for more accurate information. We recommend that you configure the Relay Proxy to be highly available, which reduces load on any particular server. To learn more, read Relay Proxy guidelines.A single server-side SDK can support many customers. In the case of client-side SDKs, this may correlate with a specific end user, because a client-side SDK is configured for a particular context.
If you have connected the Relay Proxy to a data store, you should also monitor the capacity of the data store and how many hits or misses occur during data lookups. If there are a lot of misses or the data store is nearing capacity, it may be overflowing during high-traffic periods and need more capacity.To learn more about monitoring your data store, read the documentation from your data store provider.
You can configure the Relay Proxy to export metrics, traces, and logs using the OpenTelemetry Protocol (OTLP). The Relay Proxy pushes this data to any OTLP receiver, such as an OpenTelemetry Collector, the Datadog Agent, or Prometheus with its OTLP receiver turned on. It does not expose a metrics endpoint for scraping.To export telemetry, set USE_OTLP=true and set OTEL_EXPORTER_OTLP_ENDPOINT to the address of your receiver:
You can turn off each signal individually with OTEL_METRICS_EXPORTER=none, OTEL_TRACES_EXPORTER=none, or OTEL_LOGS_EXPORTER=none. By default, the Relay Proxy records a trace for every request. To lower trace volume, set OTEL_TRACES_SAMPLER and OTEL_TRACES_SAMPLER_ARG.
You cannot export metrics and traces about the Relay Proxy from LaunchDarklyYou can only export Relay Proxy-related metrics and traces from the Relay Proxy itself. The core LaunchDarkly app and API do not export data in this way.
To learn more, read the Relay Proxy GitHub repository’s Metrics, Tracing, and Logging.
Relay Proxy 8.x exports metrics and traces to Datadog, Stackdriver, and Prometheus using the OpenCensus protocol, and only exports metrics when an SDK is connected to it. The metric names are different from those in 9.0. To learn more, read the Relay Proxy GitHub repository’s Metrics integrations. To learn how the metrics changed in 9.0, read Relay Proxy 8.x to 9.0 migration guide.
