Хабрахабр

Система мониторинга на добыче полезных ископаемых

Одна крупная добывающая компания пришла с интересной задачей: есть множество площадок с ИТ-системами. Они расположены как в городах, так и на месторождениях. Это несколько десятков региональных офисов плюс добывающие предприятия. На 500 километров в тайге без дороги — легко! На каждом объекте есть оборудование, которое нужно «сложить» в общую инфраструктуру и определить, что и в каком состоянии работает.

Зачем? Здесь нужна была не просто техническая инвентаризация всех устройств в сети (серийники, версии ПО и пр.), а полноценная система мониторинга. п. Для того чтобы выявлять корневые причины аварий и оперативно об этом предупреждать, строить карты сети, отрисовывать связи между оборудованием, мониторить состояние железа и каналов связи, делать предупреждения по сходу с поддержки или включению нового неучтённого оборудования и т. е. Помимо этого, потребовалась интеграция с CMDB (учётом конфигурационных единиц), чтобы всё железо, которое «нашла» система мониторинга, сравнивалось с тем, что стоит на учёте в конкретном филиале, т. Также была задача разграничить видимость объектов мониторинга и полномочия групп пользователей. по факту находится в сети.
Ещё систему мониторинга нужно было «подружить» с телефонией Астериск, чтобы последняя
в случае каких-то серьёзных нештатных ситуаций типа отключения питания на площадке в Красноярске могла автоматически оперативно дозваниваться ответственным людям. Операторы смотрят за оборудованием, Москва — Москву, инженеры на месторождении — только своё месторождение.

В результате тестирования для заказчика стали ясны минусы условно-бесплатного продукта: его долго и сложно настраивать, плюс в нём не было того объёма функционала, который требовался (в части той же, например, отрисовки связей между устройствами в сети). Заказчик выбирал между несколькими системами мониторинга: 1) условно-бесплатным продуктом; 2) одним из коммерческих решений; 3) системой Infosim StableNet. У коммерческого продукта не оказалось распределённых агентов мониторинга — это которые устанавливаются на конкретной площадке и контролируют только свой «куст». Из коробки он это делать не умеет, а с плагинами получается так себе. И вот благодаря чему. Соответственно, остановились на Инфосиме — он закрыл все хотелки.

Вот так выглядит основной экран администратора InfoSim StableNet (это не проект с полезными ископаемыми, а тестовая инфраструктура).

Основной экран, на котором отображается текущее состояние сети:

Например, кнопка Analyzer позволяет вывести статистику по любому параметру, который мы собираем, — в частности, round-trip time за часовой период для конкретной железки. Слева видна панель управления, в которой мы можем настраивать систему и выводить нужную нам статистику.

Невероятно удобно: облегчается процесс поиска любого параметра оборудования в сети по серийникам, типам оборудования, версиям операционных систем и т. Кнопка Inventory выводит нам инвентарные данные объектов мониторинга, соседей, MAC-таблицу по каждому устройству, которое есть в системе. д.

Это оборудование попадает в специальную ветку в дереве устройств «Новые устройства» и автоматически — в CMDB. Когда где-то далеко в тайге местные сотрудники, например, поставили новый свитч и никому об этом не сказали, в системе это сразу же стало видно.

д. Объекты мониторинга опрашиваются не только на предмет серийников и моделей, но и на загрузку памяти, интерфейсов и т. Если чего-то не хватает, заказчик пишет нам или вендору напрямую и новые железки добавляются. Есть поддержка множества вендоров — в частности, по серверам, СХД, телеком-оборудованию, машинам конечных пользователей. Всё просто.

Вот так выглядит архитектура системы:
Система интегрируется с MS Active Directory и RADIUS-серверами для общей авторизации и применения групповых политик.

Центральный сервер отвечает за обработку и вывод статистики, собранной с железа.

Агентов (удалённое ПО) может быть несколько, у нас это геораспределённая тема, по агенту на каждую площадку. Второй важный компонент — это агент, отвечающий за опрос оборудования и проверку доступности железа. И база данных для хранения всего того, что собрали. Нужно это для того, чтобы не гонять сырой трафик телеметрии в головную организацию — у заказчика большое количество площадок подключено по дорогим спутниковым каналам, поэтому отправляется только результат замеров.

В случае недоступности удалённой площадки сотрудники на месте могут подключаться напрямую к агенту и видеть состояние своего «куста» сети даже без доступа к центральному серверу.

Мы не грузим канал пингами железа, это делает агент, и он уже агрегирует пакеты со статистикой. Агентом может выступать сервер x64/x86 с ОС RedHat, CentOS, Ubuntu, Windows Server (для крупных площадок) или же микроагент на базе маленьких ARM-компьютеров вроде Raspberry PI (для маленьких площадок).

