Уже сегодня стартуют занятия в новой группе курса "Мониторинг и логирование: Zabbix, Prometheus, ELK" от OTUS. В течении ближайшей недели у всех желающих будет возможность присоединиться к курсу по специальной цене. Ну а прямо сейчас мы делимся традиционным переводом полезного материала по теме.
С systemd знакомы все системные администраторы. Разработанный Леннартом Пёттерингом (Lennart Poettering) и freedesktop.org, systemd представляет собой очень удобный инструмент для управления сервисами в Linux. Большинство современного программного обеспечения поставляется в виде systemd-служб.
Но что происходит, когда какая-нибудь служба падает? В большинстве случаев вы обнаружите это, когда уже нанесен какой-то ущерб.
Сегодня мы создадим дашборд для мониторинга служб systemd в реальном времени. На нем будут активные, неактивные и упавшие службы, а также реализована отправка сообщений в Slack!
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
В файле мы видим множество сообщений, вызовов методов, возвратов методов и сигналов.
Обратите внимание на строку "ActiveState" со значением "deactivating"? Это останавливается моя служба InfluxDB. Мы даже можем получить время, связанное с изменением!
Сервис org.freedesktop.systemd определяет шесть различных состояний: active (активное), reloading (перезагрузка), inactive (неактивное), failed (сбой), activating (активация), deactivating (деактивация). Очевидно, что нам особенно интересен failed-сигнал, поскольку он сообщает о сбое службы.
Теперь, когда у нас есть возможность вручную перехватывать сигналы systemd в системе, давайте создадим полностью автоматизированную систему мониторинга.
3. Архитектура и реализация
Для мониторинга служб systemd мы будем использовать следующую архитектуру:
Архитектура довольно простая. Главное — убедиться, что запущен dbus-daemon.
Далее нам необходимо создать простого клиента D-Bus (на Go!), который будет подписываться на сигналы от systemd. Все входящие сигналы будут анализироваться и сохраняться в InfluxDB.
После сохранения данных в InfluxDB мы создадим дашборд в Chronograf, отображающий статистику по службам и их текущее состояние.
Когда служба падает, Kapacitor (движок потоковой обработки) подхватывает соответствующий сигнал и автоматически отправляет сообщение в Slack системным администраторам.
Все просто! Верно?
Создание клиента D-Bus на Go
Первым шагом к перехвату сигналов, поступающих от systemd, является создание простого клиента, который будет:
Подключиться к шине
Подписываться на сигналы systemd
Парсить данные и отправлять их в InfluxDB
Примечание: вам может быть интересно, почему я выбрал Go для создания клиента D-Bus. Клиентские библиотеки dbus и InfluxDB написаны на Go, что делает этот язык идеальным кандидатом для этого небольшого эксперимента.
Код клиента достаточно длинный для того, чтобы его можно было полностью привести в этой статье, но я приведу ниже основную функцию, которая выполняет большую часть работы. Полный код доступен на Github.
Для каждого отдельного сигнала от systemd в InfluxDB создается точка. Я выбрал такую реализацию, потому что хотел иметь полную историю всех изменений, происходящих в разных службах. Это может быть весьма полезно для расследования некоторых повторяющихся сбоев в течение определенного периода времени.
Варианты реализации
Для структуры данных в InfluxDB в качестве тегов (меток) я выбрал имя службы (для целей индексации), а в качестве значения — состояние (failed, active, activating …).
Также я использую простой маппинг значений состояния в числа. Агрегатные функции IQL работают лучше с числовыми значениями, чем с текстовыми.
Примечание: в приведенном выше фрагменте кода можно заметить, что я получаю много свойств от systemd, но извлекаю только свойство "ActiveState", которое вы видели в первом разделе.
Теперь, когда у нас есть простой клиент на Go, давайте превратим его в службу, запустим и перейдем к Chronograf.
4. Дашборд для сисадминов
Когда у нас есть данные в InfluxDB, начинается самое интересное. Создадим дашборд в Chronograf отображающий статистику по службам и индикаторы для отдельных служб, которые мы хотим отслеживать.
Дашборд состоит из трех основных частей:
Количество активных, неактивных и упавших служб в данный момент времени.
Таблица, показывающая полную историю изменений состояния во времени по каждой службе.
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. Это надежные и эффективные решения для вашей инфраструктуры.
