Стабильный релиз INFRAX 1.0 - ситуационный центр ИТ инфраструктуры: мониторинг, подключения, инциденты и обращения

INFRAX вышел из беты и представил первый стабильный релиз с множеством обновлений относительно предыдущих версий. В этом релизе добавлен SNMP-мониторинг, задания для резервного копирования, автоматизированный контроль SLA, инвентаризация и управление активами, файловый менеджер, управление дисками и разделами на серверах, обновлённый ИИ-помощник.

Введение

У меня уже были две обзорные статьи с основными возможностями INFRAX. Если вы впервый раз видите эту систему, то имеет смысл посмотреть их:

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

INFRAX устанавливается на серверы заказчика, то есть On-premise. Данные не покидают организацию, где она установлена. Есть полнофункциональная бесплатная версия с ограничением на 100 узлов в системе и 100 пользователей. Продукт полностью российский, есть в реестре отечественного ПО. В нём частично используются open source компоненты, но вся идея и реализация полностью свои. Мне даже в голову не приходит, на что всё это может быть похоже. Не видел подобных систем.

Обновление до свежей версии

INFRAX обновляется полуавтоматически. В комплекте установки есть скрипт infrax.sh, с помощью которого можно обновить систему. Достаточно его запустить и выбрать соответствующий раздел меню.

Система полностью упакована в Docker контейнеры, так что всё обновление сводится к скачиванию и запуску новых образов контейнеров. Это всё выполняется через упомянутое меню управления. Своё состояние INFRAX хранит в СУБД PostgreSQL, так что в процессе обновления вам предложат на всякий случай сделать бэкап данных.

Более детально процесс обновления я затрагивал ранее, не буду сейчас на этом останавливаться. Перейдём сразу к нововведениям.

SNMP-мониторинг

В версии 1.0 появился мониторинг метрик по SNMP. Для этого на узле нужно настроить доступ по SNMP к устройству и создать шаблон, описывающий собираемые метрики. Можно выбрать один из готовых шаблонов или создать свой автоматически с помощью ИИ-помощника.

Покажу настройку на примере одного из свитчей. INFRAX автоматом определил, что там включён SNMP, но нужна дополнительная настройка узла, чтобы начался сбор метрик.

Перешёл в Параметры → SNMP → Шаблон мониторинга и выбрал Настроить с ИИ помощником.

Здесь ничего настраивать не надо. Можно помочь ИИшке и подгрузить файл с MIB, если он у вас есть. У меня не было. Свитч был типовой от D-Link. Помощник пошуршал с полминуты и выдал результат.

Нажал Тестировать. Все проверки прошли успешно. Применил шаблон к свитчу. Я ничего сам не настраивал. Всё было сделано автоматически. Все метрики автоматически добавились, была сформирована таблица портов на свитче.

На всякий случай сходил в веб интерфейс свитча и проверил таблицу. Всё совпадает, данные корректные.

Ну что, друзья админы. Будущее уже наступило. Теперь шаблоны для мониторинга пишет ИИ. Пообщался на эту тему с разработчиками, спросил, есть ли у них набор готовых шаблонов. Сначала хотели сделать, но практика показала, что ИИ нормально пишет шаблоны автоматически под конкретное устройство. Нет смысла создавать и поддерживать базу шаблонов.

Здесь же в таблице портов настраиваются некоторые параметры и триггеры. Я не сразу заметил эти шестерёнки, поэтому делаю на них акцент, чтобы вы не искали.

То же самое я проделал с шаблоном для сервера Dell PowerEdge R730xd. Попросил ИИ просканировать доступные OID и сделать новый шаблон. Получился с первого раза рабочий вариант.

В преднастроенных шаблонах как-будто и смысла больше нет. ИИ на ходу под популярное железо сам пишет шаблон, который можно проверить, доработать и распространить на аналогичное железо, если у вас есть однотипный набор. Причём пишет под конкретную версию железа и прошивки. Не надо об этом беспокоиться, как это бывает со стандартными шаблонами для того же Zabbix.

Резервное копирование