Поэтому, если в будущем заказчик добавит какое-то другое железо, проблем у компании не возникнет — мы также сможем помочь измерить показатели качества каналов, провести синтетические тесты, нагрузочное тестирование каналов связи между агентами. Ещё мы можем снимать задержку, джиттер, вариации джиттера для оборудования Cisco (IP SLA) и Хуавей (NQA).

Она автоматически строит топологию на уровнях L2 и L3, и на основе этого автоматически настраиваются зависимости аварийных ситуаций (root cause analyze). Система мониторинга умеет принимать сислог сообщения, SNMP-трапы с железа, фильтровать их и генерировать аварийные сообщения. Например, если в цепочке из пяти свитчей один в середине отвалился, мы получим сообщение, что отвалился третий свитч (root cause), а четвёртый и пятый недоступны из-за этого. Это очень круто, так как позволяет сообщать администраторам о корневой причине аварии, тем самым снижая время, требуемое для её решения.

Так, например, для облегчения работы нашей техподдержки мы «добавили» статусы состояния бесперебойников и электропитания: если выключается питание на сайте, то вместо 30 тревог мы получаем одну по питанию. Решение работает из коробки, но процесс можно кастомизировать. Корреляция происходит по топологии, пользователям и правилам.

Прописать влан или ntp на 40 коммутаторах? Есть групповая конфигурация оборудования, можно не просто пассивно опрашивать железо, а раскатывать конфиги типа настроек на коммутаторах. Легко!

То же самое есть по трапам, по аварийным событиям. А ещё очень круто, что система позволяет заказчику бекапить конфигурацию оборудования по расписанию: раз в сутки собирать конфиги или при событии (например, приходит сислог об изменении конфигурации — можно настроить задание, которое будет отрабатывать момент наступления события и собирать изменённый конфиг). Плюс, по сути, создаётся актуальная база всех конфигураций устройств в сети. Это очень сильно поможет при «разборе полётов» и поиске основных виновников изменения конфигураций.

В нашем проекте была сделана интеграция мониторинга с CMDB 1C:ITIL Управление информационными технологиями предприятия для хранения всей информации об оборудовании (материальных активах). Есть API для интеграции. Выясняют, что это, забивают все необходимые поля — место установки, имя и др. Информация опроса сравнивается с тем, что есть в активах, при обнаружении неучтённого оборудования система говорит: «Вот тут непонятный коммутатор». Далее отправляется задача в мониторинг — изменяется имя железки в системе, выставляется на правильную позицию в дереве локаций, применяются настройки мониторинга в зависимости от типа железки (например, граничное оборудование должно опрашиваться чаще, чем остальное), изменяется хост-нейм на самом устройстве и т. Серийный номер, имя, партийный номер, версия прошивки получается от железа. д.

Процесс на местах

Первым делом мы настроили интеграцию с AD. Это облегчило нам жизнь во время внедрения, а также в последующей эксплуатации. Не надо создавать и удалять учётки для юзеров каждый раз. Система автоматически получит все активные учётки из AD. Если вдруг кто-то уволился, то система сама деактивирует эту учётку у себя и по ней больше никто не сможет зайти.

За время запуска были настроены отчёты по утилизации и доступности каналов, по доступности железок на площадках, топ аварийных ситуаций, отчёты по конкретным типам аварий, версии ОС, отчёты по изменениям конфигурации оборудования и др. Для админов и среднего менеджмента очень актуальной задачей было получение множества отчётов.

