Журналы Systemd: как следить за ними с помощью Pandora FMS

Регистры systemd, без исключения, можно проконтролировать в приведенном ниже доказательстве концепции. Но что такое systemd и как она работает?

Я хотел бы заранее сказать, что не хочу создавать никаких разногласий, я буду держать свое мнение о systemd при себе. Еще в 2014 году, когда я официально посвятил себя изучению свободного программного обеспечения, я получал уроки от преподавателей и профессоров, которые “выросли”, используя процесс инициализации (инициализация или просто init) под названием sysvinit (также известный как инициализация System V, System V или SysV); это для Debian, который был дистрибутивом, который мы изучали. Я вкратце опишу, что сделало Sysvinit таким особенным.

Sysvinit

Sysvinit был программой init, которая после того, как ядро Linux было загружено в память и готово к работе, занималась запуском остальных процессов (другими словами, тем, что делает каждый init). Он был напрямую вдохновлен Unix® System V и, что неудивительно для нас, конфигурировался с помощью файлов, которые должны были находиться в правильном порядке, чтобы запустить все необходимое на сервере. Например, нам нужно было загрузить сетевые интерфейсы, прежде чем мы могли загрузить какие-либо сетевые службы. Когда все было запущено, sysvinit завершал работу, освобождая ресурсы памяти: sysvinit был “чао и до свидания”. Все остальное, что нам было нужно, выполнялось по нашему прямому приказу. Это был медленный и очень упорядоченный процесс, но сколько раз мы перезагружали сервер GNU/Linux® за день, неделю или месяц? “Стоимость” запуска позже принесла свои плоды в виде производительности.

Еще одна особенность заключалась в том, что процесс был последовательным: как только служба или демон сообщали, что они готовы и запущены, переходили к следующей. Это было основной критикой; такие простые вещи, как синхронизация времени с другим сервером (Network Protocol Time), останавливали весь процесс загрузки, если сетевой кабель был отключен или отсутствовало подключение к Интернету, или если сервер времени был отключен или находился в автономном режиме (или по любой другой причине).

Помимо всего этого, мы также должны учитывать затраты на выполнение BASH-скриптов, которые снова и снова вызывают одни и те же функции (cat, grep, и т.д.). Мы считаем, что его легко писать и программировать, но мы не переводим его на машинный язык, что также замедляет работу системы при запуске.

По этой причине в Ubuntu 6.10 был разработан init под названием Upstart, но это уже другая история, поскольку грядут другие изменения…

Systemd

В мире GNU/Linux регистр имеет большое значение, поэтому systemd написан как есть (не путать с System D, который является чем-то другим). Она была основана в 2009 году в основном Леонардом Поттерингом (очень активным в социальной сети Twitter), Кеем Сиверсом (работал в Novell), Харальдом Хойером (работает в Red Hat) и Дхавалом Гиани (бывший сотрудник IBM).

Fedora 15 стала первым дистрибутивом, использующим этот новый init: Что сделал – что делает – systemd по-другому? Я выражаю своими словами, с извинениями для инженеров, выпускников и компьютерщиков, следующее.

Как вы знаете, слово “программное обеспечение” полностью ассимилировано в нашем испанском языке, поскольку существуют современные понятия, которые трудно перевести, и поэтому они становятся “собственными существительными”. Так обстоит дело с розетками, что в переводе с английского означает “полости”, которые с появлением электричества стали обозначать электрические розетки: полость, куда вставляется вилка, которая в свою очередь подключается к кабелю. Иногда слово сокет используется (в архитектуре – основание здания, скульптуры и т.д.) для обозначения места, куда вставляется центральный процессор: “процессорный сокет”. Но, чтобы избежать путаницы, я думаю, что лучше продолжать использовать англицизм socket…

В Unix® понятие сокета существует для обозначения точки, где одно приложение подключается к другому; существуют даже веб-сокеты для той же цели, но расположенные на разных компьютерах.

Что ж, systemd делает то, что сначала создает сокеты, а потом демонов. Да, как в старой шутке “что появилось первым, курица или яйцо”. Когда это сделано, демоны запускаются таким же образом, один за другим, и когда сокет, владелец которого -daemon- не запущен, запрашивается другим демоном, подождите, пока он будет готов, и все!

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

