РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА В IT

РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА В IT

Синчев Бактыгерей Куспанович

д-р техн. наук, ассоциированный проф. кафедры Информационные Системы, Международный Университет Информационных Технологий,

Республика Казахстан, г. Алматы

Жумахан Айдана Берликкызы

магистрант Международного Университета Информационных Технологий,

Республика Казахстан, г. Алматы

АННОТАЦИЯ

В любом виде бизнеса существует IT-архитектура, мониторинг работоспособности которой необходим для раннего обнаружения сбоев и наличия решений для их устранения. Сбой в работе IT-инфраструктуры для некоторых компаний приводит к простоям, которые зачастую влекут за собой материальные потери. Поэтому возникает острая необходимость в создании системы, позволяющей контролировать состояние всех компонентов IT-архитектуры компании, а также своевременно отправлять оповещения о надвигающихся сбоях в работе. Поэтому цель данной статьи в изучении процесса разработки системы мониторинга в IT сфере. Объектом данной статьи является система мониторинга.

Ключевые слова: система мониторинга, разработка, продукция, программа, интеграция.

Ю.П. Липунцов отмечает, что исправность программного комплекса была крайне важна для бизнеса компании, так как в случае его выхода из строя отгрузка произведенной продукции стала бы невозможной [1]. Для получения актуальной информации о состоянии программного комплекса необходимо было разработать систему мониторинга. Система мониторинга дает возможность информировать администратора об обнаруженных негативных тенденциях, что, в свою очередь, ускоряет реакцию администратора, а значит, повышает уровень «здорового» функционирования системы.

Мониторинг, по определению А.С. Юмин, означает: систематическое наблюдение, обнаружение изменений в системе, он охватывает изменений за определенный период времени с помощью технических средств [2]. Важно, чтобы данные регистрировались многократно через регулярные промежутки времени. Таким образом, на основе данных можно получить сопоставимые выводы. Мониторинг подразумевает не только наблюдение за процессом. Если есть какие-либо отклонения от желаемого курса, можно вмешаться, чтобы добиться регулярной работы. Любая система представляет собой набор компонентов, каждый из которых подразделяется на модули, которые в свою очередь могут быть представлены как сумма еще более мелких компонентов. Для мониторинга таких иерархических структур мы должны иметь возможность идентифицировать каждый компонент системы. Эта возможность обеспечивает следующая концепция:

- создается класс для идентификации конкретного компонента системы. Условное описание помогает четко определить, являются ли существующие объекты в системе мониторинга нужными компонентами или нет. Например, одним из наиболее распространенных типов проверки является поиск ключа в реестре.

- определяется область применения существующих объектов для проверки в системе мониторинга.

- на основе заданных параметров система мониторинга выполняет поиск по заданному критерию на заданной области объектов.

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

1. Установить оптимальное значение тайм-аута между двумя итерациями поиска объектов.

2. Выбор минимально возможного диапазона существующих объектов для поиска требуемых объектов.

3. Интенсивное использование инструментов обнаружения, согласованное с данными реестра [3].

Таким образом, все компоненты IT-архитектуры компании идентифицируются в системе мониторинга как играющие определенную роль. Если один и тот же архитектурный объект играет несколько ролей (например, один сервер используется для работы с базой данных компании и некоторым пользовательским приложением), то этот объект будет идентифицирован в системе мониторинга как многозадачный. Выявление ролей объектов мониторинга позволяет получить список ключевых компонентов системы, работоспособность которых имеет решающее значение для компании. Для построения модели обслуживания необходимо также определить взаимосвязи между используемыми компонентами. Для обеспечения работоспособности контролируемых компонентов должна быть выполнена серия проверок, позволяющих определить состояние здоровья. В общем случае такие проверки называются мониторами и делятся на три категории, такие как:

- мониторы единиц;

- мониторы зависимостей;

- агрегированные мониторы.

В IT сфере всегда есть необходимость разработки подходящей программно-аппаратной архитектуры для киберфизических производственных систем. Особые проблемы при разработке архитектуры возникают из-за горизонтального и вертикального сетевого взаимодействия. Вертикальная сеть позволяет отдельным продуктам взаимодействовать с централизованно предоставляемыми услугами. Эти услуги могут быть доступны внутри компании или между компаниями по всей цепочке создания стоимости. Однако повторное использование этих архитектур невозможно из-за отсутствия шаблонов реализации при разработке системы мониторинга. Для сервис-ориентированной платформы должны быть определены основные технологии, такие как коммуникационные протоколы (например, OPC UA, HTTP) [4]. Кроме того, в таких проектах все большее внимание уделяется аспектам безопасности. С одной стороны, важна функциональная архитектура безопасности, например, надежность системы, с другой стороны, необходимо предотвратить несанкционированный доступ к мониторингу. Так в процессе выявления описанных концепций были рассмотрены все основные этапы развития системы мониторинга, а именно:

