355.72
Rating
OTUS. Онлайн-образование
Цифровые навыки от ведущих экспертов

Мониторинг служб systemd в реальном времени с помощью Chronograf

OTUS. Онлайн-образование corporate blogProgrammingDevOpsSoftware
Original author: https://habr.com/ru/company/otus/blog/527918/

Уже сегодня стартуют занятия в новой группе курса "Мониторинг и логирование: Zabbix, Prometheus, ELK" от OTUS. В течении ближайшей недели у всех желающих будет возможность присоединиться к курсу по специальной цене. Ну а прямо сейчас мы делимся традиционным переводом полезного материала по теме.


С systemd знакомы все системные администраторы. Разработанный Леннартом Пёттерингом (Lennart Poettering) и freedesktop.org, systemd представляет собой очень удобный инструмент для управления сервисами в Linux. Большинство современного программного обеспечения поставляется в виде systemd-служб.

Но что происходит, когда какая-нибудь служба падает? В большинстве случаев вы обнаружите это, когда уже нанесен какой-то ущерб.

Сегодня мы создадим дашборд для мониторинга служб systemd в реальном времени. На нем будут активные, неактивные и упавшие службы, а также реализована отправка сообщений в Slack!

Дашборд для systemd
Дашборд для systemd

1. Несколько слов о D-Bus

Прежде чем перейдем к архитектурным вопросам и кодированию, давайте быстро вспомним, что такое D-Bus и как он может помочь в достижении цели (если вы эксперт по D-Bus, то можете смело переходить к разделу 2).

D-Bus — это шина межпроцессного взаимодействия, которая позволяет взаимодействовать нескольким приложениям, зарегистрированным на ней.

Приложения, использующие D-Bus, являются либо серверами, либо клиентами. Клиент подключается к серверу D-Bus, слушающему входящие подключения. При подключении к серверу D-Bus приложения регистрируются на шине и получают имя для их идентификации.

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

Назначение D-Bus поначалу может показаться немного туманным, но это очень полезный инструмент для Linux-систем.

Например, служба UPower (отвечающая за мониторинг источников питания) может обмениваться данными со службой thermald (контролирующей общую температуру), чтобы снизить энергопотребление в случае обнаружения проблем перегрева (вы этого даже не заметите).

Но какая связь между D-Bus и мониторингом служб systemd? Systemd зарегистрирован на D-Bus как сервис org.freedesktop.systemd1. Кроме того, он отправляет некоторые сигналы клиентам, когда состояние systemd-служб изменяется. И именно это мы будем использовать для нашего мониторинга.

2. Получение сигналов D-Bus

В этой статье я использую машину с Xubuntu 18.04 и стандартным ядром. На ней должен быть запущен dbus-daemon и установлена утилита busctl.

Это можно проверить запустив:

ps aux | grep dbus-daemon

В результате должно быть как минимум две записи: одна системная шина и одна сессионная.

busctl status

Эта команда проверяет состояние шины и возвращает ее конфигурацию.

Определение полезных сигналов D-Bus

Как было сказано ранее, служба systemd регистрируется на шине и отправляет сигналы, когда происходит что-то, связанное с systemd.

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

sudo busctl monitor org.freedesktop.systemd1> systemd.output

В файле мы видим множество сообщений, вызовов методов, возвратов методов и сигналов.

Сигналы на шине systemd
Сигналы на шине systemd

Обратите внимание на строку "ActiveState" со значением "deactivating"? Это останавливается моя служба InfluxDB. Мы даже можем получить время, связанное с изменением!

Сервис org.freedesktop.systemd определяет шесть различных состояний: active (активное), reloading (перезагрузка), inactive (неактивное), failed (сбой), activating (активация), deactivating (деактивация). Очевидно, что нам особенно интересен failed-сигнал, поскольку он сообщает о сбое службы.

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

3. Архитектура и реализация

Для мониторинга служб systemd мы будем использовать следующую архитектуру:

Конечная архитектура мониторинга systemd
Конечная архитектура мониторинга systemd

Архитектура довольно простая. Главное — убедиться, что запущен dbus-daemon.

Далее нам необходимо создать простого клиента D-Bus (на Go!), который будет подписываться на сигналы от systemd. Все входящие сигналы будут анализироваться и сохраняться в InfluxDB.

После сохранения данных в InfluxDB мы создадим дашборд в Chronograf, отображающий статистику по службам и их текущее состояние.

