Назад | Перейти на главную страницу

мониторинг nfs с помощью monit

Я хотел бы отслеживать монтирование NFS и процесс сервера NFS с помощью Monit.

На сервере мне понадобится файл PID, но я не могу найти способ создать его с помощью существующих файлов конфигурации. Есть ли способ сделать это, или кто-нибудь контролировал сервер другим способом (проверяя, активен ли порт 53 и т. Д.).

На клиентах я думал сделать так, чтобы Monit просто искал определенный файл в монтировании NFS, и если он доступен, все в порядке. Проблема в том, что если сервер NFS выходит из строя, запросы файлов обычно зависают (возможно, даже на неопределенный срок, не уверен). Как можно обойти эту проблему с помощью monit?

Приветствуются любые примеры конфигурации!

Общий подход будет (при условии, что ни одно из встроенных правил Monit не применимо)

  1. Узнайте, как вы будете проводить проверки вручную
  2. Напишите сценарии оболочки, выполняющие эти проверки, возвращающие 0 в случае успеха и 1 в случае ошибки.
  3. Позвольте Monit протестировать эти скрипты (пример взят из официальная документация):

    check program myscript with path "/usr/local/bin/myscript.sh"
       if status != 0 then alert
    

Для конкретной проблемы это может означать

  • Сервер: это, вероятно, зависит от вашей ОС, дистрибутива Linux, NFS 3 или 4 и т. Д., Но это должно быть легко понять. Например. на Ubuntu 12.04 я бы проверил, работает ли NFS-сервер через

    $ service portmap status
    $ service nfs-kernel-server status
    

    Создайте сценарий оболочки, возвращающий 0, если обе команды возвращают "выполняется".

  • Клиент: чтобы проверить, смонтирован ли определенный общий ресурс NFS, я в основном использую df -h. Таким образом, соответствующий сценарий оболочки будет выглядеть как

    #! /bin/bash
    df -h | grep -q thesharename
    

Что касается "зависания" процесса Monit при сбоях сервера NFS, то это можно обойти двумя способами.

  1. Вы меняете параметры монтирования NFS с hard к soft, что приводит к тому, что уровень NFS выдает ошибку ввода-вывода для обращающегося приложения после retrans повторные попытки. Поскольку это может вызвать другие проблемы с целостностью данных (ваш письмо приложения должны уметь справляться с ошибками ввода-вывода или, по крайней мере, выходить чисто, не повреждая записанный файл), вы также можете попробовать:
  2. асинхронизируйте свой чек (распутывайте его) от Monit. Вы можете определить задание cron, которое будет регулярно проверять ваш смонтированный NFS файл и записывать другой «файл состояния NFS», например. в / tmp. Таким образом, в случае отказа сервера NFS зависнет только cronjob (а не ваш клиент Monit). Теперь ваша проверка Monit просто проверяет этот "файл состояния NFS" второго уровня И действительно ли он намного старше, чем частота задания cron (что указывает на такое зависание NFS).

Надеюсь это поможет!

Вы уже проверяли сценарии инициализации для nfs? Я подозреваю, что они создают файл pid и прикрепляют его куда-нибудь для будущего перезапуска или остановки операций. Если нет, их должно быть довольно просто изменить для этого.

Что касается проверки крепления, посмотрите раздел 4.3.1 на http://nfs.sourceforge.net/nfs-howto/ar01s04.html#mounting_remote_dirs . Если вы смонтируете его с «мягким» вариантом, вы получите поведение, позволяющее отслеживать его, но это не должно использоваться для фактического монтирования. Возможно, вам нужно второе крепление только для наблюдения?

Я хотел ответить на Клаас, но мне не хватает очков репутации. Идея использования внешнего сценария очень хороша, потому что она обеспечивает гибкость, и предложение использовать portmap или rpcinfo для проверки доступности сервера nfs довольно разумно.

Я нашел скрипт на Github от Thibaut Madelaine я думаю, это должно быть интересно многим, кто сталкивается с той же проблемой. Он использует rpcinfo вот так rpcinfo -u 123.456.789.12 nfs 3 где 123.456.789.12 - это IP-адрес вашего nfs-сервера.

Если все хорошо, мгновенно ответ будет примерно таким: program 100003 version 3 ready and waiting и если это не удалось 123.456.789.12: RPC: Program not registered. Конечно, ответ может отличаться в зависимости от вкуса вашей системы.

Создайте скрипт под названием test-mount.sh проверить крепление. Я использую создание и удаление файлов, так как считаю ненадежным чтение файла.

set -e
/bin/touch /my-mounted-dir/test/mount.test
/bin/rm /my-mounted-dir/test/mount.test
exit 0
  1. set -e сообщает сценарию, чтобы он остановил выполнение и вернул ошибку, если какая-либо команда не удалась.
  2. Используйте касание, чтобы создать файл.
  3. Удалите файл.
  4. exit 0 сообщит об успешном выполнении сценария мониторинга.

Создать тест в конфигурации monit. Это запустит test-mount.sh, и в случае неудачи запустит remount-data.sh. Вы можете заменить его на все, что захотите, в случае неудачного монтирования.

    check program test-mount with path /root/test-mount.sh timeout 5 seconds 
      if status != 0 then exec "/root/remount-data.sh"

Я напрямую использую df тест без конкретного скрипта:

check program nfs-var with path "/bin/df -t nfs4 /var"
        if status != 0 then alert
        if status = 1 then exec "/bin/mount /var"