Comments
Круто! Очень интересен такой опыт больших российских компаний!
Спасибо, прочитал с интересом. Тема мне очень близкая. Тащу примерно такие же задачи, правда в меньшем объеме, но стараюсь по возможности автоматизировать. Для чего использую те же инструменты: zabbix, python, ansible еще.

Отдельное спасибо за рассказ про компьютер под столом, общие папки и IPAM в xls — это прям откровение.
А где же ci/cd и скрам с эджайлом?
Я думал у вас почти Амазон :)

Пара вопросов:
1. Как себя ощущает сервер на виртуалке с 14К хостов и 144K Items?
У меня железный Xeon трудится с 24 ядрами и 32Г памяти, обслуживает около 1К хостов и 60К Items и дышит с трудом

2. «Недостаточная вложенность действий, т.к. часто необходимо вытянуть значение по SNMP и использовать результат в следующем запросе»
LLD неплохо подходит для этого. Там как раз два прохода получается: Discovery rules + Items Prototypes

3. На скринах засветились циски и проприетарный цискин DMVPN. У вас только сеть Заббиксом мониторится? Не пробовали что-нибудь специальное сетевое? LibreNMS например?

4. В чем храните конфиги тех же цисок?
Отвечу по своему опыту с забиксом — 1к хостов, 77к итемов — один железный сервер, бд mysql и сервер забикса на нем, по железу i5 3570, 16gb ram. Все крутится относительно шустро, но после апгрейда ssd на nvme 970pro la вырос до 8-9, причем нагрузка от mysql, хотя очереди не больше 30 сек и данные в веб интерфейс прогружаются шустро. Вообще основной «тормоз» забикса — подсистема хранения. Когда перешли с обычных винтов на ссд — разница просто огромная, дальше просто апгрейдились по мере исчерпания места, производительности хватало.
Рад что полезно :)
По поводу стола могу сказать, что это было давно и мы искали подходы. Не все сразу получается сделать идеально, часто находим решение, пробуем и понимаем что нам нужно что-то еще, или что-то другое.

По вопросам:
1. Ощущает неплохо, основное на что мы стараемся делаеть упор — не мониторить все сразу, а создавать item'ы только по необходимым метрикам. Как пример — бывают неполадки связанные с кольцами, но мы не стали мониторить STP на всем оборудовании, т.к. их очень мало и они редко возникают, и проще осуществлять починку уже в real-time зайдя на оборудование и проведя диагностику. Если добавлять такой item на все объекты получится +14к айтемов и +14к триггеров. В общем, немного lean, делаем проверки по топ-проблемам.
У нас сейчас item/trigger 146k/52k. Распеределение item по сервер/прокси_1/прокси_2 — 6k/70k/70k. Машины все виртуальные — 8 CPU, 16 RAM. Но сейчас, чтобы улучшить производительность, растем линейно — добавляем еще 2 прокси, плюс выводим базу на отдельный сервер. Веб всегда жил отдельно. В основном рост связан с увеличением числа объектов, плюс появление новых item, чтобы следить за новыми сервисами.

2. Да, изначально было так, но исходя из бережливого подхода мониторим только необходимые параметры. Тут тоже пример — нам нужно следить только за внешними интерфейсами на маршрутизаторе, которые связаны с провайдером, аплинки в общем. LLD без фильтра выведет все интерфейсы роутера, коих может быть очень много и начет мониторить все. Если использовать LLD с фильтром, то у всех внешних интерфейсов должен быть один признак, например, description, чтобы по результату LLD мы могли отфильтровать. Но у нас description были разные, да и человеческий фактор может привести к ошибке (инженер зашел и поменял, логика сломалась). Чтобы этого избежать мы этим признаком выбрали наличие BGP сессии на интерфейсе. Т.е. находим через snmpwalk всех соседей (на самом деле смотрим ip source для bgp сессий), а потом находим интерфейсы с этими ip и используем их id. По сути тот же LLD, только запускает он внешний скрипт, а не стандартный SNMP.

3. Для магазинов используем для сети только заббикс, выходит дешевле, т.к. опенсорс, и очень гибкий, все что угодно можем доделать. Недавно внедрили Splunk. Для корневой сети используем решение посложнее — CA Spectrum. Очень помогает Grafana. Есть желание попробовать описать эти решения в последующих статьях.

4. Конфиги пока собираем через python-ssh, но сейчас развиваем тему автосбора средствами железок в git. По мере развития постараюсь описать и этот подход, если он будет интересен.
Похоже на риторический вопрос. Как IOS vs Android. В целом, изначально выбрали заббикс, а развивать дальше лучше существующее, чем постоянно менять коней на переправе. Тем более, возможностей текущего решения хватает и путей развития и масштабирования тоже масса. PRTG к тому же платный.
Лет этак 14 назад, когда я работал инженером в телекоме областного уровня, я написал свой мониторинг на Tcl :) Типа everything is serious, с многопоточным микроядром, модулями, шаблонами для одинакового оборудования, autodiscovery сущностей и связей между объектами, alarm'ами, сетевым API на основе текстовых команд с поддержкой мгновенных асинхронных уведомлений, и так далее. Где-то тысячи полторы железок это все мониторило (а если считать по item'ам — то десятки тысяч) на железе тех времен (на Solaris/SPARC) без особых проблем. Ностальгия :)

