Добрый день.
1) Развернутого ответа пока нет. Пробуем использовать, тематика интересная пытаемся понять возможности для нас. Не все получается. Как раз ваш гайд помог начать. Спасибо:)
2) Рассматриваем различные инструменты. Для Cisco, например, есть много возможностей и многие инструменты очень удобны, в частности тот же Batfish. Но часто не получается использовать универсальное решение, так как у нас используется много оборудования HPE на платформе Comware. Для него либо нет готовых решений, либо их мало. Конкретно сейчас не используем Napalm, пытаемся написать кастомное решение под свою инфраструктуру. Но мы в этой части пока в самом начале пути, возможно мы к нему придем.
Привет.
1. Nornir смотрел, но пока в качестве факультатива, в проде еще не использовали. Зависит от цели использования. Если применим в работе, то в одной из следующих статей попробую рассказать об успехе, или нет.
2. Зависит от системы. Например, для Ansible это ansible-vault. Для gitlab это внутренние скрытые переменные. Для чистого python вопрос неоднозначный пока для нас. Можно предложить хранить их как и ssh-ключи, с доступом только от root в linux. Предполагается, что рутовый доступ закрыт от любых пользователей.
Спасибо за отзыв!
CMDB.noc — собственная. Пу сути это база mysql, с админ-панелью. Изначально, нам нужно было хранить данные по подключенным каналам связи и провайдерам с привязкой к объекту. Там много кастомных полей, поэтому пришлось делать свое решение. Позже решили туда же добавить и сетевое оборудование, т.к. нужны связи между объектом, каналом и железом, плюс также много кастомных полей, вроде нескольких external id других систем. Использовать готовое решение сходу не получалось, не хватало необходимого функционала. Плюс, нужно было решение которое является Single Source of Truth для железа.
2) Изначально выбор был по ТЗ и цене среди предлагаемых на рынке решений для энтерпрайза. SW достаточно прост в структуре и показался очень удобным к адаптации. Там есть недостатки по API.
Сейчас я бы посоветовал присмотреться к Netbox, довольно приятное решение, можно совмещать базу оборудования и IPAM. На странице проекта как раз описан подход Single Source of Truth для системы инвентаризации.
Про NOC project, к сожалению, не могу подробно сказать. Его не использовали.
Согласен, такой же подход используем. Ошибки были в основном в нестандартных названиях в ячейках, так что Zabbix не мог их суммаризировать. Как например, скорость, 4mbps или 4096kbps. Все ради красоты)
Привет. Таких планов не было, большинство скриптов узкоспециализированые под текущую структуру файлов/выгрузок и под инфраструктуру конкретной компании. Если кто-то решит использовать данный подход в своей деятельности — это здорово, но придется это оптимизировать под свою структуру. В текущих реалиях и скорости изменений — нам придется их видоизменить, или полностью переписать в течении года.
Если говорить о Zabbix, и скриптах содержащих в своей основе API, то это скорее возможности использования инструмента на практике. И если стремиться к новой функциональности, то скорее через развитие API Zabbix, чем через скрипты использующие его.
Есть некоторые скрипты, не относящиеся к теме, которые имеют смысл для PR, в широком смысле. Однако, на мой взгляд их пока недостаточно, чтобы действительно серьезно относиться к этому как к новой функциональности.
Ну что тут сказать. Legacy, legacy, legacy. Но честности ради, у нас идет сейчас большая работа по созданию единой CMDB которая учитывает и сетевое оборудование, и провайдеров и создает связи между ними, но это отдельная совсем тема. Тут больше о том, что любую боль можно преодолеть и даже автоматизировать ее. Улучшать можно бесконечно.
Другие устройства нас интересуют в меньше степени, поэтому Zabbix для маршрутизаторов. Его задача оперативно отслеживать доступность каналов связи и каналообразующего оборудования. Коммутаторы, как и роутеры, отсылают свои данные в Splunk, это тоже больше отдельная тема. Никто не скажет про коммутатор больше, чем он сам. Но не исключаю, что мы добавим их в zabbix также при наличии необходимости.
На DHCP держим только менеджмент точек доступа. Остальной менеджмент весь статикой.
Интеграция — созданием заявок в Remedy по выбранным событиям или цепочке событий.
Ложные срабатывания это сложный вопрос. Что считать ложным? Ложных не было, бывали случаи когда пропала связь одного Zabbix-Proxy с внешним миром, и он, абсолютно обоснованно, посчитал что все объекты выпали из сети и он забил тревогу. Но это правильное поведение.
Похоже на риторический вопрос. Как IOS vs Android. В целом, изначально выбрали заббикс, а развивать дальше лучше существующее, чем постоянно менять коней на переправе. Тем более, возможностей текущего решения хватает и путей развития и масштабирования тоже масса. PRTG к тому же платный.
Рад что полезно :)
По поводу стола могу сказать, что это было давно и мы искали подходы. Не все сразу получается сделать идеально, часто находим решение, пробуем и понимаем что нам нужно что-то еще, или что-то другое.
По вопросам:
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. По мере развития постараюсь описать и этот подход, если он будет интересен.
1) Развернутого ответа пока нет. Пробуем использовать, тематика интересная пытаемся понять возможности для нас. Не все получается. Как раз ваш гайд помог начать. Спасибо:)
2) Рассматриваем различные инструменты. Для Cisco, например, есть много возможностей и многие инструменты очень удобны, в частности тот же Batfish. Но часто не получается использовать универсальное решение, так как у нас используется много оборудования HPE на платформе Comware. Для него либо нет готовых решений, либо их мало. Конкретно сейчас не используем Napalm, пытаемся написать кастомное решение под свою инфраструктуру. Но мы в этой части пока в самом начале пути, возможно мы к нему придем.
1. Nornir смотрел, но пока в качестве факультатива, в проде еще не использовали. Зависит от цели использования. Если применим в работе, то в одной из следующих статей попробую рассказать об успехе, или нет.
2. Зависит от системы. Например, для Ansible это ansible-vault. Для gitlab это внутренние скрытые переменные. Для чистого python вопрос неоднозначный пока для нас. Можно предложить хранить их как и ssh-ключи, с доступом только от root в linux. Предполагается, что рутовый доступ закрыт от любых пользователей.
CMDB.noc — собственная. Пу сути это база mysql, с админ-панелью. Изначально, нам нужно было хранить данные по подключенным каналам связи и провайдерам с привязкой к объекту. Там много кастомных полей, поэтому пришлось делать свое решение. Позже решили туда же добавить и сетевое оборудование, т.к. нужны связи между объектом, каналом и железом, плюс также много кастомных полей, вроде нескольких external id других систем. Использовать готовое решение сходу не получалось, не хватало необходимого функционала. Плюс, нужно было решение которое является Single Source of Truth для железа.
2) Изначально выбор был по ТЗ и цене среди предлагаемых на рынке решений для энтерпрайза. SW достаточно прост в структуре и показался очень удобным к адаптации. Там есть недостатки по API.
Сейчас я бы посоветовал присмотреться к Netbox, довольно приятное решение, можно совмещать базу оборудования и IPAM. На странице проекта как раз описан подход Single Source of Truth для системы инвентаризации.
Про NOC project, к сожалению, не могу подробно сказать. Его не использовали.
Если говорить о Zabbix, и скриптах содержащих в своей основе API, то это скорее возможности использования инструмента на практике. И если стремиться к новой функциональности, то скорее через развитие API Zabbix, чем через скрипты использующие его.
Есть некоторые скрипты, не относящиеся к теме, которые имеют смысл для PR, в широком смысле. Однако, на мой взгляд их пока недостаточно, чтобы действительно серьезно относиться к этому как к новой функциональности.
Другие устройства нас интересуют в меньше степени, поэтому Zabbix для маршрутизаторов. Его задача оперативно отслеживать доступность каналов связи и каналообразующего оборудования. Коммутаторы, как и роутеры, отсылают свои данные в Splunk, это тоже больше отдельная тема. Никто не скажет про коммутатор больше, чем он сам. Но не исключаю, что мы добавим их в zabbix также при наличии необходимости.
На DHCP держим только менеджмент точек доступа. Остальной менеджмент весь статикой.
Интеграция — созданием заявок в Remedy по выбранным событиям или цепочке событий.
Ложные срабатывания это сложный вопрос. Что считать ложным? Ложных не было, бывали случаи когда пропала связь одного Zabbix-Proxy с внешним миром, и он, абсолютно обоснованно, посчитал что все объекты выпали из сети и он забил тревогу. Но это правильное поведение.
По поводу стола могу сказать, что это было давно и мы искали подходы. Не все сразу получается сделать идеально, часто находим решение, пробуем и понимаем что нам нужно что-то еще, или что-то другое.
По вопросам:
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. По мере развития постараюсь описать и этот подход, если он будет интересен.