Вспомните, что работа systemd заключается в загрузке каждого демона, но что произойдет, если один из них выйдет из строя? Systemd должен иметь возможность завершить и перезапустить его, и вот тут-то и возникают проблемы: запустил ли этот демон сам себя? Вы запустили другой экземпляр? Это большая проблема для systemd, потому что он не знает, вырос ли демон, эволюционировал, развился и работает совершенно нормально.

Решение этой проблемы было представлено годом ранее, и нет, оно не имело никакого отношения к systemd: это были контрольные группы (позднее сокращенно cgroups).

registers-systemd
Systemd-компоненты (Изображение любезно предоставлено Wikimedia Commons, CC BY-SA 3.0)

Как видите, cgroups, autofs и kdbus прочно вошли в ядро Linux. Мне бы очень хотелось рассказать вам о графике в целом… Я лишь делаю оговорку, что это изображение может не соответствовать архитектуре сердца *nix.

Возвращаясь к cgroups, этот элемент был создан для размещения “контейнеров” как способа контроля ресурсов (памяти, использования процессора и т.д.) процессов. Это привело к появлению Docker и его самых известных “оркестров”: Kubernetes и Podman (более эффективные виртуальные машины, которые согласованно работают в кластерах).

Таким образом (и я описал это в очень общих чертах) systemd может абсолютно контролировать все, что происходит под ее управлением, и, как всякая власть ослепляет, следующий шаг (“диктаторский режим”) systemd вот-вот начнется.

Альфа и омега

Самая сильная критика systemd заключается в том, что она стала первой и последней, альфой и омегой в мире ядра Linux. Вы знаете старую поговорку “не кладите все яйца в одну корзину”: systemd – это первый идентификатор процесса один (Process IDentifier 1 или PID 1), а затем все остальные процессы, которые со временем завершаются и, наконец, systemd выключает компьютер.

В течение всего времени, пока компьютер включен, systemd отвечает за поддержание работы всех служб и следит за их производительностью: для всех них он имеет свой сокет, готовый запустить процессы, если получит какой-либо запрос. Например, bluetooth – это то, что мы вряд ли когда-нибудь будем использовать на сервере; поэтому сокет будет создан, но пока мы действительно не подключим устройство, он не будет запускать никаких программ (несмотря на эту схему, недоброжелатели systemd отмечают, что это также потребляет некоторое количество памяти и циклов процессора).

Для Pandora FMS в режиме кластера высокой доступности(Pandora FMS HA) systemd чрезвычайно важен: он отвечает за обеспечение постоянной работы службы pandora_ha для мониторинга кластера серверов (перезапуск Pandora FMS HA, при необходимости).

Некоторые из наиболее важных дистрибутивов Linux, кроме Fedora (и мира Red Hat), используют systemd:

Однако я должен отметить (хотя я всегда говорю здесь о sysvinit в прошедшем времени), что на момент написания статьи существует дистрибутив на базе Debian, который все еще использует его (и openrc, еще один необязательный init): Девуан. Невероятно, но сервер Devuan можно установить в автономном режиме на компакт-диск объемом 670 мегабайт. Если мы хотим, мы можем загрузить на диски графический интерфейс, такой как Xfce или MATE (доступно больше графических интерфейсов).

Единицы в systemd

Если перейти к общим особенностям systemd, то для запуска и мониторинга системы она использует так называемые блоки:

  1. service: помимо заботы обо всех демонах, он также поддерживает поддержку SysV скриптов, в случае, если какая-либо программа использует эту технологию.
  2. розетка: о чем я уже говорил выше.
  3. устройство: для работы и управления устройствами.
  4. mount: Этот диск инкапсулирует точку монтирования в иерархии файловой системы. Systemd отслеживает все точки монтирования по мере их появления и удаления, а также может использоваться для монтирования и демонтажа точек монтирования, для обеспечения избыточности.
  5. automount: Этот тип диска инкапсулирует точку автоматического монтирования в иерархии файловой системы.
  6. целевой: этот тип единиц используется для логической группировки единиц; вместо того, чтобы делать что-то самостоятельно, он просто ссылается на другие единицы, которые, таким образом, могут управляться вместе.
  7. снимок: подобно целевому блоку, снимки ничего не делают сами по себе, и их единственная цель – ссылаться на другие блоки. Они полезны для хранения состояний или контрольных точек, которые могут быть восстановлены в случае чрезвычайной ситуации или по запросу пользователя.

Я рекомендую прочитать статью, посвященную демистификации systemd, опубликованную в ответ на значительное количество ее противников.

Реестры Systemd и Pandora FMS

