Monit настроить сообщение о проблемах администратору
Обновлено: 20.05.2024
Мониторинг большинства служб, процессов, системных параметров и прочих вещей в жизни любого администратора.
CentOS
Dubina/Bubunta
Не забываем про различные пути до сервисов на разных ОС! Особенно Gentoo :D
Под каждый вид мониторинга создается отдельно файл в папке /etc/monit.d/
Все настройки производятся в файле /etc/monit.conf
1) Раскомментируем и изменим путь для записи лог-файла;
2) Настроим отправку уведомлений по SMTP (для клиентских лучше использовать sendmail , чтобы не светить парольку от почты)
Для этого пишем set mailserver localhost
3) Доступы к веб-морде (лучше не использовать. Консольный вариант также удобен и понятен)
4) Время опроса демона и задержка перед опросом после запуска
5) Кому отправлять алерты по-умолчанию (используется только в том случае, если не указан другой адрес для уведомления)
Список доступных оповещений
| Event | Failure state | Success state |
|---|---|---|
| ACTION | Action done | “Action done” |
| CHECKSUM | “Checksum failed” | “Checksum succeeded” |
| CONNECTION | “Connection failed” | “Connection succeeded” |
| CONTENT | “Content failed” | “Content succeeded” |
| DATA | “Data access error” | “Data access succeeded” |
| EXEC | “Execution failed” | “Execution succeeded” |
| FSFLAGS | “Filesystem flags failed” | “Filesystem flags succeeded” |
| GID | “GID failed” | “GID succeeded” |
| ICMP | “Ping failed” | “Ping succeeded” |
| INSTANCE | “Monit instance changed” | “Monit instance changed not” |
| INVALID | “Invalid type” | “Type succeeded” |
| NONEXIST | “Does not exist” | “Exists” |
| PERMISSION | “Permission failed” | “Permission succeeded” |
| PID | “PID failed” | “PID succeeded” |
| PPID | “PPID failed” | “PPID succeeded” |
| RESOURCE | “Resource limit matched” | “Resource limit succeeded” |
| SIZE | “Size failed” | “Size succeeded” |
| STATUS | “Status failed” | “Status succeeded” |
| TIMEOUT | “Timeout” | “Timeout recovery” |
| TIMESTAMP | “Timestamp failed” | “Timestamp succeeded” |
| UID | “UID failed” | “UID succeeded” |
| UPTIME | “Uptime failed” | “Uptime succeeded” |
Мониторинг процессов
Для каждой службы выбираем свои действия по которым будем получать уведомления. Здесь представлены только примеры!
Значения также настраиваются исходя из конфигурация сервера и нагрузки на них!
Мониторинг NGINX
Мониторинг PHP-FPM
Мониторинг MySQL (для MariaDB отдельный конфиг)
Мониторинг MariaDB
Внимание. Если работает по сокетам, то указываем путь до каждого из них в новом файле!
Не стоит забывать, что порт может быть отличный от примера.
Мониторинг места на диске
Если нужно мониторить все место на диске, то вместо имени папки - пишем rootfs
Оригинал: How to set up server monitoring system with Monit
Автор: Iulian Murgulet
Дата публикации: 25 марта 2015 г.
Перевод: А.Панин
Дата перевода: 15 августа 2016 г.
Многие системные администраторы, имеющие дело с Linux-серверами, полагаются на централизованные удаленные системы мониторинга (такие, как Nagios или Cacti) для наблюдения за подконтрольной сетевой инфраструктурой. Хотя централизованный мониторинг и значительно упрощает жизнь системного администратора при работе с множеством узлов и устройств, удаленный сервер системы мониторинга становится единой точкой отказа; если этот сервер выйдет из строя или прекратит отвечать на запросы по какой-либо причине (например, из-за некачественного аппаратного обеспечения или неработоспособности сети), вы не сможете контролировать всю сетевую инфраструктуру.
Один из способов избыточного резервирования описанной системы мониторинга заключается в установке и использовании отдельного (резервного) программного компонента для мониторинга состояния наиболее важных или основных серверов вашей сети. В этом случае даже тогда, когда централизованная система мониторинга окажется в неработоспособном состоянии, вы все также сможете отслеживать состояние основных серверов с помощью резервной системы мониторинга.
Что такое Monit?
Monit является кроссплатформенным инструментом с открытым исходным кодом, предназначенным для мониторинга состояния систем Unix/Linux (то есть, Linux, BSD, OSX, Solaris). Monit крайне просто установить, он является достаточно легковесным (занимает всего 500 КБ дискового пространства) и не требует каких-либо сторонних программ, плагинов или библиотек. К тому же, Monit осуществляет полноценный мониторинг состояния системы, включающий мониторинг состояния процессов, изменений файловой системы, а также осуществляет отправку уведомлений по электронной почте, выполняет заданные действия при наступлении тех или иных событий и так далее. Комбинация из простоты установки, легковесной реализации и широкого спектра возможностей делает Monit идеальным кандидатом на роль резервной системы мониторинга состояния сервера.
Я использую Monit уже несколько лет на множестве узлов и очень доволен стабильностью его работы. Даже в качестве полнофункциональной системы мониторинга состояния сервера, Monit может оказаться очень полезным инструментом для любого системного администратора, обслуживающего Linux-серверы. В данной статье я постараюсь описать методику установки Monit на локальный сервер (в качестве резервной системы мониторинга его состояния) с целью мониторинга состояния его основных служб. С помощью данного примера я продемонстрирую лишь малую часть возможностей Monit.
Установка Monit в Linux
В репозиториях большинства дистрибутивов Linux уже присутствует пакет с компонентами Monit.
Debian, Ubuntu или Linux Mint:
Fedora или CentOS/RHEL:
В CentOS/RHEL вам в первую очередь придется подключить либо репозиторий EPEL, либо репозиторий Repoforge.
В комплекте поставки Monit присутствует очень хорошо документированный файл конфигурации с множеством примеров. Основной файл конфигурации расположен по пути /etc/monit.conf в дистрибутивах Fedora/CentOS/RHEL или /etc/monit/monitrc в дистрибутивах Debian/Ubuntu/Mint. Файл конфигурации Monit содержит две секции параметров: секцию глобальных параметров "Global" и секцию параметров сервисов "Services" .
Секция глобальных параметров файла конфигурации: веб-страница с информацией о состоянии сервера
- Monit должен принимать соединения на порту 1966 .
- Доступ к веб-странице должен быть организован с применением защищенного протокола SSL.
- Для доступа к веб-странице должны использоваться слова "monituser" и "romania" в качестве имени пользователя и пароля соответственно.
- Доступ к веб-странице должен быть разрешен лишь с локального узла, с узла myhost.mydomain.ro , а также из внутренней сети ( 192.168.0.0/16 ).
- Monit должен хранить SSL-сертификат в формате pem.
При выполнении всех последующих операций, связанных с настройкой Monit, я буду использовать систему, созданную специалистами компании Red Hat. Аналогичные операции могут выполняться и в системе, основанной на дистрибутиве Debian.
В первую очередь следует сгенерировать самостоятельно подписанный сертификат ( monit.pem ) в директории /var/certs .
Теперь нужно поместить следующий набор директив в основной файл конфигурации Monit. Вы можете как создать пустой файл конфигурации, так и скопировать шаблон этого файла и модифицировать его по мере необходимости.
Секция глобальных параметров файла конфигурации: уведомления по электронной почте
На основе приведенной выше информации, несложно сформировать следующую конфигурацию механизма отправки уведомлений по электронной почте:
Секция глобальных параметров файла конфигурации: демон Monit
На следующем этапе необходимо настроить демон monit. Мы будем настраивать его в соответствии со следующими требованиями:
- Необходимо осуществить первую проверку состояния сервисов по прошествии 120 секунд.
- Следует проверять состояние сервисов через каждые 3 минуты.
- Нужно использовать сервис syslog для ведения журнала событий.
Для выполнения приведенных выше требований достаточно разместить следующий блок директив в файле конфигурации:
Тестирование глобальных параметров файла конфигурации
На этом процесс заполнения секции глобальных параметров файла конфигурации можно считать оконченным. На данный момент файл конфигурации Monit должен выглядеть следующим образом:
Пришло время проверить корректность заполнения файла конфигурации. Вы можете проверить корректность существующего файла конфигурации ( /etc/monit.conf ), выполнив следующую команду:
После того, как вы проверите синтаксис файла конфигурации, следует запустить демон monit и подождать 2-3 минуты:
Если вы используете systemd, выполните следующую команду:
Учтите, что в том случае, если вы будете использовать самостоятельно подписанный SSL-сертификат, вы увидите страницу с предупреждением в окне веб-браузера сразу же после перехода по указанному выше адресу.
После ввода корректных имени пользователя и пароля вы должны увидеть следующую страницу.
Далее в данном руководстве я продемонстрирую методику настройки Monit для мониторинга состояния локального сервера и его основных сервисов. Вы же можете найти огромное количество полезных примеров файлов конфигурации на официальной странице wiki проекта. Все эти примеры готовы к использованию, поэтому вы можете, не опасаясь за последствия, использовать функции копирования/вставки.
Секция параметров сервиса файла конфигурации: мониторинг параметров использования оперативной памяти и центрального процессора
Давайте начнем с организации мониторинга параметров использования оперативной памяти и центрального процессора. Скопируйте следующий блок директив и вставьте его в файл конфигурации:
В том случае, если значения каких-либо из рабочих параметров не должны отслеживаться в рамках каждого цикла мониторинга, вы можете использовать следующий формат директивы. Например, в данном случае будет осуществляться проверка значения средней нагрузки на центральный процессор в рамках каждого второго цикла мониторинга (то есть, через каждые 240 секунд):
Секция параметров сервиса файла конфигурации: мониторинг состояния сервиса SSH
Давайте убедимся в том, что в нашей системе присутствует бинарный файл sshd , расположенный по пути /usr/sbin/sshd :
Нам также нужно убедиться в том, что существует сценарий инициализации для sshd :
Наконец, нам следует убедиться в том, что демон sshd запущен, исполняется и принимает соединения на порту 22 :
В частности, мы можем интерпретировать приведенный выше блок директив следующим образом. В первую очередь осуществляется проверка наличия в системе процесса с именем sshd и pid-файла демона ( /var/run/sshd.pid ). Если в системе не обнаруживается хотя бы одной из двух упомянутых сущностей, осуществляется перезапуск демона sshd с помощью его сценария инициализации. После этого осуществляется проверка поддержки процессом, принимающим соединения на порту 22 , протокола SSH. В том случае, если процесс не обслуживает клиентов по протоколу SSH, осуществляется перезапуск демона sshd . Если в рамках 5 последних циклов мониторинга (то есть, в течение последних 5x120 секунд) было осуществлено как минимум 5 операций перезапуска, демон sshd признается некорректно функционирующим и никаких попыток проверки его состояния более не предпринимается.
Секция параметров сервиса файла конфигурации: мониторинг состояния сервиса SMTP
Теперь давайте настроим механизм проверки состояния удаленного почтового сервера, использующего протокол SMTP (запущенного на узле с адресом 192.168.111.102 ). Давайте предположим, что посредством сетевого интерфейса упомянутого узла можно получить доступ к серверам, использующим протоколы SMTP, IMAP и SSH.
Здесь в первую очередь проверяется, отвечает ли узел на запросы по протоколу ICMP. Если не удается получить ответ по протоколу ICMP в рамках 10 циклов мониторинга, отправляется соответствующее уведомление. В том случае, если сервер, принимающий соединения на порту 25 , не обслуживает клиентов по протоколу SMTP, также отправляется уведомление. Если же следующая после неудачной проверка завершается успешно, исполняется указанный сценарий ( /scripts/mail-script ). Кроме того, если серверы, принимающие соединения на портах 22 и 143 не обслуживают клиентов по протоколам SSH и IMAP соответственно, также отправляется уведомление.
Заключение
В данной статье я постарался продемонстрировать методику настройки демона Monit с целью организации мониторинга состояния локального сервера. В плане возможностей Monit была показана лишь вершина айсберга. Вам стоит выделить немного времени и самостоятельно прочитать страницу руководства Monit (которая содержит очень полезную информацию). Monit может стать отличным помощником любого администратора Linux-систем благодаря простому и понятному синтаксису файлов конфигурации. Если вы добавите Monit к уже существующей централизованной системе мониторинга, использующей удаленный сервер, вы, без сомнения, повысите ее надежность. А что вы думаете о Monit?
10 Окт 2017 17:10:37 | 1 comment
Мониторинг сайтов с помощью Monit
В предыдущей статье я описал как установить и настроить Monit для мониторинга сервера, но помимо мониторинга параметров сервера Monit можно использовать и для многих других целей, в частности мониторинга web-сайтов.
У нас уже есть настроенный и работающий Monit, теперь давайте определимся мониторинг каких параметров сайта мы хотим и будем проверять:
Такой метод проверки несет мало полезной информации, но он жизненно необходим для диагностики доступности сайта на сетевом уровне. И если проверка по ICMP выдает сбой, то это первый признак того, что с вашим сайтом, вернее с сервером где Ваш сайт что-то не так.
Создадим файл конфигурации /etc/monit/conf.d/mysite
Здесь мы проверяем наш сайт по протоколу ICMPv4 отправляя ICMP Echo Request с таймаутом 10 секунд.
Более детально о всех опциях проверки можно почитать Проверку подключения на 80-й порт и на 443-й порт.
Пишем в файл /etc/monit/conf.d/mysite
Более детально о всех опциях проверки можно почитать в официальной документации.
Проверка SSL сертификата нашего сайта
Данная проверка является модифицированным аналогом предыдущего варианта проверки на подключение.
В файле /etc/monit/conf.d/mysite пишем:
Так же мы можем проверять контрольную сумму сертификата, что очень актуально если у Вас постоянный сертификат выданный на 1 или 2 года, дополнительная проверка сертификата по контрольной сумме гарантирует, что это точно Ваш сертификат, а не подделка.
Проверку по контрольной сумме можно сделать так:
Вначале посмотрим SHA1 fingerprint нашего SSL сертификата (посмотреть можно 2-мя способами), на самом web-сервере:
или на удаленном сервере:
В файле /etc/monit/conf.d/mysite пишем:
Теперь давайте проверим конфигурацию monit, сделаем перезагрузку настроек и посмотрим результаты проверки.
Как видим, все отлично, все проверки успешно отработали. Наш SSL сертификат валиден еще 9 дней.
Давайте поменяем параметр проверки валидации SSL сертификата c 7 на 10 дней и перезапустим проверку и выведем результат:
Проверка кода ответа web-сервера, проверка отдачи контента на определенные ключевые слова.
Зачем вообще нужны такие проверки?
А зачем тогда проверять контент на предмет каких-то ключевых слов?
А контент нужно проверять чтобы:
1. Убедиться, что это именно Ваш сайт с Вашим контентом, а не какой-то подставной домен. Например если Вы забыли продлить срок регистрации Вашего домена, то регистратор снимает делегирование домена и отдает страницу-заглушку, на которой пишет, что срок регистрации домена закончился. Код ответа web-сервера регистратора будет 200 и предыдущая проверка не выявит ошибку, но вот проверка контента на уникальные слова выявит ошибку и вышлет Вам оповещение.
Все эти проверки мы рассмотрим ниже.
Проверка кода ответа Web-сервера.
Здесь все предельно просто, проверяем код ответа на главной странице сайта, если он отличен от 200 — высылаем оповещение.
В файле /etc/monit/conf.d/mysite пишем:
Проверка контента на сайте.
Будем искать номер телефона на главной странице сайта.
В файле /etc/monit/conf.d/mysite пишем:
Все нормально. А теперь поменяем на сайте номер телефона и подождем очередную проверку.
У нас есть аларм в консоле, а так же пришло оповещение на email такого вида:
У меня на сервере используется nginx, поэтому я напишу создание заголовка для него.
Заголовок будет X-Monit со статическим значением my_private_string
Теперь проверим наличие нашего заголовка в ответе сервера:
Все есть, пишем проверку для Monit.
Создаем файл /usr/sbin/monit_check_mysite_header.sh такого вида:
Не забываем сделать файл исполняемым
В файле /etc/monit/conf.d/mysite пишем:
Проверяем конфигурацию и перезагружаем её, потом ждем результатов проверки и смотрим:
Все есть, нужны нам заголовок присутствует.
А теперь давайте изменим содержимое нашего заголовка в nginx и подождем.
Мы видим last output = X-Monit-Wrong, то есть наш заголовок стал не совпадать с тем что нужно.
Так же нам на почту пришло уведомление об этом:
Можно вообще убрать наш секретный заголовок X-Monit в nginx и тогда при следующей проверке в Monit будет статус X-Monit-Empty, то есть заголовка нет вообще.
Конечно заголовок должен быть не статическим как сделал я для примера, а динамическим и формироваться по определенному секретному алгоритму и тогда без вскрытия настроек web-сервера злоумышленники никогда не смогут подделать его и даже если они взломают ftp аккаунт сервера и БД сервера и скопируют их содержимое чтобы запустить абсолютно полную копию Вашего сайта, то Ваша проверка тут же это выявит по отсутствию секретного заголовка.
Проверка доступности и работоспособности базы данных сайта.
Скрипт не выполняет никаких проверочных SQL запросов к БД, он просто подключается к MySQL и выбирает нужную БД. Вы можете изменить скрипт так, чтобы он делал простой SQL-запрос, например выводил количество записей в какой-либо табличке, это даст дополнительную уверенность, что в БД есть какие-либо данные и она не пустая.
Итак, сам php скрипт будет таким (расположим его в корне сайта с именем mysqlcheck.php):
В файле /etc/monit/conf.d/mysite пишем:
Проверяем конфигурацию и перезагружаем её, потом ждем результатов проверки и смотрим:
Проверка истечение срока регистрации доменного имени.
Данный вид проверки так же не решается силами одного Monit, для проверки нам понадобиться сторонний скрипт на shell, но с ним все гораздо проще, он уже есть в моем репозитарии, остается только скачать его и написать небольшой shell-скрипт для анализа результата работы domain-check.pl.
Пишем простой скрипт для monit для проверки истечение срока регистрации доменного имени:
Сохраняем его в /usr/sbin/monit_check_mysite_expire.sh
Не забываем сделать файл исполняемым
В файле /etc/monit/conf.d/mysite пишем:
Проверяем конфигурацию и перезагружаем её, потом ждем результатов проверки и смотрим:
Все отлично. Проверка работает.
Чтобы убедиться в работоспособности измените в скрипте /usr/sbin/monit_check_mysite_expire.sh параметр interval с 10 до 1000 и подождите, при следующей проверке monit выдаст оповещение.
И в заключении я приведу всю конфигурацию для мониторинга сайта.
Это наш файл /etc/monit/conf.d/mysite который получился по результатам статьи:
Мы рассмотрели вопрос мониторинга работоспособности сайта с помощью системы Monit, данные виды проверок позволяют достаточно эффективно и быстро диагностировать перебои в работе сайта, а так же позволяют заблаговременно оповестить владельца сайта о наступлении возможных проблем.
На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.
Монитор передачи
На моем недавно построенном энергоэффективном домашнем сервере я тестирую и запускаю несколько приложений, включая Transmission. Я использую Monit для мониторинга нескольких служб, перечисленных ниже:
Контролируйте свой домашний сервер с Monit:
В этом руководстве я покажу вам, как следить за состоянием процесса передачи, чтобы настроенная вами система автоматической загрузки работала так, как должна. Просто еще один уровень автоматизации для вашего домашнего сервера.
Перед включением мониторинга передачи необходимо иметь работающий экземпляр Monit с соответствующим /etc/monit/monitrc файлом. Конфигурации Monit для различных сервисов загружаются из /etc/monit/conf.d папки.
1. Найти порт передачи WebUI
Кроме того, вы можете открыть файл настроек передачи и искать порт. Если вы следовали нашему руководству по установке Transmission WebUI, вы можете открыть файл настроек с помощью следующей команды:
Затем найдите номер порта. Найдите строку, похожую на:
В этом руководстве мы предполагаем, что вы используете порт 9091, который является портом по умолчанию для демона передачи.
Настроить скрипт мониторинга передачи Monit
Для мониторинга передачи с Monit создайте файл конфигурации Monit с помощью следующей команды:
Скопируйте в него следующее содержимое, сохраните и выйдите (нажмите Ctrl X, нажмите Y и нажмите ENTER).
Цикл – 1 период мониторинга, как установлено в /etc/monit/monitrc . Если в течение 3 циклов мониторинга произойдет 2 перезапуска, Monit прекратит мониторинг состояния процесса передачи, вместо того, чтобы засыпать вас оповещениями по электронной почте. Вы можете настроить вышеперечисленные правила по своему усмотрению. [ Читайте: что такое Usenet и почему он лучше Torrents? ]
Тест и перезагрузка Монит
После внесения каких-либо изменений необходимо протестировать конфигурацию Monit:
Если Monit запущен, перезагрузите конфигурации Monit с помощью следующей команды:
Если Monit не запущен, запустите его, используя sudo monit команду. Вся последовательность команд для тестирования и перезагрузки Monit показана на рисунке ниже.
Теперь запустите веб-браузер и перейдите на один из следующих URL-адресов в зависимости от того, как настроен ваш Monit (обязательно используйте правильный номер порта):
Вы должны увидеть статус процесса передачи на странице состояния мониторинга, показанной на рисунке ниже.
Вот и все для мониторинга трансмиссии с Monit. Как вы можете видеть, Monit обеспечивает автоматический мониторинг сервера, который может быть очень полезен для системных администраторов. На странице Monit Wiki есть несколько примеров. Больше примеров Monit для домашнего сервера, чтобы следовать, поэтому продолжайте проверять.
Читайте также: