Контроль закрытия сессий web мониторинга

[ya.asoloviev]

Добрый день.
Есть проблема, что периодически зависают web сервисы которые мониторит Zabbix и подозрение в том, что Zabbix при web мониторинге открывает сессию, но не закрывает её. Это приводит к переполнению таблицы состояний.
Осуществляется мониторинг доступности web-интерфейса ipmi модуля в который встроен т.н. маленький компьютер, его ресурсов скорее всего не хватает хранить столько открытых сессий, а так происходит когда приходит каждый новый запрос от заббикса.
Подтвердить или опровергнуть мне не удалось, что Zabbix открывает и не закрывает сессию. Не нашел технической информации по вопросу.

1. Как Zabbix отправляет запрос о доступности web ресурса? Полагаю посредством curl, но что именно отправляет и как обрабатывает ответ.
2. Как удостовериться, что сессия закрылась или нет?
3. Можно ли контролировать процесс закрытия сессий?

Что то мне подсказывает, что сессия автоматически закрывается через указанный Timeout в настройках шага, но для этого нет подтверждений.
Попытаюсь снять с сети трафик в формате pcap и почитать что там видно.

[Kos]

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

[ya.asoloviev]

Прикладываю настройки шага, все в принципе по умолчанию:

[Kos]

Весь сценарий состоит из одного шага (т.е. единственного запроса)? Тогда в чём смысл термина "сессия"?
Или вы про TCP-сессию? Она должна закрываться после последнего запроса сценария, и если вы снифером собираете трафик, то это должно быть видно.

[ya.asoloviev]

Добрый день.
Спасибо за ответ. Прикладываю скриншоты трафика. По всей видимости сессия закрывается, как при ответе от сервиса, так и в случае если сервис завис и не отвечает.
Но для меня изначально было это не очевидно, выглядит так, что zabbix отправляет запрос на проверку и на этом всё, как он закрывает tcp сессию не понятно.
Я слабо разобрался в PCAP и обозначениях флагов, но своими словами опишу увиденное.
На скриншоте ниже 10.х.х.8 - прокси через который Zabbix опрашивает, 10.х.х.18 - хост
Видно, что предпоследняя строка содержит флаг FIN,ACK что означает уведомление о намерении прекратить сессию, хост в ответ отправляет ACK видимо подтверждая полученные данные.

На скриншоте ниже 10.х.х.2 - zabbix, 10.x.x.51 хост.
Хост не отвечает (завис), в связи с чем zabbix отправляет пакет rst, что означает сброс сессии.

[Kos]

Второй скриншот нормальный. На первом мне не нравится то, что процесс окончания TCP-сессии не завершён со стороны хоста: не видно ответного пакета с флагом FIN. По сути, сервер Zabbix остаётся в состоянии FIN-WAIT-2 (ссылка). Если это все данные (дальше пакетов нет), то можно говорить о неправильном поведении (некорректном закрытии TCP-соединения) не со стороны сервера Zabbix, а со стороны проверяемого им хоста.

[ya.asoloviev]

Прикладываю третий сценарий (скриншот), это мониторинг другого типа хостов, тут видно, что Zabbix отправил в FIN,ACK и в ответ получил FIN,ACK. И последний ACK тут от zabbix, а там был от хоста.

Требуется понять, как локализовать проблему. В любом случае, полезно понимать, как Zabbix себя ведёт при web мониторинге.

[Kos]

Ваш последний скриншот лишь подтверждает мысли из предыдущего моего сообщения. Zabbix (точнее, операционка, на которой он работает) ведёт себя совершенно корректно, а вот "встроенный маленький компьютер" - нет. Если после получения от Zabbix-а пакета с флагом FIN он ничего больше сам передавать не собирается, то должен закрыть соединение со своей стороны, чего не делает.

[ya.asoloviev]

Kos, спасибо за помощь!