Load balancer backend parity
98-load-balancer-backend-parity.yaml
HTTP(S)
What this example does
Multi-node infrastructure verification: Load balancer backend parity. This can reveal differences between individual service backends.
Checks and behavior
- Sends an GET request to https://app.example.com/health.
- Checks allowed/denied HTTP status codes.
- Looks for expected response content and/or rejects known error markers.
- TLS settings cover certificate trust, certificate expiry.
- Runs against explicitly configured backends.
- Retries failures to reduce transient false alarms.
- Applies response-time thresholds for operational alerting.
- Formats results for icinga2 output.
Adapt example domains, addresses, credentials and thresholds to your environment before use.
YAML configuration
# Copyright (c) 2026 mati peterson. Maintainer: mati peterson <ipsonic@mailbox.org>. Project: https://ipsonic.com/probe/. Disclaimer: Provided AS IS, without warranty of any kind. Use at your own risk; validate checks and configurations before production use.
# Probe each backend by resolving the same public hostname to different IPs.
# The URL hostname remains in Host and TLS SNI; replace documentation IPs.
name: "Load balancer backend parity"
url: "https://app.example.com/health"
request: {method: GET}
timeouts: {connect: 3, response: 10}
tls: {verify: true, min_valid_days: 14}
execution:
retries: 2
retry_delay: 1
success_required: 2
backends:
- name: app-node-a
resolve: {app.example.com: 192.0.2.10}
- name: app-node-b
resolve: {app.example.com: 192.0.2.11}
tests:
status: {allow: [200]}
body:
contains: [healthy]
not_contains: ["maintenance", "Traceback"]
monitoring:
service_name: "Application Backend Parity"
output: icinga2
on_failure: critical
thresholds:
response_time: {warning: 2, critical: 5}