Не работает агрегация нескольких OID в один get запрос

[ahauras]

Приветствую уважаемое сообщество!
При развертывании zabbix 7.0.18 LTS столкнулся с проблемой:
В инструкции вижу, что это поддерживается:

Чтобы найти оптимальное количество объектов для запроса для данного устройства, Zabbix использует следующую стратегию. Он начинает с осторожного запроса одного значения. Если запрос успешен, Zabbix запрашивает два значения. Если запрос снова успешен, Zabbix запрашивает три значения и продолжает аналогичным образом, умножая количество запрошенных объектов на 1,5. В результате получается следующая последовательность размеров запросов: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Но по факту ни на какой из 100 хостов не прилетает snmp get, содержащего больше одного OID даже сразу после добавления.
Галочка "Use combined requests" на каждом хосте стоит. Интервал обновления item в основном 1 минута.

При этом текущая система мониторинга, на которой я мониторю это оборудование, отправляет в get по 40-50 OID.
Мониторится все через несколько прокси тоже версии 7.0.18.
Мое предположение, что для агрегации сервер должен запрашивать все OID одновременно, но он делает это с паузами в секунду-две:

16:40:14.516064 IP 192.168.7.18.161 > 192.168.7.1.30943: C="public" GetResponse(36) .1.3.6.1.4.1.31926.2.2.1.10.1=250820
16:40:15.503064 IP 192.168.7.1.49442 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.2.1.8.1
16:40:15.515252 IP 192.168.7.18.161 > 192.168.7.1.49442: C="public" GetResponse(38) .1.3.6.1.4.1.31926.2.2.1.8.1=7150508358
16:40:16.503546 IP 192.168.7.1.62466 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.7.1
16:40:16.513537 IP 192.168.7.18.161 > 192.168.7.1.62466: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.7.1=2
16:40:18.502875 IP 192.168.7.1.40977 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.10.1
16:40:18.511342 IP 192.168.7.18.161 > 192.168.7.1.40977: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.10.1=1
16:40:19.502785 IP 192.168.7.1.45268 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.9.1
16:40:19.523680 IP 192.168.7.18.161 > 192.168.7.1.45268: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.9.1=1
16:40:20.503647 IP 192.168.7.1.57220 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.19.1
16:40:20.515821 IP 192.168.7.18.161 > 192.168.7.1.57220: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.19.1=-57
16:40:21.503881 IP 192.168.7.1.42378 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.25.1
16:40:21.513350 IP 192.168.7.18.161 > 192.168.7.1.42378: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.25.1=4
16:40:22.503682 IP 192.168.7.1.48192 > 192.168.7.18.161: C="public" GetRequest(33) .1.3.6.1.4.1.31926.2.1.1.24.1
16:40:22.514600 IP 192.168.7.18.161 > 192.168.7.1.48192: C="public" GetResponse(34) .1.3.6.1.4.1.31926.2.1.1.24.1=4

В документации я времени агрегации не нашел. В правильном ли направлении я иду в этом случае?

[Kos]

Хм. Проверил у себя (Zabbix Server 7.0.17) - ситуация аналогичная.
Т.е. если в свойствах элемента данных в поле "OID" указана конструкция "walk[...]" (например, правило обнаружения), то, действительно, идут запросы getBulkRequest, где одним пакектом присылается сразу стопка значений.
А вот если в поле "OID" указано "get[...]", то каждый запрос идёт по отдельности, никакой консолидации не происходит. По крайней мере, в собранных tcpdump'ом трейсах мне таких объединённых запросов (GetRequest-PDU) увидеть не удалось.

Разницы между поведением Zabbix сервера и Zabbix прокси в данном случае быть не должно - они собираются из тех же исходников и используют те же внутренние процессы.

[Kos]

О, обновили документацию (добавлены два абзаца). Похоже, что для асинхронных запросов такая агрегация и в самом деле не предусмотрена (как минимум, в текущей версии).
Вот ссылка (на английскую версию, во избежание разночтений), я выделил синим ключевой момент:

If combined requests cause partial or malformed responses that result in incorrect per-second (delta) calculations (for example, apparent spikes in interface counters), disable Use combined requests for the affected interface to force separate per-item queries; this often prevents false spikes. Alternatively, consider using asynchronous get[] or walk[] items, which are executed asynchronously and are not subject to the per-interface Use combined requests batching — they can be used instead of legacy synchronous OID checks to avoid combined-request related issues. Look for server/proxy log entries similar to the one shown in the Overview section to help identify affected devices.