1. Разработка модели обслуживания.

2. Реализация инструментов для обнаружения объектов мониторинга.

3. Построение карты состояния интересующей системы.

Стоит отметить, что системы мониторинга производства требуют текущих данных о производстве. Для веб-мониторинга распределенного производства необходимые данные должны передаваться через интернет. Поэтому необходима архитектура, обеспечивающая безопасный, быстрый и надежный обмен данными. Так появляется необходимость в обласных система при мониторинге. Облачные сервисы легко масштабируются и адаптируются к текущим требованиям бизнеса. По финансовым причинам и для поддержания гибкости большинство вычислительных мощностей, баз данных, систем хранения и соответствующих сетевых компонентов арендуются у поставщика инфраструктуры как услуги (IaaS). Для безопасной передачи данных между локациями используются туннели виртуальной частной сети (VPN). Это распространенное решение для подключения участников по всему миру к расширенной частной сети по защищенному каналу. На каждом объекте установлены маршрутизаторы для установления соединения с VPN компании. Туннель VPN используется для передачи данных с датчиков на сервер приложений (AS). Кроме того, передача данных защищена протоколом SSL для обеспечения более высокого уровня безопасности систем мониторинга. Сначала каждый датчик должен пройти аутентификацию на AS. После этого данные подвергаются проверке на правдоподобность. Последний шаг - сохранение значений в базе данных. Имеющиеся данные используются для расчета показателей, предиктивного обслуживания и т.д. [5] Эти расчеты могут быть выполнены крупными центрами обработки данных за короткое время. Такие сервисы, как «Google Cloud Functions», могут использовать предоставленные алгоритмы для обработки полученных данных. Счета выставляются на основе фактически необходимого вычислительного времени, что позволяет поддерживать низкую стоимость. Это делает их способными взаимодействовать с современным производственным мониторингом. Компьютеры работают под управлением минимальной операционной системы Linux без графического интерфейса пользователя. Исходный код для считывания данных с датчиков написан на языке C++. Обработка и отправка информации в AS выполняется скриптом на языке Python. AS имеет возможность передавать данные в MC через протокол Web Sockets при системной мониторинге. Это технология для поддержания постоянных соединений между клиентами и сервером. Через этот канал сервер имеет возможность отправлять сообщения подключенному клиенту. При обнаружении новых событий, МС может отправлять клиентам информацию о производстве, критических ситуациях. Это приводит к сильному уменьшению количества запросов, что снижает сетевой трафик и нагрузку на сервер. Пользователь имеет возможность активировать несколько каналов обмена сообщениями. При системной мониторинге есть возможность получать push-уведомления, а также при возникновении критических ошибок АС может включить сигнал тревоги или отправить SMS оператору.

Система мониторинга представляет собой браузерное веб-приложение и должна быть установлена на веб-сервере. Она поставляется с комплексным управлением ролями и правами, что позволяет надежно активировать функции, предназначенные для конкретного пользователя. Связь с AS осуществляется через SSL-шифрованное в HTTPS-соединении. Чтобы избежать высоких затрат, в головном офисе установлен второй маршрутизатор. Трудоемкость разработки может быть резко снижена, хотя возможно использование независимо от платформы. Универсальная архитектура может быть применена к мощной и надежной облачной инфраструктуре, что делает возможным мониторинг в реальном времени.

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

Список литературы:

1. Липунцов Ю.П. Управление процессами. - М: Компания АйТи, 2003. – 55 с.
2. Юмин А.С. Система мониторинга. – М.: Луч, 2018. – 61 с.
3. Панчин Н.В. IT решения // Новые информационные технологии. – 2019. – 2. – 40-45.
4. Гудмиров Д.Д. Разработка система мониторинга производства. – СПб, 2015. – 147 с.
5. Спиричева Н.Р. Мониторинг серверного оборудования и приложений. – Екатеринбург, 2014. – 33 с.