В новой версии INFRAX появилась возможность создавать различные резервные копии данных и настроек сетевых устройств. Поддерживается следующая функциональность:

  • Бэкап файлов на Linux и Windows, конфигурации MikroTik и сетевых устройств через SSH.
  • Инкрементальные и полные копии, дедупликация.
  • Бэкап в live режиме с помощью специального модуля ядра, либо снепшотов LVM.
  • Настраиваемое расписание - по таймеру или по факту завершения других заданий (цепочки заданий)
  • Ротация бэкапов по количеству копий и дней.
  • Запуск произвольных скриптов до и после резервного копирования
  • Отслеживание прогресса выполнения в реальном времени и возможность отмены заданий
  • Автоматическое создание инцидентов при сбоях резервного копирования

Покажу, как это выглядит на практике. Для примера возьму узел с Linux и положу бэкапы на узел с Windows. Для этого на обоих узлах должны быть установлены агенты.

Идём в раздел Бэкапы и добавляем новое задание.

Тип резервного копирования → Файлы сервера, настраиваем расписание. Не буду показывать все картинки, чтобы не загромождать ими статью. Там всё настраивается интуитивно. В качестве источника выбираем нужный узел в системе и указываем на нём директорию, которую будем бэкапить.

Затем настраиваем хранилище бэкапов. Опять выбираем узел, где будут храниться данные, и директорию.

На следующем этапе нужно будет выбрать способ создания консистентных копий. Как я уже говорил, это может быть модуль ядра BLKSNAP, который написала компания Veeam для своих продуктов и выложила в открытый доступ, либо LVM. С последним скорее всего ничего не выйдет, потому что для снепшота должно быть свободное место в VG. Если вы заранее не планировали использовать снепшоты, то вряд ли вы его там оставляли.

В моём примере модуль уже установлен. Если у вас его нет, то тут же, через веб интерфейс можно его установить и проследить за выполнением процесса:

На завершающем этапе добавления задания нужно выбрать метод и политику хранения.

После этого задание можно запустить вручную, не дожидаясь запланированного времени. За процессом можно следить в режиме реального времени:

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

В качестве источника бэкапов можно выбрать сетевое устройство. Нативно поддерживается только Mikrotik. Для остальных устройств нужно будет написать свой скрипт для выгрузки настроек по SSH.

Если выбрать Mikrotik, то ничего особо настраивать не надо. Достаточно его выбрать из списка узлов. Если же это другое сетевое устройство, то нужно будет подготовить скрипт для экспорта нужных данных.

Реализовано всё относительно просто и удобно в плане настройки. Никаких лишних сущностей - источник, приёмник и директория с данными. Если бэкап закончится ошибкой, будет автоматически создан тикет с проблемой. У меня, кстати, подобное случилось при настройке обычного бэкапа, без установки модуля ядра и использования снепшотов.

Бэкап по какой-то причине выполнялся с ошибкой. Я не стал с ней разбираться. Установил модуль ядра и сделал бэкап через него. Это рекомендуемый и более надёжный способ.

Инвентаризация активов (CMDB): актуальная карта инфраструктуры

Модуль управления активами INFRAX объединяет функции CMDB (Configuration Management Database) и ITAM (IT Asset Management). Это единая база знаний об IT-инфраструктуре вашей организации, которая позволяет вести учет всех активов - от серверов и компьютеров до программного обеспечения и лицензий, отслеживать их взаимосвязи, финансовые характеристики и жизненный цикл.

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

Добавить оборудование в базу можно вручную без его привязки к узлу сети. Для визуализации связей есть отдельное отображение в виде графа. Ниже пример автоматического построения связей на основе узлов сети. Я вручную ничего не правил. Тут в основном гипервизоры и виртуальные машины на них.

Для активов типа Серверная стойка есть свой тип визуализации и наполнения.

В качестве актива можно добавить лицензионное ПО и связать его с железом, на котором оно установлено.

Основные справочники для категорий, классов, типов, атрибутов, статусов и связей уже заполнены. Какой-то особой преднастройки для создания базы данных активов выполнять не нужно. Можно сразу заполнять реальными данными.

По всем активам ведётся журнал изменений с фиксацией действий на уровне пользователей. Можно составлять инвентаризационной описи, выполнять печать и сканирование QR/штрих-кодов.

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

Помимо активов в INFRAX можно вести:

  • Реестры поставщиков, контрактов и бюджетов с фильтрацией по проектам
  • Привязку расходов: бюджет можно связать с активами и контрактами
  • Контроль сроков контрактов (даты, продление, стоимость, поставщик)
  • Дашборд активов: истекающие контракты, превышение лицензий, амортизация
  • Экспорт отчётов по инвентарю, контрактам, лицензиям и амортизации в CSV/XLSX/PDF

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