Точно :) Было и приложение, которое по сети подключалось к нему и показывало карту сети, состояние объектов и alarm'ы, Netstate, его мой коллега разработал.

Я похоже с ним общался, он как раз давал исходники чтоб под линукс это собрать.
Самая первая система мониторинга, как же давно это было. Год наверно 2007
сейчас погуглил проект на сайтах отсутствует. Можно порыться, где то у меня были все сорцы.
Они лежат у меня на Гитхабе (вместе с Netstate в src/contrib). Только репозиторий заархивирован, потому что разработка больше не ведется :)
Спасибо за пост, проделана просто огромная работа…
Но как, так…
«Данные по провайдерам, без которых не обойтись инженерам 1-й и 2-й линии, хранятся в excel-файле на общем сетевом диске и актуализируются менеджерами, ведущими договоры по связи.»
Ребята вы берете инфу о магазинах из SAP, при этом храня данные по провам в excel файле? Что мешает использовать только SAP?
«У нас в поле с IP- адресом в SAP хранится адрес сервера, а не маршрутизатора, но с помощью модуля ipaddress считаем первый адрес подсети, который в нашем случае всегда роутер»
А, как вы поступаете с другими устройствами? Коммутаторами, точками например? Есть ли что-то на dhcp?
Есть ли интеграции с сервисдеск системами? Много ли ложных срабатываний?
Прошу прощения за такое количество вопросов:)

Ну что тут сказать. Legacy, legacy, legacy. Но честности ради, у нас идет сейчас большая работа по созданию единой CMDB которая учитывает и сетевое оборудование, и провайдеров и создает связи между ними, но это отдельная совсем тема. Тут больше о том, что любую боль можно преодолеть и даже автоматизировать ее. Улучшать можно бесконечно.
Другие устройства нас интересуют в меньше степени, поэтому Zabbix для маршрутизаторов. Его задача оперативно отслеживать доступность каналов связи и каналообразующего оборудования. Коммутаторы, как и роутеры, отсылают свои данные в Splunk, это тоже больше отдельная тема. Никто не скажет про коммутатор больше, чем он сам. Но не исключаю, что мы добавим их в zabbix также при наличии необходимости.
На DHCP держим только менеджмент точек доступа. Остальной менеджмент весь статикой.
Интеграция — созданием заявок в Remedy по выбранным событиям или цепочке событий.
Ложные срабатывания это сложный вопрос. Что считать ложным? Ложных не было, бывали случаи когда пропала связь одного Zabbix-Proxy с внешним миром, и он, абсолютно обоснованно, посчитал что все объекты выпали из сети и он забил тревогу. Но это правильное поведение.
Но честности ради, у нас идет сейчас большая работа по созданию единой CMDB которая учитывает и сетевое оборудование, и провайдеров и создает связи между ними, но это отдельная совсем тема.

Если не секрет, какое решение для CMDB используете?
Не секрет. HPSM, плюс свои наработки для сетевого оборудования и каналов связи.
и что важно соблюдать текущую структуру. На практике, конечно, возникали ошибки

Всегда держим структуру в первых строках файла. И файлом пользоваться проще, и структуру можно сверять на предмет изменений.
Согласен, такой же подход используем. Ошибки были в основном в нестандартных названиях в ячейках, так что Zabbix не мог их суммаризировать. Как например, скорость, 4mbps или 4096kbps. Все ради красоты)
Планируется ли выложить скрипты в github?
Почему это важно. Вы могли бы получить бесплатно новую функциональность от сторонних разработчиков через PR, бесплатное тестирование, бесплатное исправление ошибок через PR и т.д.
Привет. Таких планов не было, большинство скриптов узкоспециализированые под текущую структуру файлов/выгрузок и под инфраструктуру конкретной компании. Если кто-то решит использовать данный подход в своей деятельности — это здорово, но придется это оптимизировать под свою структуру. В текущих реалиях и скорости изменений — нам придется их видоизменить, или полностью переписать в течении года.
Если говорить о Zabbix, и скриптах содержащих в своей основе API, то это скорее возможности использования инструмента на практике. И если стремиться к новой функциональности, то скорее через развитие API Zabbix, чем через скрипты использующие его.
Есть некоторые скрипты, не относящиеся к теме, которые имеют смысл для PR, в широком смысле. Однако, на мой взгляд их пока недостаточно, чтобы действительно серьезно относиться к этому как к новой функциональности.
Смахивает на РЖД.

Короче если бы ВЫ не гнались за гуем ( почему то это люди из мира виндовс… )
То использовали бы NAGIOS и все бы упростилось ( добавление хостов ) и ускорилось ( загрука сервера ) в разы.
Only those users with full accounts are able to leave comments. Log in, please.