Мониторинг хостов 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-автоматической подписи. Хотя, если вы уже знакомы с концепцией Zone и Endpoint в Icinga 2, вы также можете использовать свои собственные инструменты для настройки клиентов и установки SSL-сертификатов (например, повторное использование Puppet CA).
Хотя со временем сообщество использовало три различных метода, которые сейчас настолько популярны, что требуют их подробного объяснения в документах (что сбивает с толку чтение и все еще находится в списке todo для переписывания).
1) Клиенты с локальной настройкой. Icinga 2 поставляется с некоторыми базовыми примерами проверки мониторинга локального узла. Добавив новые проверки локально и перезапустив Icinga 2, ядро на клиенте начнет выполнять проверки и сообщит о них главному узлу коннектора. На мастер-узле вы можете перечислить узлы из собранного репозитория, внести их в чёрный/белый список, а затем сгенерировать конфигурацию, используя 'node update-config'.
В случае, если вам кажется сложным самостоятельно управлять конфигурацией на каждом клиенте - это верно, но с точки зрения автоматизации и локальной конфигурации это всё равно верно.
2) Мастер централизованной конфигурации с (сателлитами и) клиентами. Этот метод использует механизм Zone и Endpoint из кластера Icinga 2, и позволяет распределить конфигурацию от мастера к клиентам. Таким образом, вы просто управляете хостом/сервисными объектами на мастере, а остальное позволяет Icinga 2 обрабатывать. Есть даже место для глобальной зоны, включающей шаблоны, команды проверки и т.д.
В этом сценарии вы просто настраиваете клиента один раз и позволяете мастеру управлять остальными. Вы также получите преимущество локального планировщика на клиенте, который продолжает проверять и переигрывает историю проверок при восстановлении соединения (что, несомненно, полезно для отчетности по SLA)
3) Если вы ищете NRPE, похожий на выполнение проверок без локального планировщика, но с быстрым исполнением командного плагина, вы можете использовать клиентов в качестве "моста выполнения команд". В этом сценарии Вы изначально установите клиента один раз, и добавьте его конфигурацию конечной точки/зоны к ведущему устройству. Проверяемые хост/сервисные объекты также конфигурируются на ведущем устройстве, но содержат ссылку на так называемую "Command_endpoint". Это заставляет Icinga 2 посылать выполнение проверки клиенту Icinga 2, который асинхронно выполняет проверку и посылает результат обратно ведущему устройству.
Вам все равно понадобятся локальные определения CheckCommand на клиенте. Библиотека шаблонов Icinga (Icinga Template Library, 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 - это вилка нагиос и она использует те же плагины/клиенты для мониторинга. Что вам нужно, так это демон nrpe и nagios-плагины.
Демон nrpe работает на серверах, которые вы хотите контролировать, и прослушивает запросы от удаленных nagios/icinga. Когда приходит такой запрос, он может выполнить определённый плагин и вернуть результат на ваш сервер icinga.
Плагины nagios - это набор маленьких программ, которые проверяют статус определённого сервиса/ресурса и в зависимости от условий сообщают OK, WARNING, CRITICAL.
Пакеты, которые вам нужны:
- nagios-плагины
- nagios-nrpe-сервер
Они должны быть установлены на каждом сервере, который вы хотите контролировать.
.Если вам нужно только проверить доступность внешних служб (например, HTTP), вам не нужно устанавливать программное обеспечение на клиенте.