Скрипт Service Monitor для серверов Linux: 4 шага

2024 Автор: John Day | [email protected]. Последнее изменение: 2024-01-30 11:54

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

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

Шаг 1. Использование методов, предоставляемых Systemd

Как вы, возможно, уже знаете, большинство современных операционных систем Linux используют systemd.

Если вы не знакомы с systemd, это, согласно википедии:

«… Система инициализации, используемая в дистрибутивах Linux для начальной загрузки пользовательского пространства и последующего управления всеми процессами, вместо систем инициализации UNIX System V или Berkeley Software Distribution (BSD)…»

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

www.tecmint.com/systemd-replaces-init-in-l…

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

Не вдаваясь в подробности systemd, чтобы добавить процесс в systemd, вы должны создать служебный файл. Синтаксис такого файла может варьироваться от очень простого до чрезвычайно сложного, и мы не будем вдаваться в подробности. Чтобы иметь базовый файл.service, достаточно использовать следующие записи:

[Unit] Description = Описание applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Тип = simpleExecStart = / usr / sbin / applicationExecReload = / usr / sbin / application reloadExecStop = / usr / sbin / application stopRestart = always [Install] WantedBy = multi-user.target

Поместите их в файл application.service в папке / lib / systemd / system.

Что делает каждый из этих вариантов, объясняется в следующей ссылке:

access.redhat.com/documentation/en-US/Red_…

Чтобы запустить приложение, введите следующую команду:

sudo systemctl start application.service

Примечание: расширение.service можно не указывать.

Чтобы остановить приложение:

sudo systemctl остановить application.service

Если файл конфигурации был изменен, и вы хотите перезагрузить настройки:

sudo systemctl перезагрузить application.service

Чтобы перезапустить приложение:

sudo systemctl перезапустить application.service

Чтобы включить автоматический запуск при загрузке:

sudo systemctl включить application.service

Если этот параметр включен, диспетчер процессов systemd попытается запустить приложение на основе настроек, предоставленных системным файлом.

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

Если вы поместите Restart = always в служебный файл, то systemd будет отслеживать процесс и, если он не может быть найден в списке процессов, попытается перезапустить его автоматически.

Если вы разместите

RestartSec = 30

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

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

Здесь вам пригодятся сценарии из этого руководства.

Шаг 2: Настройка и использование скриптов Service Checker

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

Поскольку код немного велик, он загружен на github и находится в следующем репозитории:

github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh

«Сердце» всего пакета -

checkService.sh

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

Сценарий может отслеживать несколько процессов и выполнять дополнительные задачи, как описано ниже:

Он просматривает все файлы из подпапки / services с расширениями.serv или.check и проверяет, есть ли активный процесс под названием «приложение».

Если для приложения нет файла '.check', только файл application.serv:

Если процесс активен, он будет считать его активным

Если процесс неактивен, он перезапустит службу, введя следующую команду:

systemctl перезапустить приложение

если файл.serv пуст!

Если файл.serv не пуст и имеет права на исполнение, он попытается запустить его как простой сценарий BASH.

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

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

Можно редактировать содержимое такого серв-файла в соответствии с потребностями.

Другой пример - файл pcscd.serv. В этом случае несколько других процессов также были перезапущены / убиты.

Если есть файл проверки, после проверки того, запущен ли процесс, он также запустит этот файл сценария для выполнения дополнительных проверок.

Например, для службы oscam мы создали файл проверки, который пытается подключиться к своему веб-интерфейсу, чтобы убедиться, что он успешен. В противном случае, несмотря на то, что процесс активен, служба не отвечает и ее необходимо перезапустить. Перезапуск службы должен быть выполнен / вызван самим файлом.check.

Другой пример - DLNA-служба mediatomb.

Это небольшой сервер, который предоставляет видео / аудио контент клиентам DLNA и транслирует себя по сети. Иногда служба зависает и больше не может быть обнаружена, но процесс остается активным. Чтобы проверить, доступна ли служба для обнаружения, использовалась служебная программа интерфейса командной строки gssdp-discover. Весь код, проверяющий сервер DLNA, был помещен в скрипт mediatomb.check.

Это всего лишь несколько примеров того, как можно использовать файлы.serv и.check.

Чтобы отслеживать новую службу, вы должны создать.serv и, при необходимости, также файл проверки и написать в них соответствующий скрипт.

Если достаточно только проверки наличия процесса, то будет достаточно пустого файла.serv. Если необходимо выполнить дополнительные проверки, необходимо создать файл.check и написать небольшой сценарий для выполнения этой работы.

Разумеется, сценарий.sh необходимо запускать периодически, поэтому для него также необходимо создать задание cron:

# проверять запущенные службы каждые 5 минут * / 5 * * * * /var/bin/ServiceCheck/checkService.sh> / dev / null

Шаг 3: Заключительные мысли

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

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