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

Мониторинг хостов Debian 5, 6, 7 с помощью icinga2

Я успешно установил icinga2 и icinga2-web на Debian 8. Проблема в том, что мне нужно отслеживать серверы с установленными Debian 5, 6 и 7. Это вообще возможно?

Если я правильно понимаю - мне нужен клиент icinga2, установленный на хосте, который я хочу отслеживать, и в icinga2 нет такой вещи, как конкретный клиент - нужно установить весь пакет icinga2.

Я попытался установить этот пакет на сжатие из бэкпортов (инструкция находится здесь: http://debmon.org/instructions) но безуспешно.

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

Хотя то, что вы просто устанавливаете бинарный пакет icinga2 на узел, который вы называете «клиентом», может сбивать с толку, это разумно.

Таким образом, вы получите следующие преимущества:

  • Такая же настройка для всех узлов в вашей (кластерной) распределенной настройке, будь то главный, вспомогательный, клиент, агент или любая другая роль, которую вы им назначите.
  • Одинаковая конфигурация dsl для всех задействованных узлов
  • Клиенты используют те же преимущества, что и узлы кластера: поддержка SSL x509, IPv4 и IPv6, журнал воспроизведения при потере соединения и т. Д.

Настроить клиентов помогают мастера кликов и механизмы автоматической подписи CSR. Хотя, если вы уже знакомы с концепцией зоны и конечной точки в Icinga 2, вы также можете использовать свои собственные инструменты для настройки клиентов, а также для развертывания сертификатов SSL (например, повторно используя Puppet CA).

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

1) Клиенты с локальной конфигурацией. Icinga 2 поставляется с некоторыми основными примерами проверок, контролирующих локальный узел. При локальном добавлении новых проверок и перезапуске Icinga 2 ядро ​​на клиенте начнет выполнять проверки и сообщать о них главному узлу соединителя. На главном сервере вы можете перечислить узлы из собранного репозитория, внести их в черный / белый список, а затем сгенерировать конфигурацию с помощью 'node update-config'.

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

2) Мастер центральной конфигурации с (спутниками и) клиентами. Этот метод повторно использует механизм зоны и конечной точки из кластера Icinga 2 и позволяет распространять конфигурацию от мастера к клиентам. Таким образом, вы просто будете управлять объектами хоста / службы на главном сервере, а Icinga 2 сделает все остальное. Есть даже место для глобальной зоны, включая шаблоны, команды проверки и т. Д.

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

3) Если вы ищете NRPE, например выполнение проверки без локального планировщика, но в качестве исполнителя плагина быстрых команд, вы можете использовать клиентов как «мост выполнения команд». В этом сценарии вы сначала настроите клиент один раз и добавите его конфигурацию конечной точки / зоны к мастеру. Проверяемые объекты хоста / службы также настроены на главном устройстве, но ссылаются на так называемую "command_endpoint". Это заставляет Icinga 2 отправлять выполнение проверки клиенту Icinga 2, который асинхронно выполняет проверку и отправляет результат обратно мастеру.

Вам по-прежнему понадобятся локальные определения CheckCommand на клиенте. Библиотека шаблонов Icinga (ITL) уже предоставляет множество из них, но если вы планируете добавить свои собственные, вам следует подумать о том, чтобы взять 2) только с глобальной зоной, синхронизирующей конфигурацию команд.

Таким образом, вы также можете гарантировать, что определенные параметры команды, переданные мастеру, могут быть отключены на определенных клиентах (печально известный параметр «-a» в nrpe, но более контролируемым способом).

Больше можно найти в документации: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-scenarios

Что касается Debian 5, Lenny - это конец жизненного цикла, поэтому он не поддерживается Icinga 2. Тогда перейдите на check_by_ssh. http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-by-ssh

Icinga - это форк nagios, который использует те же плагины / клиенты для мониторинга. Что вам нужно, так это демон nrpe и плагины nagios.

Демон nrpe работает на серверах, которые вы хотите отслеживать, и прослушивает запросы от удаленных nagios / icinga. Когда приходит такой запрос, он может запустить определенный плагин и вернуть результат на ваш сервер icinga.

Плагины nagios представляют собой набор небольших программ, которые проверяют состояние конкретной службы / ресурса и сообщают о них с помощью OK, WARNING, CRITICAL в зависимости от условий.

Вам нужны следующие пакеты:

  • nagios-плагины
  • nagios-nrpe-сервер

Вы должны установить их на каждом сервере, который вы хотите отслеживать.

Если вам нужно только проверить доступность внешних сервисов (например, HTTP), вам не нужно устанавливать программное обеспечение на клиенте.