Агент получает от наблюдаемых устройств следующие данные:
Сообщения журнала Syslog. Агент получает сообщения журналов Syslog по стандартам RFC 3164 и RFC 5424. Агент преобразует сообщения в формат JSON и передаёт их по REST API в Ядро. Для сообщений от устройств, не соблюдающих указанные стандарты, Агент дополняет недостающие поля пустыми значениями. Агент приводит приоритет сообщения к одному из трёх, используемых в ППО Палладиум: (значения приоритета Syslog 6-7 (Informational, Debug) приводятся к уровню OK, значения приоритета Syslog 3-5 (Error, Warning, Notice) приводятся к уровню WARN, значения приоритета Syslog 0-2 (Emergency, Alert, Critical) приводятся к уровню ERROR). Остальная обработка и анализ сообщений журнала Syslog осуществляется в Ядре системы. В случае недоступности Ядра системы, Агент обеспечивает ограниченное хранение полученных сообщений. После восстановления связи с Ядром Агент отправляет накопленные сообщения и очищает временное хранилище. Временное хранилище реализовано в виде директории, которая подключается с хоста к контейнеру в качестве bind mount, в соответствии с Руководством по установке Агента.
Ловушки SNMP (traps). Агент получает ловушки (уведомления) от наблюдаемых устройств по протоколу SNMP, преобразует их в формат JSON и передаёт по REST API в Ядро системы. Агент приводит приоритет ловушек к одному из трёх, используемых в ППО Палладиум. Агент не преобразует SNMP Object Id (oid) в текстовое представление согласно MIB-файлу. Обработка, анализ и преобразование ловушек осуществляется в Ядре системы.
Данные, поступающие от Zabbix через потоковый протокол Zabbix Streaming Protocol. Объём, состав и фильтры данных, отправляемых по потоковому протоколу, указывается в оснастке управления Zabbix при настройке коннектора.
Результаты вывода команд из заданий (сбор конфигураций). Агент собирает вывод команд, отправляемых по SSH на наблюдаемое устройство, преобразует его в формат JSON и отправляет в Ядро системы. Обработка и анализ вывода команд осуществляется в Ядре системы.
Результаты сбора метрик ёмкости и производительности. Агент получает метрики ёмкости и производительности от наблюдаемых устройств из вывода команд, отправляемых по SSH, а также разбирая полученные JSON-файлы от OneView. Агент преобразует полученные метрики к единому формату и отсылает метрики в Ядро системы через HTTPS.
Указанные данные сохраняются в памяти Агента до момента передачи в Ядро системы. В случае недоступности Ядра системы Агент накапливает данные на локальном диске, пока Ядро системы вновь не станет доступным.
Дополнительно к указанным выше данным от наблюдаемых устройств на Агенте сохраняется идентификатор Агента и служебные файлы. Для них используется директория, подключенная с хоста к контейнеру в качестве bind mount.
Список команд, выполняемых активными задачами при сборе конфигураций и метрик, перечислен в Приложении 1 ниже.
Агент не собирает следующие данные с наблюдаемых устройств:
Пользовательские данные, хранимые на накопителях.
Имена пользователей, их пароли или хэши паролей.
Дампы памяти или других накопителей информации.
Для активного сбора метрик и конфигураций требуется настройка задач на Агенте. Настройку производит пользователь.
Ядро системы, развёрнутое в ЦОД ООО «Паладин Проекты», получает данные от Агентов и сохраняет их в локальные базы данных. Используется два типа систем управления базами данных (СУБД):
Реляционные СУБД — для хранения организаций, пользователей, наблюдаемых устройств и их атрибутов, уведомлений от наблюдаемых устройств и конфигураций используется СУБД PostgreSQL.
СУБД временных рядов (Time-series Database, TSDB) — для хранения метрик от наблюдаемых устройств используется СУБД VictoriaMetrics.
Просматривать и модифицировать хранимые в Ядре данные можно через веб-интерфейс, при этом данные, полученные от Агентов одной организации, не видны пользователям, принадлежащим к другой организации. Веб-интерфейс также позволяет добавлять данные, которые будут храниться в Ядре системы, такие как новые пользователи в пределах организации, новые устройства, атрибуты и привязки (маппинги) устройств, контакты для получения уведомлений по электронной почте и Telegram.
Ядро системы позволяет настраивать учётные данные пользователей, принадлежащих к организации Заказчика. Для настройки учётных данных необходимы следующие персональные данные:
Фамилия, имя, отчество.
Рабочий телефон.
Адрес электронной почты.
ООО «Паладин Проекты» выступает оператором персональных данных. Согласие на обработку персональных данных является необходимым условием для пользования веб-интерфейсом ППО Палладиум, доступ к которому персонифицирован.
Задачи сбора данных, таких как конфигурации и метрики, настраиваются через веб-интерфейс Ядра системы, но выполняются на Агенте. После создания необходимой задачи в веб-интерфейсе Ядра параметры задачи становится в пул для передачи на Агента. При следующем регулярном опросе Агентом в ответе указываются обновления, который необходимо применить Агенту. После обработки обновлений Агент отправляет сообщения об успехе или провале, которые Ядро сохраняет и в дальнейшем учитывает обновления успешно примененными или нет.
Такой режим работы был выбран, чтобы минимизировать количество настроек на самом Агенте. При этом программный код задач остаётся в Агенте, при настройке задач Ядро просто передаёт параметры задач, реализации которых уже имеются на Агенте. Никакого дополнительного кода на Агент из Ядра не передаётся. Новые типы задач и новая функциональность Агента может быть установлена только в ходе ручного обновления контейнера, выполняемого системным администратором Заказчика.
Новые Уведомления, получаемые Ядром системы от Агентов, сохраняются в базу данных, а для дублей увеличивается счётчик дублей. В случае, если Уведомление имеет высокий уровень критичности (ERROR), и для наблюдаемого устройства указан серийный номер, Ядро системы регистрирует обращение в Службе технической поддержки через компонент интеграции.
Аналогично Ядро сохраняет в базу данных получаемые метрики.
Ядро получает от Агентов Конфигурации, производит сравнение с предыдущей хранящейся версией, и, если есть различия, сохраняет новую Конфигурацию в базу данных. При этом предыдущая версия Конфигурации сохраняется в истории версий и доступна для сравнения.
Хранящаяся в базах данных Ядра системы информация отображается в веб-интерфейсе.