Nagios Best Practice [дубликат]

На этот вопрос уже есть ответ здесь:

Я установил Nagios в свою сеть, и у меня есть несколько вопросов для новичков.

Я хотел бы получить некоторую «передовую» информацию о следующих типах серверов:

  • Веб-сервер
  • Сервер Exchange
  • Сервер базы данных

Из приведенного выше списка я хотел бы узнать ресурсы это следует контролировать. Например, каковы предпочтительные проверки для мониторинга сервера обмена, я сначала подумал о них:

  • Дисковое пространство (C :)
  • Загрузка ЦП (%)
  • Использование памяти (%)

I ' Я хочу составить их список, чтобы при добавлении нового сервера в свою сеть я знал, какие проверки мне следует добавить (по сути, набор шаблонов) в зависимости от типа сервера.

Для дальнейшего пояснения я не спрашиваю, КАК настраивать Nagios, но какие передовые практики и типичные проверки я должен выбрать для разных типов серверов.

0
задан 27 March 2011 в 15:59
3 ответа

У меня есть немного понимания проблемы Вы, но я думаю, что Вы ищете установку в качестве примера.

Викимедиа (Парни Википедии) имеет общедоступный сервер Nagios, который кажется, что это точно, в чем Вы нуждаетесь. Проверьте его здесь: http://nagios.wikimedia.org/

1
ответ дан 4 December 2019 в 14:51

Одна вещь отметить:

quis custodes Ipsos custodiet

Если контрольная услуга, предоставленная Nagios, спускается, то, как будет Вы знать ли любой a) Ваши сервисы просто хорошо или b) Вы потеряли свой контрольный сервис и на самом деле вещи, разваливается вокруг Ваших ушей.

Поэтому я всегда рекомендовал бы иметь два хоста Nagios.

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

Они оба должны быть настроены, чтобы смочь отправить уведомления, второй должен также быть настроен так, чтобы это не зависело ни от каких сервисов в первом месте.

0
ответ дан 4 December 2019 в 14:51

Вы ищете группы узлов. Ключ к масштабируемому nagios развертыванию или по крайней мере один ключ, никогда не должен отображать сервисную проверку непосредственно на хост или список хостов. Вместо этого создайте группы узлов и добавьте, что хосты тех групп узлов затем присваивают сервисные проверки тем группам узлов. Это будет означать, что добавление нового сервера очень легко. Вот пример.

define hostgroup {
        hostgroup_name          mogile-servers
        alias                   Mogile Servers
        members                 adrock,mca,miked
}


define service {
        hostgroup               mogile-servers
        use                     he-generic-service
        service_description     MOGSTORED_RSS
        contact_groups          sms
        check_command           check_remote_procs_rss!10485760!12582912!mogstored
}

Отметьте, существует еще несколько сервисов, присвоенных группе узлов mogile-серверов.

Теперь, если я должен добавить другой mogile сервер, я просто добавляю его к группе узлов mogile-серверов, и все сервисы будут проверены что новый хост. Легкий.

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

В Вашем примере выше, Вы создали бы что-то как:

define hostgroup {
        hostgroup_name          exchange-servers
        alias                   Exchange Servers
        members                 pdc-host, sdc-host, tdc-host
}

define service {
        hostgroup               exchange-servers
        use                     he-generic-service
        service_description     EXCHANGE
        contact_groups          sms
        check_command           check_exchange

}
1
ответ дан 4 December 2019 в 14:51

Теги

Похожие вопросы