Рваные графики Cisco ASA

[neo32]

Здравствуйте.
Мониторю Zabbix'ом, Cisco ASA, получаю рваные графики. Канал в целом везде нормальный, да и раньше нормально работало. для мониторинга использую шаблон взятый отсюда https://share.zabbix.com/network_dev...-asa-discovery
данные собираю по snmpv3.
гуглил различные варианты почему вообще они могут рваться, первое что пришло в голову, посмотреть в сторону 32 и 64 битных счётчиков. Но ситуация такова, что графики рвутся и в таких параметрах как "ConnectionInUse" или к примеру "CPU Utilisation avg last 1 min", а они как я понимаю 64битными быть не могут..
В очередях периодически мелькают snmpv3 очереди итемов от этих АС.
в логах по проблемным железкам выдаёт:

3898:20170524:065940.606 temporarily disabling SNMP agent checks on host "ASA-OTR": host unavailable
  3904:20170524:065945.557 enabling SNMP agent checks on host "ASA-OTR": host became available
  3883:20170524:070010.525 SNMP agent item "ifInOctets[Adaptive Security Appliance 'Ethernet0/3' interface]" on host "ASA-OTR" failed: first network error, wait for 15 seconds
  3796:20170524:070040.225 temporarily disabling SNMP agent checks on host "ASA-OTR": host unavailable
  3788:20170524:070115.224 enabling SNMP agent checks on host "ASA-OTR": host became available
  3830:20170524:070115.338 SNMP agent item "ifInOctets[Adaptive Security Appliance 'Ethernet0/0' interface]" on host "ASA-OTR" failed: first network error, wait for 15 seconds
  3843:20170524:070120.243 resuming SNMP agent checks on host "ASA-OTR": connection restored
  3791:20170524:070145.248 SNMP agent item "ifInOctets[Adaptive Security Appliance 'Ethernet0/2' interface]" on host "ASA-OTR" failed: first network error, wait for 15 seconds
  3797:20170524:070220.135 resuming SNMP agent checks on host "ASA-OTR": connection restored
  3783:20170524:070245.296 SNMP agent item "ifInOctets[Adaptive Security Appliance 'Ethernet0/3' interface]" on host "ASA-OTR" failed: first network error, wait for 15 seconds

В списке устройств, если фильтрануть по АСАм, они с различной периодичностью становятся красненькими и пишет "Timeout while connecting to ..."

Подскажите пожалуйста в чём может быть проблематичность ?

UPD. Выяснил ещё одну деталь, проблема кроется не только в устройствах Cisco ASA, а в целом с устройств, данные с которых получаются по SNMPv3. Такая же проблема и на PDU и на свичах Cisco.

[Kos]

Трудно говорить что-то конкретное, когда не указана версия используемого Zabbix-сервера. Могу только сказать, что в линейке 3.x было довольно много изменений, относящихся к улучшениям работы по SNMP.

Чисто теоретически, могу предположить, что может не хватать поллеров на Zabbix-сервере (или Zabbix-proxy, если устройства мониторятся через него), либо используются слишком короткие тайм-ауты (по умолчанию - 3 или 4 секунды, в зависимости от версии Zabbix). И то, и другое выставляется в конфиге Zabbix-сервера (либо Zabbix-прокси), считывается при старте соответствующего демона.

Ну, ещё может быть проблема с bulk requests, но это маловероятно: всё-таки, в последних версиях этот механизм уже достаточно "вылизан".

А начал бы я, всё же, в любом случае с замены 32-битных счётчиков 64-битными там, где это возможно (например, трафик на интерфейсах).

[neo32]

Трудно говорить что-то конкретное, когда не указана версия используемого Zabbix-сервера. Могу только сказать, что в линейке 3.x было довольно много изменений, относящихся к улучшениям работы по SNMP.

Чисто теоретически, могу предположить, что может не хватать поллеров на Zabbix-сервере (или Zabbix-proxy, если устройства мониторятся через него), либо используются слишком короткие тайм-ауты (по умолчанию - 3 или 4 секунды, в зависимости от версии Zabbix). И то, и другое выставляется в конфиге Zabbix-сервера (либо Zabbix-прокси), считывается при старте соответствующего демона.

Ну, ещё может быть проблема с bulk requests, но это маловероятно: всё-таки, в последних версиях этот механизм уже достаточно "вылизан".

А начал бы я, всё же, в любом случае с замены 32-битных счётчиков 64-битными там, где это возможно (например, трафик на интерфейсах).