ИИ-помощник

В INFRAX продолжили развитие ИИ-помощника, который может взять на себя часть рутины. С помощью агентов на узлах он может выполнять диагностику и настройку, выполняя команды на сервере. Его работа интегрирована в систему, так что пользоваться им удобно. Сам он ничего не делает, только предлагает к выполнению команду. Вы можете запустить её вручную, доверить выполнение агенту. Вывод работы команды вы можете разрешить передать в ИИ. Сам он этого делать не будет. То есть ИИ выступает только как помощник. Сам он без вашего ведома ничего не делает.

☝Полезной особенностью такого формата работы с ИИ является то, что он всегда в контексте. Он знает сервер, с которым собирается работать, его характеристики, нагрузку. Если это работа с инцидентом, то он знает контекст инцидента. А если это инцидент бизнес-сервиса, состоящего из нескольких серверов, то он это тоже учитывает.

Помимо этого встроенный ИИ-помощник может работать не только с сервером через установленного агента, но и с самой платформой INFRAX. У него есть инструменты для управления платформой. Он может настроить на сервере сбор какой-то метрики и добавить её в мониторинг, или решить проблему с помощью какого-то скрипта и добавить его в хранилище скриптов, а если надо, то и настроить автоматический запуск.

Занимаемое место на диске

Покажу несколько примеров, как это работает. Допустим, сработал триггер на лимит использования диска. Я открыл тикет и пообщался с ИИ. Тикет, кстати, тоже автоматически создаётся. Как это работает, я рассказывал в прошлых публикациях.

ИИ-помощник предложил команду, с помощью которой можно в консоли посмотреть занимаемое место в структурированном виде. Он может сам выполнить эту команду, либо вы. И у вас же остаётся выбор, отправить вывод команды обратно ИИ для дальнейшего анализа или нет. То есть вы полностью контролируете не только выполнение команд, но и поступающие в ИИ данные.

В данном примере через несколько итераций стало понятно, что разрослись журналы баз 1С, которые я сам почистил. В консоль можно попасть прямо из тикета. На картинках справа внизу кнопка для подключения по SSH. Удобно сделано.

Проверка и установка обновлений системы

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

Тут же видите результат.

Можете сходить и вручную всё установить, либо попросить ИИ-помощника сделать это самостоятельно. Я попросил установить обновления.

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

Тут же вы можете зайти вручную на сервер и всё там проверить. Если всё в порядке, то тикет можно закрыть. Он останется на память в качестве истории взаимодействия с узлом, к которой всегда можно вернуться.

Аудит запущенных сервисов

Рассмотрим ещё один пример. Допустим, вам достался в наследство cервер, про который вы ничего не знаете. Либо это ваш, но вы про него забыли, ничего не документировали. А теперь хотите узнать, что там работает. Задаём вопрос ИИ агенту:

“Расскажи, что работает на этом сервере. Какие сервисы и на каких портах.”

Он предложил команду на исполнение для анализа её вывода:

# ss -tlnpu | awk 'NR==1 || /LISTEN|udp/' | head -80

Выполняем и отправляем ему результат. Потом смотрим заключение.

В принципе, всё по делу. Но вижу, что некоторые сервисы он пропустил, потому что там ещё кое-что работает. Смотрю рассуждения ИИ-помощника. Они есть тут же, в тикете:

То есть он всё проанализировал, но вывел информацию только по его мнению по основным сервисам. Прошу вывести по всем. Он дал ещё одну команду для выполнения и потом вывел все сервисы. До этого он пропустил Apache и Infraxagent.

Ниже ещё несколько наглядных примеров задач, которые можно эффективно решить с помощью ИИ-помощника.

Мониторинг PostgreSQL

Запрос к ИИ:

“На этом сервере крутится PostgreSQL, но мы его никак не мониторим. Настрой.”

ИИ сначала разведывает. Запускает:

# pg_isready
# psql -V

Проверяет, слушает ли порт 5432. Затем предлагает скрипт, который проверяет ключевые метрики: количество активных подключений (SELECT count(*) FROM pg_stat_activity), размер базы, наличие долгих запросов (дольше 30 секунд), статус репликации. Генерирует готовый bash-скрипт, предлагает сохранить его в библиотеку скриптов INFRAX и поставить на расписание каждые 2 минуты. Админ подтверждает - мониторинг работает.

