Подсчет метрики health downtime в stream upstreams

Добрый день.

Имеем ряд взаимодействий, в которых через angie tcp stream софт открывает единственное длительное tcp соединение с клиентом, в котором осуществляется вся работа. Заметили, что в таких взаимодействиях после недоступности клиента и его восстановления метрика downtime продолжает расти вплоть до штатного завершения сессии, метрика state также отдает значение unavailable. При этом по метрике current видно, что имеется открытое tcp соединение, на стороне софта также видно, что идет успешная работа с клиентом, но метрика downtime продолжает расти.

Используем метрику downtime в условиях триггеров и данное поведение приводит к тому, что не получается достоверно понять ушла проблема или нет, т.к. данная метрика продолжает расти.

В метриках выглядит следующим образом (запрашивал метрики с интервалом 30-40 секунд)

      "xxx": {
        "peers": {
          "xxx:yyy": {
            "server": "xxx:yyy",
            "backup": false,
            "weight": 1,
            "state": "unavailable",
            "selected": {
              "current": 1,
              "total": 83,
              "last": "2025-04-10T20:02:33Z"
            },
            "data": {
              "sent": 351492,
              "received": 322518
            },
            "health": {
              "fails": 63,
              "unavailable": 3,
              "downtime": 301844615,
              "downstart": "2025-04-10T19:27:42.444Z"
            },
            "sid": "91c11b403bd00769fd61ac29e7175a20"
          }
        }
      }

----

      "xxx": {
        "peers": {
          "xxx:yyy": {
            "server": "xxx:yyy",
            "backup": false,
            "weight": 1,
            "state": "unavailable",
            "selected": {
              "current": 1,
              "total": 83,
              "last": "2025-04-10T20:02:33Z"
            },
            "data": {
              "sent": 351492,
              "received": 322518
            },
            "health": {
              "fails": 63,
              "unavailable": 3,
              "downtime": 301889534,
              "downstart": "2025-04-10T19:27:42.444Z"
            },
            "sid": "91c11b403bd00769fd61ac29e7175a20"
          }
        }
      }

Можете, пожалуйста, уточнить каким образом сейчас ведется подсчет метрики downtime и возможно ли скорректировать эту логику, чтобы при наличии активных сессий tcp upstream не помечался как недоступный и метрика downtime не продолжала расти.

Модуль stream оперирурет сессиями в отличии от HTTP-модуля, который оперирует запросами.

Одна сессия - это один законченный сеанс связи клиента и бекенда от открытия соединения до его закрытия.

Когда число неудачных сессий за заданный интервал fail_timeout достигает значения max_fails, то сервер переводится в состояние unavailable и начинает отсчитываться счетчик downtime. При этом периодически, раз в fail_timeout, на такой сервер направляется одно соединение для очередной проверки его работоспособности. После успешного завершения проверочной сессии сервер переводится в состояние up и downtime перестается отсчитываться.

То, что вы наблюдаете - это проверочная сессия, пока она не завршится - сервер будет считаться недоступным и другие клиенты на него направляться не будут (по крайней мере не чаще, чем раз в fail_timeout). В общем-то вся эта логика унаследована от nginx - статистика тут добавляет лишь визуализации.

Похоже я не совсем прав. Коллеги тут подсказали, что у stream есть механизм, который позволяет сбрасывать счетчик неудачных попыток до завершения сессии - его добавили в 2016 году. Похоже API статуса не учитывает этого механизма и это нужно поправить.

Будет исправлено в следующей версии.

Большое спасибо за предоставленную обратную связь. С нетерпением ждем нового релиза!