Простите, привык уже что у нас последняя версия зачастую стоит..
3.2.6 версия сервера
поллеров для эксперимента вкрутил 200 штук.. хотя не уверен что ему столько нужно:



булки я во время разбирательств с АСАми вырубил на них.
счётчики 64 включил, там где это возможно, результата не дало.
таймауты выставил на макс - 30 сек..
Возможно стоит поглядеть в сторону Unreachable delay, Unreachable period и Unavailable delay, но я честно говоря не знаю как их лучше крутить..

[neo32]

Upd.

Вот кстати то, как у меня выглядит один из графиков по интерфейсу для параметра OutOctets:



Согласитесь страшно выглядит?))

[Kos]

счётчики 64 включил, там где это возможно, результата не дало.
[...]

Вот кстати то, как у меня выглядит один из графиков по интерфейсу для параметра OutOctets:
[...]
Согласитесь страшно выглядит?))

У меня выглядело аналогично для гигабитных и 10Г-интерфейсов при использовании 32-битных счётчиков. После перехода на 64-битные - нормализовалось. Там важно не только включить новые счётчики, но убрать старые. Если счётчики менялись в шаблоне и правилах дискаверинга интерфейсов (где они обычно и расположены), то надо дождаться, пока отработает этот дискаверинг (и убедиться, что они таки заменились).

поллеров для эксперимента вкрутил 200 штук.. хотя не уверен что ему столько нужно

Надо смотреть график их использования (Zabbix data gathering process busy % из стандартного шаблона) и ориентироваться по нему и по соседнему (Zabbix internal process busy %). Может, ещё какие процессы CPU сервера отъедают или базу данных сильно грузят (housekeeper, например).

Тайм-ауты я бы для начала ставил бы без фанатизма, секунд 8-10.

[neo32]

to Kos

У меня выглядело аналогично для гигабитных и 10Г-интерфейсов при использовании 32-битных счётчиков. После перехода на 64-битные - нормализовалось. Там важно не только включить новые счётчики, но убрать старые. Если счётчики менялись в шаблоне и правилах дискаверинга интерфейсов (где они обычно и расположены), то надо дождаться, пока отработает этот дискаверинг (и убедиться, что они таки заменились).

Отсоединял с очисткой, подсоединял заново.. результата не дало, и как я уже ранее говорил, такие параметры как "кол-во соединений" и "утилизация CPU за минуту", также отображаются в "рваных" графиках..

Надо смотреть график их использования (Zabbix data gathering process busy % из стандартного шаблона) и ориентироваться по нему и по соседнему (Zabbix internal process busy %). Может, ещё какие процессы CPU сервера отъедают или базу данных сильно грузят (housekeeper, например).

Тайм-ауты я бы для начала ставил бы без фанатизма, секунд 8-10.

Вот на всеобщее выставляю свои графики
Zabbix data gathering process busy %

[neo32]

А вот второй
Zabbix internal process busy %


Какой диагноз можно поставить глядя на это ?

UPD:
Ещё заприметил, что как только отсоединяю шаблоны ASA Discovery, от наблюдаемых железок, с очисткой, то есть перестаю мониторить их вовсе, очередь уменьшается, ставлю на мониторинг вновь, очередь опять растёт, как раз по параметрам ASA's .

[yukra]

to Kos
Вот на всеобщее выставляю свои графики
[/IMG]

zabbix poller - минимум 8%, максимум 100. Как по мне, так это не нормально. У меня этот же параметр тоже конечно скачет, но от 30 до 65%, и то я понимаю причину + unreachable poller должен всегда быть ровно в ноль и не капли больше.
Нет, если у вас работы по переконфигурированию, авария с потерей связи до части агентов или что-то типа того, то ок естественно будет не ноль, но во время, когда "все работает штатно" он не должен быть отличным от нуля.

Вот для примера мой аналогичный график, при этом я знаю причину того, что у меня unreachable poller и zabbix poller скакал - я на препроде один сервис мучал не выключая его из мониторинга, и часть метрик действительно были недоступны из-за выключенных служб.

[neo32]

zabbix poller - минимум 8%, максимум 100. Как по мне, так это не нормально. У меня этот же параметр тоже конечно скачет, но от 30 до 65%, и то я понимаю причину + unreachable poller должен всегда быть ровно в ноль и не капли больше.
Нет, если у вас работы по переконфигурированию, авария с потерей связи до части агентов или что-то типа того, то ок естественно будет не ноль, но во время, когда "все работает штатно" он не должен быть отличным от нуля.

