Watchdog linux что это

Обновлено: 06.07.2024

Guido нравится Linux за возможность изучать работу компьютеров. Linux из-за своей открытости позволяет проводить такие исследования.

Устройство мониторинга сервера "watchdog"

Кнопка выключения сервера
Устройство мониторинга состояния сервера

Что же это за устройство мониторинга (watchdog)?

Устройство мониторинга, ( оригинальное и более распространенное название watchdog - по-русски "сторожевой пес"), это такая штука, которая постоянно контролирует состояние системы и проверяет ее работоспособность. Нечто подобное установлено на зонде Mars Pathfinder (ведь никто не собирался отправлять на марс вместе с роботом человека, чтобы периодически перезагружать систему когда она зависнет) и на некоторых особо дорогостоящих серверах.

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

Но тогда встает следующий вопрос: зачем тогда слежение за компьютером, если Linux до такой степени надежный и стабильный? Ответ так же прост - чтобы сделать его еще более надежным и стабильным. Всегда остается человеческий фактор, с которым всегда приходится считаться. Ведь если сервер в течении года работает без сбоев обслуживающий персонал и не знает о его существовании. И в случае поломки первый вопрос будет: "Где он находится?". А как насчет того что сервер полетел под новый год, когда все уже разбежались отмечать? В подобных случаях дополнительный мониторинг придется как нельзя кстати!

Да, подобное устройство мониторинга не решит всех проблем и не защитит от поломок железа, а если вы решили укомплектовать ваш сервер мониторингом, то вам также следует позаботиться и о дополнительном пространстве (имеется ввиду пространство для достаточной вентиляции помещения ).

Использование мониторинга

Средство мониторинга системы, которое мы будем собирать, предназначено для проверки жизнеспособности пользовательских приложений. Ведь для обеспечения надежного функционирования системы надо быть уверенным в стабильности таких приложений как веб-сервер или база данных, кроме того контролировать расход дискового пространства, возможно даже температуру CPU.Для подобных вещей предназначен crontab. И подобные вопросы уже были описаны в статье ЖК-панель управления для Вашего сервера на Linux . Поэтому мы на этом не задержимся.

Нечто подобное поможет вам контролировать ресурсы сети, использование свопа и дискового пространства.

Можно использовать этот скрипт вместе с crontab так что он будет запускаться каждые 15 минут:

Аппаратная часть

Стандартных реле не бывает. У каждого производителя свои модели. Для нас существенно сопротивление катушки реле. Ниже представлены две схемы, одна с реле на 5V, 500 Oм, а вторая на 5V, 120 Oм. При покупке поинтересуйтесь сопротивлением катушки реле или просто измерьте его омметром. Кликните на картинку чтобы увеличить.

Схема для реле на 120 Oм :

Схема для реле на 500 Oм:

Кнопка выключения замыкает при нажатии RTS и CD. На схеме она выглядит несколько странно, но в Eagle других символов нет.

Я не привожу список необходимого оборудования. Все что будет необходимо купить есть на схеме, только не забудьте разъем DB9 для последовательного порта. Диоды подойдут любые, например 1N4148. Лично я считаю что лучше установить реле на 500 Oм, тогда вам не понадобятся R4 и конденсатор на 2000мкФ (или 2200мкФ). А для С1 можно использовать конденсатор меньшего номинала (1000мкФ).

Принцип работы

Схема построена на таймера NE555. Микросхема представляет из себя два компаратора, RS-триггер и делитель из 3 резисторов 5 кOм, задающий пороги срабатывания компараторов. Всякий раз, когда на ножке 6 (threshold) напряжение поднимается выше 2/3, выход RS-триггера переключается в состояние "1".

Теперь рассмотрим нашу схему. Выход RTS последовательного порта используется как источник питания нашей схемы. Уровни напряжений в канале RS232 составляют +/-10V, и поэтому нам понадобится диод перед конденсатором С1. Конденсатор C1 заряжается очень быстро и выступает в качестве аккумулятора энергии для последующего кратковременного включения реле. Конденсатор C2 медленно заряжается через резистор ( 4.7 MОм ). Транзистор Т1, управляемый по линии DTR последовательного порта, разряжает конденсатор C2.В случае пропадания сигнала, из-за того что компьютер подвис, конденсатор медленно ( примерно в течении 40 сек. ) начнет заряжаться до 2/3 питающего напряжения, после чего RS-триггер перейдет в состояние "1".

Цепь С1, R2, светодиод и реле должна быть рассчитана таким образом, чтобы реле включалось кратковременно и только за счет энергии запасенной на конденсаторе С1. Нам необходимо чтобы "кнопка сброса" была "нажата" пару секунд.

Светодиод должен гореть до полной перезагрузки компьютера.

На схеме также изображена кнопка выключения компьютера подключенная к линии CD последовательного порта. Если удерживать ее около 15 секунд, будет выполнена команда "shutdown -h now", которая и выключит сервер. Она не имеет ничего общего с мониторингом и предназначена исключительно для обслуживания компьютера.

