+++ This bug was initially created as a clone of Bug #1892338 +++ If a route were to break the HAProxy config files, and thus break HAProxy reloads, the HAProxyReloadFail alert will only fire for ~5 minutes. Instead, the HAProxyReloadFail alert (& base metric) should be reworked. The template_router_reload_fails metric should be dropped in exchange for a metric that tracks the status of the most recent reload. ie template_router_reload_success which is pinned to 1 on successful reloads, and 0 on failed reloads. The current template_router_reload_fails reports an increasing value of failed reloads, which is difficult to alert on properly. A flag/boolean metric is trivial to alert on for the actual duration of the problem. This affects 4.7, 4.6, and 4.5, so backports will be required. --- Additional comment from wking on 2020-10-28 14:09:57 UTC --- I'd mentioned a positive name, but a negative name like template_router_reload_failure might be more convenient if you wanted a label with a reason slug, or some such. You could always add a reason to a positive label too, but template_router_reload_success{failure_reason="whatever"} feels more awkward than template_router_reload_failure{reason="whatever"}. --- Additional comment from sgreene on 2020-10-28 14:17:23 UTC --- (In reply to W. Trevor King from comment #1) > I'd mentioned a positive name, but a negative name like > template_router_reload_failure might be more convenient if you wanted a > label with a reason slug, or some such. You could always add a reason to a > positive label too, but > template_router_reload_success{failure_reason="whatever"} feels more awkward > than template_router_reload_failure{reason="whatever"}. Noted, I will make sure to use a negative name instead. :) --- Additional comment from wking on 2020-10-28 15:32:44 UTC --- Not a regression, so it's hard to imagine holding 4.7.0 on a fix for this.
Adding upcoming sprint as this backport is in the queue.
Depends on the 4.6.z BZ which has not merged yet. Adding upcoming sprint.
this is awaiting cherry-pick approval.
The PRs for this BZ are still awaiting cherry-pick approval.
Tested in "4.5.0-0.nightly-2021-03-28-125930" payload. It is noted that the new metric and the associated Prometheus rules are added as intended: ---- curl -sS -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImRFT2ZlVFlHSzNWdFBoLVdscjllVWNuNmQ5b0FqS1RNOFhnZDRrOUpPSjAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJvcGVuc2hpZnQtbW9uaXRvcmluZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJwcm9tZXRoZXVzLWs4cy10b2tlbi02NGpjdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJwcm9tZXRoZXVzLWs4cyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjAzZDEwNzc5LTgyYzktNDc5MC1hN2EyLTNkZmZkMjk5ZDE5ZCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpvcGVuc2hpZnQtbW9uaXRvcmluZzpwcm9tZXRoZXVzLWs4cyJ9.RtdIZaHCJLbJ4tiFC5_I8S4_O3hDIUSOtaKQXy65lxvfW6QokUyR9UI3WILy31Jjv_5LDljxOK241kHvmyLOwBvAHxJ1l2lOuC5ckQ60rTJHZf9Yrc3tf9QOhDPLxagdQkn3vZjqWJC-Gm_iRalJgMqKp6NAR0qiJOTWpbSOfLQokZsIafaYYo81jWigAWjXrU8YgRP2_vSBwbMrtIrgXHuyGfyCUsa9VoH6jl7tW5m6xbij4N8hUWAXrTTqBmecuvT0ScxVpg51JF8QW1nV0HAauBHPLGifgBoby38pqsWbXWH9lKcCfHDY8KxOh4VZrMK58-spqiujKrmn9D3-wQ" -k https://10.131.0.14:1936/metrics | grep -i template_router_reload_failure # HELP template_router_reload_failure Metric to track the status of the most recent HAProxy reload # TYPE template_router_reload_failure gauge template_router_reload_failure 0 ----
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.5.37 bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:1015