Вот для примера мой аналогичный
<>
при этом я знаю причину того, что у меня unreachable poller и zabbix poller скакал - я на препроде один сервис мучал не выключая его из мониторинга, и часть метрик действительно были недоступны из-за выключенных служб.

Сегодня с утра, график вот такой, за последние 6 часов.



Извините, но как по Вашему, в чем у меня может быть проблема ?
У нас конечно не всё идеально с каналами связи, но не настолько чтобы не достукиваться до железок которые стоят в 1ом здании с Zabbix сервером или до которых канал 10 мегабит..
Я просто ума не приложу, что у меня конкретно может быть не так..
Кстати, про поллеры, Zabbix у меня сам начинает ругаться "Zabbix poller processes more than 75% busy", когда значение в zabbix_server.conf стоит меньше 140-150.

UPD: Хочу заметить, что логи все засыпаны сообщениями об ошибках типа "first network error, wait for 15 seconds" и "another network error, wait for 15 seconds", а затем "connection restore". Может кто то подсказать изза чего такое ?

UPD2: https://www.zabbix.com/forum/showthread.php?t=26286
Нашёл похожую проблему за 2013 год, чувак понадеялся на версию 2.2 , но у нас то 3.2.6)) этот этап уже позади

UPD3: Клонировал шаблон с переделкой на SNMPv2 и прописал на Cisco ASA доступ по SNMPv2 для сервера zabbix, прикрепил шаблон, посмотрел - Вердикт: графики строятся отлично, без каких либо разрывов.
Остаётся не понятной ситуация с SNMPv3. Почему же при опросе устройств по этой версии протокола, происходят постоянные дисконнекты железок и их не опрашиваемость.. ?

[sadman]

upd: Хочу заметить, что логи все засыпаны сообщениями об ошибках типа "first network error, wait for 15 seconds" и "another network error, wait for 15 seconds", а затем "connection restore". Может кто то подсказать изза чего такое ?

Подозреваю, что смысл такой: железка не ответила первый раз, второй, потом очухалась. Может слишком много запросов к ней по smnp - вот не все сразу и обслуживаются.

[Kos]

У SNMPv3 больше накладные расходы (на обработку логина/пароля, аутентификации/авторизации, шифрование и т.п.). При большом количестве запросов это может подгружать процессор устройства, который занимается обслуживанием SNMP-запросов (замечу, что на свитчах это, как правило, отдельный чип, нежели те, которые занимаются непосредственно свитчеванием - т.е. форвардингом пакетов). В результате часть запросов просто игнорируется (что, строго говоря, по протоколу вполне допустимо).

Обычно помогает опрос в bulk-режиме, при котором сразу много запросов группируются в один. У Вас, помнится, этот режим как раз был выключен.

[neo32]

To Sadman
to Kos

Большое спасибо за ответы, про то что железка не успевает я немного не учитывал и попробую всё же включить на особо проблемных железках bulk. Спасибо Вам.

[Nagainos]

Похожая проблема, что и у топикстартера.
Часть железа выпадает с сообщением "snmp_build: unknown failure" через час после запуска zabbix-server'а и как итог - рваные графики.
В итоге прикрутил костыль - перезагружаю zabbix-server раз в час и планирую съехать на версию 3.0 в надежде что это поможет.

- SNMPv2
- Использую только номера OID'ов, без записи текстом.
- На счёт 64битных счётчиков - лично мне не помогло, хотя нагрузка на гигабитные сетевые интерфейсы стала считаться точнее.
- Bulk запросы пробовал включать/выключать, не помогло.

PS. Из странного - не всегда получается корректно рестартануть zabbix-server, часть дочерних процессов не завершается при сигнале SIGTERM в мастер-процесс и остаётся "работать" тем самым мешая systemd поднять zabbix-server.

[Nagainos]

to sadman
to kos

Большое спасибо за ответы, про то что железка не успевает я немного не учитывал и попробую всё же включить на особо проблемных железках bulk. Спасибо Вам.

Вам удалось найти причину проблемы?

[neo32]

Вам удалось найти причину проблемы?

Здравствуйте.
Вы знаете, по факту нет, выяснить в чём трабла с технической точки зрения или найти какие то неопровержимые док-ва, что железки не успевают обрабатывать шифрованный snmpv3 трафик, НЕ УДАЛОСЬ

Выходом нашли по новой переводить интересующие железки (а их дохрена ), на версию snmpv2