п.). Отчёты можно увидеть в формате HTML, получать их по почте в формате PDF и XLSX с нужной периодичностью (раз в сутки, неделю, месяц и т. Для разных отчётов была настроена своя периодичность и персональная адресность потребителя отчёта.

Например, мы в нашей облачной услуге мониторинга сделали Telegram-бота, который оповещает ответственных сотрудников в нашей службе эксплуатации об аварийных ситуациях. Система также имеет гибкие возможности по оповещению и выполнению кастомных действий при возникновении аварийных ситуаций, стандартно может отправлять e-mail-сообщения, эсэмэски (используя внешний СМС-шлюз), плюс писать свои скрипты, которые будут запускаться. 1. Также его можно опрашивать на предмет разных параметров: «ЦПУ, 10. 100» возвращает «95%», но с учётом поддержки мобильного приложения это может показаться немного избыточным, хотя и удобно. 1.

Теперь при возникновении мегакритичной ситуации (отключении питания на критичных площадках или ЦОД) система названивает ответственным людям на мобильные телефоны и голосом, как у Сири, говорит: «Напряжение на таком-то объекте ниже критической отметки». Далее мы написали скрипт интеграции с телефонной станцией. По сути, мы автоматизировали процесс оповещения ответственных администраторов или руководства при возникновении аварии. Делается довольно просто: авария дублируется в определённую папку на телефонной станции, где обрабатывается сервисом телефонии — надо только указать заранее номера, кому звонить автоматом. Другими словами, заменили человека, который должен позвонить и доложить об аварии.

Звонит юзер, говорит: «У меня не работает сеть». Очень удобная функция поиска пользователей и железок. По его IP-адресу можно сразу увидеть, куда он подключён (какой коммутатор, какой порт, какой мак) и куда он подключён раньше:

Нужно, например, посмотреть, где у нас стоит какой-нибудь коммутатор. Можно строить разного вида графические топологии, которые облегчают жизнь инженерам. Поддерживается несколько уровней соседства (первый — непосредственные соседи, второй — соседи соседей и т. Всё просто: нашли его в нужной ветке (или воспользовались поиском) и открыли его соседей. И сразу видно, где в топологии стоит наш коммутатор, какими портами и куда он подключён, какие мак-адреса у портов. п.). Или же посмотреть карту протоколов OSPF, BGP, EIGRP, STP, PIM, MPLS — система всё это сама обработает и нарисует.

Для удобства мы разделили части WAN и LAN площадок и отрисовываем их отдельными картами. Или же наглядно посмотреть, как себя «чувствует» сеть на одной из площадок. При наведении на них можно увидеть текущий статус и провалиться в какое-нибудь конкретное устройство. Все индикаторы и линки интерактивны. Он эту схему много раз видел как статичную картинку на бумаге или экране. Отдельно хочется обратить внимание, что в качестве подложки такого отчёта используется схема из Microsoft Visio, которую рисовал сам инженер. Очень удобно. Теперь она «оживает» и даёт обратную связь в реальном времени.

Ролей стало много, но они гибко настраиваются. В соответствии с требованием заказчика были разграничены права доступа пользователей. Учитывая разницу часовых поясов между объектами, очень пригодилась фишка рабочих часов в ролях: в какое время, по каким авариям, кому SMS и так далее.

По нашему опыту в таких случаях бывают проблемы с плановыми работами — они портят отчёты и вызывают лишние тревоги. InfoSim StableNet собирает статистику инцидентов. Да, плановые работы задним числом не объявляются. Здесь же можно отметить, что вот тут и тут будут работы: тогда тревоги пойдут в silent-режиме, а в отчёте будет отмечено другим цветом, что данный даунтайм — это план.

Например, на проекте были точки доступа Моторолы. Если не хватает возможностей из коробки, можно создавать самописные шаблоны. С помощью встроенного «визарда» мы создали шаблоны и мониторили параметры, которые хотел видеть заказчик (уровень сигнала, соотношение сигнал/шум). Готовых шаблонов под них не было.

На этот случай в системе есть функционал, который позволяет добавить новых вендоров и модели железок за считаные секунды. Был и другой случай, когда система «не понимала» одного российского производителя и показывала код производителя вместо имени.

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

  1. Мониторить доступность с помощью ICMP-пингов.
  2. Собирать инфу с помощью SNMP.
  3. Сканировать подсети на предмет появления нового оборудования.
  4. Рассылать отчёты по периодам.
  5. Осуществлять бекапы конфигураций.
  6. Анализировать доступности.
  7. «Бить тревогу» по недоступности оборудования или выходу показателей за пределы нормы.
  8. Выполнять скриптование по SNMP traps как триггерам, данным syslog’а и любым входным данным.
  9. Интегрироваться с AD.
  10. Автоматически определять связность устройств (CDP, LLDP, L3 соседство) и на основе этого автоматически рисовать карту сети.
  11. Создавать «погодные карты» для визуализации состояния сети с возможностью использования графических подложек.
  12. Создавать рабочие экраны (dashboards) для вывода оперативной информации о состоянии сети и устройств.
  13. Проводить инвентаризацию оборудования (тип оборудования, производитель, модель, версия ПО, когда настанет дата EoS/EoL и т. д.)
  14. Есть REST API для глубокой интеграции с CMDB 1C и другими внешними системами.
  15. Выполнять групповую настройку оборудования из системы мониторинга.
  16. Проверять конфигурацию устройств на соответствие политикам компании

Ссылки

— Байки первой линии поддержки.
— Каналы связи для месторождений полезных ископаемых.
— Моя почта: DDrozhzhin@croc.ru

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть