Project: Trickster (Observability and Analysis / Observability)
File: health.md

Trickster provides a `/trickster/ping` endpoint that returns a response of `200 OK` and the word `pong` if Trickster is up and running. The `/trickster/ping` endpoint does not check any proxy configurations or upstream origins. The path to the Ping endpoint is configurable, see the configuration documentation for more information. Trickster offers `health` endpoints for monitoring the health of the Trickster service with respect to its upstream connection to origin servers. Each configured backend's health check path is `/trickster/health/BACKENDNAME`. For example, if your backend is named `foo`, you can perform a health check of the upstream server at `http://<tricksteraddress:port>/trickster/health/foo`. The backend health path prefix `/trickster/health/` is customizable. See the for more info about setting the `healthhandlerpath` configuration, or refer to this example: ```yaml frontend: healthhandlerpath: /-/trickster/health ``` The behavior of a `health` request will vary based on the Backend provider, as each has their own health check protocol. For example, with Prometheus, Trickster makes a request to `/query?query=up` and (hopefully) receives a `200 OK`, while for InfluxDB the request is to `/ping` which returns a `204 No Content`. Supported TSDB Providers are pre-configured in Trickster to perform a suitable health check operation, however these can be overridden in the configuration file. For non-TSDB Backends, the default behavior is to make a `GET` request to `http://origin_url:port/` and expect a 2xx response. However, all aspects of the Health Check request and expected response are configurable per-Backend. ```yaml backends: server1: provider: reverseproxycache origin_url: http://server1 healthcheck: # all values below are optional verb: HEAD path: /health ``` ```yaml backends: server1: provider: reverseproxy origin_url: http://server1 healthcheck: # all values below are optional verb: HEAD scheme: https host: alternate-hostname.example.com path: /health query: param1=value1&param2=value2 headers: User-Agent: health-check-agent timeout_ms: 1000 expected_codes: [ 200, 204, 206, 301, 302, 304 ] expected_headers: X-Health-Check-Status: success expected_body: "pass" ``` See more examples in . By default, a Backend will only initiate a health check on-demand, upon receiving a request to its health endpoint. To facilitate integrations with the Trickster Application Load Balancer provider, additional options provide for 1) timed interval health checks and 2) thresholding for consecutive successful or unsuccessful health checks that determine the backend's overall health status. ```yaml backends: server1: provider: reverseproxy origin_url: http://server1 healthcheck: path: /health timeoutms: 1000 # timeoutms should be <= interval_ms interval_ms: 1000 # auto-poll health every 1s failure_threshold: 3 # backend is unhealthy after 3 consecutive failures recovery_threshold: 3 # backend is healthy after 3 consecutive successes ``` In addition to the out-of-the-box health checks to determine up-or-down status, you may want to setup alarms and thresholds based on the metrics instrumented by Trickster. See for collecting performance metrics about Trickster.