Программное обеспечение

Драйвер представляет собой небольшую программу на С, которую можно запускать из /etc/init.d/. Она включит сигнал на линии RTS RS232, после чего начнет периодически ( каждые 12 сек. ) посылать импульсы по линии DTR (таймаут составляет 40 секунд). При нормальном выключении компьютера программа отключит RTS и передаст последний импульс на DTR. В результате конденсатор цепи питания С1 к моменту истечения таймаута полностью разрядится, исключая возможность принудительной перезагрузки. Для установки программы, распакуйте файл linuxwd-0.3.tar.gz и наберите

После этого скопируйте исполняемый файл linuxwd в /usr/sbin/linuxwd. Подправьте созданный linuxwd_rc скрипт (для redhat/mandrake, или linuxwd_rc_anydist для любого другого), укажите порт, к которому подключено наше устройство (ttyS1=COM2 или ttyS0=COM1). Скопируйте скрипт в
/etc/rc3.d/S21linuxwd
и
/etc/rc5.d/S21linuxwd

Тестирование

После того как вы все распаяли, проверьте систему на работоспособность перед тем как подключить ее к компьютеру. Подключите вывод, который будет позже подключен к линии RTS последовательного порта, на 40-50 секунд к блоку питания на 9-10V DC. Вы должны услышать щелчок при включении реле и должен загореться светодиод. Затем реле должно выключиться, а светодиод продолжать гореть до тех пор пока вы не подадите +10V на вывод, который будет позже подключен к линии DTR последовательного порта.
После того как вы все проверили, подсоедините все это к компьютеру. Программа linuxwd имеет режим тестирования, в этом режиме она может выводит данные на экран и останавливаться на время после выдачи импульса в линию DTR для эмулирования подвисания системы. Выполните команду:

linuxwd -t /dev/ttyS0

для запуска linuxwd в режиме теста (если оборудование подключено к COM2, укажите /dev/ttyS1).

Список некоторых файлов которые будут установлены в систему:
/etc/init.d/watchdog
/etc/init.d/wd_keepalive
/etc/watchdog.conf
/etc/default/watchdog
/dev/watchdog
/usr/sbin/watchdog
/usr/sbin/wd_identify
/usr/sbin/wd_keepalive
/usr/share/doc/watchdog/
/usr/share/man/man5/watchdog.conf.5.gz
/usr/share/man/man8/watchdog.8.gz
/usr/share/man/man8/wd_identify.8.gz
/usr/share/man/man8/wd_keepalive.8.gz

Возможные параметры конфига /etc/watchdog.conf:
interval =
Интервал между двумя операциями записи в watchdog устройство. Значение по умолчанию составляет 10 секунд. Интервал больше минуты может быть использованы только параметром -f из командной строки.

logtick =
Если пишутся логи, можно пропускать запись событий каждое указанно количество интервалов. Например если logtick = 60 и interval 10, получится 600 секунд, то есть в логируемый файл будет добавляться запись не чаще одного раза в 10 минут.

max-temperature =
Установка максимально разрешенной температуры.

watchdog-device =
Установка имени устройства.

temperature-device =
Установка имени устройства температуры.

file =
Файловый режим, проверка файлов.

change =
Интервал времени для файлового режима.

ping =
Режим пинга, для проверки сетевых соединений. Опция может быть использована более одного раза.

interface =
Установка имени сетевого интерфейса.

test-binary =
Выполнение пользовательского теста.

repair-binary =
Выполняется при невозможности перезагрузки системы.

admin =
Адрес email для уведомлений, можно оставить значение пустым для отключения.

realtime =
Yes для невозможности выгрузки watchdog из оперативной памяти.

priority =
Установка приоритета для режима realtime.

Пример настройки с Intel TCO Watchog Timer.
Загрузка модуля:

В /etc/watchdog.conf должно быть раскоментировано/добавлено:

В /etc/default/watchdog указать имя модуля:

Можно добавить опцию отладки чтобы в syslog журнал писалась отладочная информация:

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

В итоге мы получили устройство, которое подключается к расширительному спаренному USB-разъему на материнской плате.

Данное устройство имеет следующие возможности:

Имитация нажатия кнопок POWER и RESET;
Управление питанием USB-устройством (при условии, что у него нет отдельного источника);
Управление гальванически развязанной контактной группой (реле). Можно поставить в разрез цепи питания;
Индикаторные светодиоды (одним можно управлять, второй показывает режимы работы).

Алгоритм работы прост: внутри находятся два настраиваемых таймера, которые постоянно отсчитывают заданное время, по истечению которого имитируется нажатие соответствующих кнопок (POWER и RESET). Чтобы предотвратить случайную перезагрузку, необходимо периодически послать команду сброса таймера.

Лучше, чтобы за процедуру сброса таймеров отвечало целевое приложение, а не стороннее или системное (Cron, служба расписаний) по причине того, что вероятность сбоя в системе меньше, чем в приложении (хотя, у кого как).
Обмен информацией аналогичен консольному.

