Разработчики systemd представили новую подсистему systemd-report, предназначенную для сбора и агрегации данных о состоянии Linux-систем. Инструмент консолидирует статические сведения о конфигурации оборудования и динамические метрики в единый отчет формата JSON с временной меткой. Данная разработка ориентирована на системных администраторов и управление крупными парками серверов, требующими единообразного мониторинга состояния множества узлов.
Особенности сбора данных в systemd-report
Новый функционал получает информацию от различных сервисов-провайдеров через универсальный интерфейс Varlink. Собранные данные разделены на две основные категории. Первая группа включает статические «факты»: архитектуру процессора, имя хоста, версию ядра, идентификационные данные операционной системы, объем оперативной памяти, количество ядер CPU, тип виртуализации, сведения о TPM и другие аппаратные параметры. Вторая группа охватывает динамические метрики, изменяющиеся в процессе эксплуатации: текущую нагрузку на CPU и память, среднюю загрузку системы (load average), параметры ввода-вывода дисков, использование swap, состояние сетевых интерфейсов, статистику cgroup, количество перезапусков сервисов, состояние юнитов systemd и важные сообщения из журнала.
По словам Леннарта Поттеринга, архитектура сервиса метрик была первоначально предложена компанией Meta с упором на динамические данные, но позже интерфейс расширили для включения статических характеристик. В частности, компания Amutable уже применяет этот функционал для задач управления развертыванием операционных систем.
Удаленное управление и безопасность отчетов
Подсистема разработана с расчетом на удаленное управление парком устройств. Сформированные отчеты могут автоматически передаваться на HTTPS-сервер с помощью PUT-запросов, что позволяет централизованно собирать данные в единую систему управления. Настройка включает отправку отчетов по расписанию через таймеры systemd или по системным событиям, таким как загрузка, перезагрузка или выключение машины.
Особое внимание уделено защите передаваемых данных. Отчеты могут быть криптографически подписаны перед отправкой, для чего предусмотрены три метода:
- Использование программно сгенерированного асимметричного ключа, хранящегося локально.
- Применение аппаратного TPM для создания подписи, охватывающей платформенные измерения и данные отчета.
- Использование CPU TSM-квоты для сред конфиденциальных вычислений, привязывающей отчет к измерениям защищенной виртуальной машины.
Отличия от традиционных систем мониторинга
Хотя systemd-report по набору собираемых данных может напоминать решения вроде Prometheus с его node_exporter, подход к реализации различается. Вместо использования модели «скрейпинга» (постоянного опроса), systemd получает данные непосредственно от низкоуровневых компонентов ОС. Инструмент фокусируется на создании целостных, подписанных и датированных снимков состояния системы. Леннарт Поттеринг отмечает, что эти методы не исключают друг друга и в будущем могут быть интегрированы.
Архитектура systemd-report спроектирована как расширяемая платформа. Сторонние проекты могут добавлять свои метрики или механизмы подписи, просто предоставив соответствующий сокет Varlink. Провайдеры данных могут быть написаны на любом языке программирования при условии реализации интерфейса, что превращает systemd-report не просто в утилиту вывода информации, а в полноценный фреймворк для управления инфраструктурой любого масштаба.