Если мы когда-нибудь захотим внести свой вклад в разработку кода systemd, мы можем начать с чтения стандартов кодирования (стиля написания программ) на их официальном сайте GitHub. Там вы найдете восхитительные детали, например, что для отступов нужно использовать восемь пробелов (хотя есть и исключения), или гораздо более важные вещи, например, какие конкретные функции языка Си нужно использовать.

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

Итак, давайте будем практичными, во-первых, журналы systemd создаются в двоичном формате и готовы к отправке через интернет на любую другую машину, которую мы назначили для их получения… это напоминает нам о syslog (в частности, syslog-ng, новое поколение syslog которая добавила сетевую пересылку регистров). По умолчанию журналы systemd хранятся в “/var/log/journal”, и мы можем увидеть их размер с помощью команды sudo journalctl -disk-usage.

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

Начиная с версии 7.0 NG 712, Pandora FMS включает ElasticSearch для хранения информации журналов, а с обновления 717 Pandora FMS 7.0 NG появляется новый компонент: Pandora FMS SyslogServer. Основное преимущество Pandora FMS SyslogServer заключается в том, что он дополняет унификацию журналов. Этот компонент позволяет Pandora FMS анализировать syslog машины, на которой он расположен, анализируя его содержимое и сохраняя ссылки в нашем сервере ElasticSearch.

С помощью этого мощного инструмента мониторинга мы можем настроить syslog-ng на прямое чтение журналов systemd. Или, что еще лучше, настройте файл journalald.conf на пересылку сообщений в syslog-ng. Существует множество дополнительных деталей, но эта статья не претендует на роль руководства или вики: точные инструкции можно найти в документации обеих программ.

registers-systemd
Настройка ведения журнала systemd в syslog в journald conf

Реестры Systemd и контейнерная виртуализация

Дополнительно мы можем контролировать контейнеры и/или Docker (один или оба одновременно), поскольку обычно в такие виртуальные машины не добавляют systemd для экономии памяти и процессорных циклов. Опять же, вы можете прочитать точные детали в этой ссылке для Docker и здесь для systemd-machined.service. Всегда помните, что у нас есть Pandora FMS SyslogServer и ElasticSearch для обработки огромного количества данных и/или информации, которые мы будем получать, и обратите внимание на сетевой трафик, который также увеличится.

Pandora FMS Systemd Регистры и агенты Программное обеспечение

Наконец, мы можем запрашивать журналы systemd с помощью команды journalctl и фильтровать информацию с помощью BASH и его GNU-команд. Допустим, мы хотим видеть последние запуски и остановки нашего оборудования.
registers-systemd
sudo journalctl -list-boots

Мы можем фильтровать по дате с помощью параметров -since, не только передавая дату, но и используя команды с кавычками: если мы хотим увидеть записи за вчерашний день, мы используем -since “yesterday”; или выбрать по единицам измерения, например, с помощью -unit service.

Программные агенты Pandora FMS – это небольшие установленные программы, которые извлекают метрики с минимальным воздействием на наше оборудование. Мы также можем просмотреть соответствующие журналы systemd с помощью команды systemd analyze blame:

registers-systemd
системный анализ вины

Даже за треть секунды программный агент Pandora FMS (как видно из примера выше) может извлечь важные данные. С помощью journalctl мы можем экспортировать наши запросы в формате JSON, чтобы их могли анализировать другие программы и быстро извлекать точные данные и поля (это известно как программный парсер) для ответа на плагин, который мы разработали для программных агентов Pandora FMS.

В этой замечательной статье приведены примеры использования BASH и разработки модулей для программных агентов Pandora FMS, которые будут выполняться на небольшом компьютере Raspberry model board. Надеюсь, вам понравится.

Также популярный язык программирования Python имеет библиотеки, к которым мы можем обращаться:

from systemd import journal

Таким образом, вы можете получить прямой доступ к записям systemd без использования journalctl и передать результаты в Pandora FMS Software Agent.

Прежде чем мы попрощаемся, помните, что вы можете узнать больше о том, что может предложить вам Pandora FMS, нажав здесь.

Если вам необходимо контролировать более 100 устройств, вы также можете воспользоваться БЕСПЛАТНОЙ 30-дневной демонстрацией Pandora FMS Enterprise. Получите его здесь.

Не стесняйтесь присылать нам свои запросы. Сотрудники Pandora FMS будут рады помочь вам!

Shares