команда	Описание	Пример
help	Краткая справка по командам	help
LED1	Управление светодиодом, по умолчанию выключен	LED1 ON LED1 OFF
RELAY	Управление реле, по умолчанию включено	RELAY ON RELAY OFF
KEY1	Имитация нажатия кнопки 1, по умолчанию не нажата	KEY1 ON KEY1 OFF
KEY2	Имитация нажатия кнопки 2, по умолчанию не нажата	KEY2 ON KEY2 OFF
C1	Управление таймером 1, связанным с кнопкой 1. Установка времени в секундах, максимальное значение 32767. Для отключения функции таймера, необходимо задать время равное 0.	C1 RES C1 SET 60 C1 SET 0
C2	Управление таймером 2, связанным с кнопкой 2. Установка времени в секундах, максимальное значение 32767. Для отключения функции таймера, необходимо задать время равное 0.	C2 RES C2 SET 60 C2 SET 0
USB	Управление питанием USB, по умолчанию включено	USB ON USB OFF

В случае удачного выполнения команды возвращает «OK».
В случае некорректных данных возвращает «ERROR».
Признаком конца строки служит символ возврата каретки «\r». Также поддерживается режим «\r\n».

Устройство выполнено на базе контроллера STM32F103CA с аппаратной поддержкой USB. Библиотека работы с USB версии V4.0.0. Напряжение работы 3.3В получаем с помощью линейного стабилизатора из 5В на USB. Во всех управляющих цепях используются транзисторы в ключевом режиме. Также не забываем про защитный диод от токов самоиндукции в катушки реле (в моем случае он оказался встроенным).

Установка

Можно взять готовую версию из PIP:
$ pip install watchdog
Сам PIP ставится как пакет python-pip, порт devel/py-pip, etc.
Либо собрать из исходников через setup.py.

Достаточно подробно все расписано в оригинальном руководстве. Правда там описание версии 0.5.4, а сейчас актуальна 0.6.0. Однако, вся разница в правке копирайтов и замене отступа в 4 пробела на отступ в 2. «Google code style» :)

Вообще, там довольно много особенностей сборки по версиям самого python так и по целевой платформе. Они все описаны по ссылке выше, но если будет нужно, допишу в статью вкратце на русском.

Кроме того, собрать модуль можно на несовместимой ОС, но тогда в дело вступится fallback-реализация, делающая «слепки» структуры ФС с последующими сравнениями. Возможно, так кто-то и делал у себя при решении подобной задачи :)

Сам же я пробовал собрать под ubuntu 11.4 и freebsd-8.2 RELEASE, каких-либо проблем при сборке и работе не возникло.

Базовый пример

Предположим, что нас интересуют изменения по некоему пути /path/to/smth, связанные с созданием, удалением и переименованием файлов и директорий.

Класс Observer выбирается в /observers/__init__.py исходя из возможностей вашей ОС, так что нет необходимости самостоятельно решать, что же выбрать.
Класс FileSystemEventHandler является базовым классом обработчика событий изменения. Он мало что умеет, но мы научим его потомка:

Полный список методов можно увидеть в самом FileSystemEventHandler.dispatch: on_modified, on_moved, on_created, on_deleted.

Запускаем это все:

Observer является относительно далеким потомком threading.Thread, соотвественно после вызова start() мы получаем фоновый поток, следящий за изменениями. Так что если скрипт сразу завершится, то ничего толкового мы не получим. Реалиация ожидания зависит в первую очередь от применения модуля в реальном проекте, сейчас же можно просто сделать костыль:

Ждем событий изменений ФС до прихода Ctrl+C (SIGINT), после чего говорим нашему потоку завершиться и ждем, пока он это выполнит.

Запускаем скрипт, идем по нашему пути и:

На выходе скрипта имеем:

В методы нашего класса Handler в поле event приходят потомки FileSystemEvent, перечисленные в watchdog/events.py.
У всех есть свойства src_path, is_directory, event_type («created», «deleted», и т.п.). Для события moved добавляется свойство dest_path.

Ну если вы больше ничего не хотите… А разве ещё что-нибудь есть?

* любые символы
? любой единичный символ
[seq] любой единичный символ из указанных
[!seq] любой единичный символ НЕ из указанных

RegexMatchingEventHandler делает тоже самое, но с явным указанием regexp-выражений в конструкторе:

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

Наконец, LoggingEventHandler выводит все в лог через logging.info().

— Вот и все. Может кому пригодится.

P.S.
При слежении за директорией, в которой (и в ее дочерних) содержатся папки/файлы не с ascii именованием, возникнет исключение exceptions.UnicodeEncodeError в глубинах watchdog'а. В Linux (inotify) он возникает в watchdog.observers.inotify.Inotify._add_watch.
Причина — чтение содержимого в ascii кодировке.
Для исправления ситуации можно пропатчить метод:

Вот пример исходной строки, и ее repr() до и после обработки encode():

Читайте также: