Pull to refresh

Comments 23

Круто! Очень интересен такой опыт больших российских компаний!
Спасибо, прочитал с интересом. Тема мне очень близкая. Тащу примерно такие же задачи, правда в меньшем объеме, но стараюсь по возможности автоматизировать. Для чего использую те же инструменты: 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
Ну да, где-то середина 2000-х это была :)
сейчас погуглил проект на сайтах отсутствует. Можно порыться, где то у меня были все сорцы.
Они лежат у меня на Гитхабе (вместе с 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 и все бы упростилось ( добавление хостов ) и ускорилось ( загрука сервера ) в разы.
Sign up to leave a comment.