Когда служба падает, Kapacitor (движок потоковой обработки) подхватывает соответствующий сигнал и автоматически отправляет сообщение в Slack системным администраторам.

Все просто! Верно?

Создание клиента D-Bus на Go

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

  1. Подключиться к шине

  2. Подписываться на сигналы systemd

  3. Парсить данные и отправлять их в InfluxDB

Примечание: вам может быть интересно, почему я выбрал Go для создания клиента D-Bus. Клиентские библиотеки dbus и InfluxDB написаны на Go, что делает этот язык идеальным кандидатом для этого небольшого эксперимента.

Код клиента достаточно длинный для того, чтобы его можно было полностью привести в этой статье, но я приведу ниже основную функцию, которая выполняет большую часть работы. Полный код доступен на Github.

Для каждого отдельного сигнала от systemd в InfluxDB создается точка. Я выбрал такую реализацию, потому что хотел иметь полную историю всех изменений, происходящих в разных службах. Это может быть весьма полезно для расследования некоторых повторяющихся сбоев в течение определенного периода времени.

Варианты реализации

Для структуры данных в InfluxDB в качестве тегов (меток) я выбрал имя службы (для целей индексации), а в качестве значения — состояние (failed, active, activating …).

Также я использую простой маппинг значений состояния в числа. Агрегатные функции IQL работают лучше с числовыми значениями, чем с текстовыми.

Примечание: в приведенном выше фрагменте кода можно заметить, что я получаю много свойств от systemd, но извлекаю только свойство "ActiveState", которое вы видели в первом разделе.

Теперь, когда у нас есть простой клиент на Go, давайте превратим его в службу, запустим и перейдем к Chronograf.

4. Дашборд для сисадминов

Когда у нас есть данные в InfluxDB, начинается самое интересное. Создадим дашборд в Chronograf отображающий статистику по службам и индикаторы для отдельных служб, которые мы хотим отслеживать.

Дашборд состоит из трех основных частей:

  1. Количество активных, неактивных и упавших служб в данный момент времени.

  2. Таблица, показывающая полную историю изменений состояния во времени по каждой службе.

  3. 12 индикаторов, отображающих 12 различных служб systemd, на которые мы хотим обратить особое внимание.

Примечание: предполагается, что у вас есть некоторые предварительные знания Chronograf, вы знаете как его настроить и связать с InfluxDB. Документация доступна здесь.

Количество активных, неактивных и упавших служб

Вот вариант создания блока с одной метрикой:

Полная история изменений состояния

Похожим образом создаем таблицы истории:

Индикаторы для отдельных служб

Конечно же, я призываю вас поиграть с виджетами и создавать свои собственные дашборды. Ваш дашборд не должен быть точной копией представленного выше.

Теперь, когда у нас есть дашборд, мы можем мониторить systemd-службы в реальном времени. Здорово!

Но что, если бы у нас еще были оповещения в реальном времени в Slack?

5. Отправка алертов при сбое службы

Мы будем использовать Kapacitor (движок потоковой обработки), который отвечает за создание и обработку алертов в случае сбоя служб.

После установки и запуска Kapacitor, давайте вернемся в Chronograf и перейдем к панели алертов.

При нажатии на кнопку "Manage Tasks" вы увидите два раздела: правила алертов (alert rules) и сценарии (tick scripts). Давайте создадим новый алерт, нажав на кнопку "Build Alert Rule".

Ниже приведена полная конфигурация алертов:

Этот алерт настроен на отправку оповещений на веб-хук Slack'а, если в течение пятнадцати минут служба не отвечает (т.е. значение состояния равно минус единице). На стороне Slack оповещение имеет следующий вид:

6. Заключение

Я многому научился, создавая этот маленький проект. Не имея опыта работы с D-Bus и Golang, этот эксперимент научил меня, что выход из зоны комфорта (даже в программировании) — это путь к развитию новых навыков.

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

Если вам нравится создавать собственные решения для мониторинга, вы, безусловно, можете почерпнуть из этой статьи некоторые идеи. Но если вам больше нравится использовать готовые инструменты, то я бы определенно рекомендовал SignalFX или Telegraf. Это надежные и эффективные решения для вашей инфраструктуры.

Посмотреть специальное предложение

Рекомендуемые к прочтению статьи:

Tags:devopssoftware developmentdashboard
Hubs: OTUS. Онлайн-образование corporate blog Programming DevOps Software
+10
3.1k 42
Comments 1

Information

Founded
Location
Россия
Website
otus.ru
Employees
51–100 employees
Registered