Мониторинг кодов ответов и время отклика запросов в Nginx

Запрос к ИИ:

“Хочу видеть, если на нашем API начнут расти 500-е ошибки или время ответа превысит 2 секунды.”

ИИ проверяет формат логов:

# head -5 /var/log/nginx/access.log

Определяет формат, генерирует скрипт, который парсит access.log за последние 5 минут и считает долю 5xx-ответов и средний $request_time. Пороги: алерт, если 5xx > 5% или среднее время > 2 секунд. Сохраняет, ставит на расписание каждые 5 минут.

Аудит безопасности сервера

Запрос к ИИ:

“Проверь этот сервер по базовым критериям безопасности: открытые порты, пользователи с sudo, устаревшие пакеты, SSH-конфигурация.”

ИИ последовательно выполняет:

# ss -tlnp 
# grep -Po '^sudo.+:\K.*$' /etc/group
# cat /etc/ssh/sshd_config | grep -E 'PermitRoot|PasswordAuth|Port'
# apt list --upgradable 2>/dev/null | wc -l

Выдаёт сводку: “Root-логин по SSH разрешён, парольная аутентификация включена, 47 пакетов требуют обновления, пользователь testuser имеет sudo без ограничений”. Предлагает конкретные шаги по исправлению каждого пункта.

И так далее. Думаю, принцип взаимодействия с ИИ в рамках системы INFRAX понятен. Всё примерно так же, как и в чатах с ИИ, но тут по-умолчанию для ИИ указан контекст и есть простая передача результатов его работы обратно в обработку. Не нужно тратить время и токены для погружения.

Удалённый доступ к рабочим станциям

В новой версии INFRAX появилась возможность подключаться к рабочим станциям, где установлен агент. Реализовано это на базе доработанного VNC сервера в агенте. И всё это увязано между собой - учётка пользователя, его компьютер, заявка.

Допустим, пользователь создаёт тикет с какой-то проблемой. INFRAX знает его учётку, знает к какому компьютеру она привязана. А компьютер через агента обновляет информацию о себе в системе, даже если у него динамический IP адрес. В итоге сотрудник техподдержки из заявки пользователя имеет возможность напрямую подключиться к его компьютеру.

Подобное подключение напрямую через агента доступно и для серверов. Это будет актуально, если по каким-то причинам подключение по стандартным протоколам, типа SSH или RDP не работает, например, из-за ошибки в настройках. Вы как-будто подключаетесь напрямую к консоли сервера.

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

Заключение

Статья большая получилась. Не буду подробно останавливаться на остальных нововведениях. Кратко упомяну их:

  • Автоматический контроль SLA с уведомлениями, автоматической привязкой к инцидентам, с гибкой настройкой в зависимости от категории услуги, по которой делается заявка.
  • В INFRAX можно выполнять базовые действия с дисками на серверах - просмотр разделов, создание, удаление, форматирование, работа с LVM и некоторые другие действия. Добавив диск к виртуальной машине можно его тут же в INFRAX примонтировать к системе.
  • Появился десктопный клиент под Windows, Linux, MacOS для подключения к веб интерфейсу. По сути тот же браузер, только для одного приложения. Удобно, если надо изолировать работу в INFRAX от остальной деятельности.
  • Автоматический импорт из Confluence - загрузка статей и пространств из Confluence в базу знаний INFRAX

Система очень активно развивается и обрастает полезной функциональностью. Я сталкивался с некоторыми багами, которые передавал разработчикам. Не стал об этом писать в статье, так как нет смысла. Все те баги, что я упоминал в прошлых статьях, уже исправлены. Так же будет скорее всего и тут. В ближайших релизах замеченные ошибки будут скорее всего исправлены и потеряют актуальность в статье.

Напомню, что INFRAX полностью бесплатен без каких-либо ограничений для 100 узлов и 100 пользователей. ИИ оплачивается отдельно через личный кабинет. Стоимость будет зависеть от используемого режима модели. Я тестировал самую первую джун и вторую - мидл. В среднем у меня получился один запрос к джуну 1-1,5р., к мидлу 2-5 р.

Подобная система управления будет особенно актуальна тем, кто занимается технической поддержкой. Она закрывает практически все потребности такого рода деятельности.

Реклама, ООО «Аудит-Телеком», ИНН 7733293872, erid: 2SDnjdAN8y7

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

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

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

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Много интересного в канале автора в Telegram →
This is default text for notification bar