Icinga2 простой вариант14.04.2017 07:04

Про icinga2 пишут почему-то на удивление мало и то, что пишут как-то не создаёт общего концепта. В одном месте пишут как написать скрипт, в другом как установить всё это дело, а что с этим делать потом не ясно.

Я сам использую icinga где-то с начала 2013 года, тогда ещё была только первая версия и сильно далеко от Nagios’a она не ушла.С выходом второй версии поменялось очень много и для меня выбор очевиден.

Дальше я хочу рассказать, как это всё быстро установить и, что более интересно, что дальше с этим делать.

Немного описания
Icinga2 нужна чтобы наблюдать за состоянием серверов, сервисов, принтеров, роутеров и всего другого где есть линукс или виндовс или даже где нет.
Если первая версия работала на ядре от Nagios’a, то во второй версии всё было сделано по-новому, чтобы было быстро и красиво. Для этого команде от icinga пришлось переписать ядро и теперь без больших усилий можно сделать либо распределенную систему, либо то-же самое, но к этому добавить еще и кластер.

Но такое делается для больших сетей (over 10k в одном сегменте). Когда только выходила вторая версия, то я читал, что у них на тестах один сервер мог обрабатывать до 10к обращений в секунду, я столько серверов не держу, поэтому подтвердить не могу.

Начало и чуть-чуть теории
В 2013 году мы у нас на фирме решили сделать систему для мониторинга и устанавливать у наших клиентов, беря с них деньги за услуги в случае каких-либо проблем с их системами, встал вопрос, а как собственно попадать на их системы.
У icinga есть два способа проверять состояние систем — либо активно обращаться к серверам стучась на какой-нибудь порт, либо открыть у себя порт и ждать что туда что-то придёт. Соответственно это называется активный и пассивный методы. В большинстве случаев используется активный способ, хотя мне не понятно почему. Также в интернете в основном встречается описание именно активного опроса.

Активный режим

Тут есть несколько вариантов, можно использовать icinga2 director и клиента для виндовс или линукс. После их установки надо писать конфиги или шаблоны для icinga2. В данном случае icinga2 обращается к серверу и выполняет через клиента проверку либо как-то произвольный скприт. Раньше для этого использовался NRPE, как это происходит сейчас я не знаю.

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

Пассивный режим

В этом случае открываем на стороне icinga2 сервера порт 5667 для NSCA или включаем Icinga2 APi (порт 5665) и просто ждём пока нам придёт состояние какой-либо системы, при этом icinga смотрит, когда статус обновился последний раз и если статус не обновляется какое-то определённое время, то icinga помечает его как неизвестный. Ну и конечно куда-же без ложки дёгтя — если надо проверять роутер или принтер или где-то опрашивать SNMP, то при пассивных опросах это сделать нельзя. Но тут можно написать костыль, один из серверов в этой же сети может опрашивать через SNMP и слать статус в icinga, но для этого надо писать скрипт.
NSCA это уже в какой-то мере устаревшее решение, но для виндовс систем, пока нету хорошей альтернативы (чтобы не пришлось много делать руками). В линуксе я уже написал некоторое количество скриптов и они обращаются к Icinga2 Api. Совсем недавно я так-же написал библиотеку для node.js (ссылка внизу). Установка ()
Как уже было понятно выше, я хочу установить Icinga2 и настроить её в пассивном режиме.
Для Icinga2 я сделал контейнер (docker).
Что в контейнере:
1. Icinga Web 2 — веб интерфейс, где можно смотреть статус
2. Graphite — чтобы отображались красивые графики
3. Icinga2 Classic UI — тоже гуи, но с первой версии, чтобы можно было использовать старые программы типа Nagstamon (для виндовс) или adagios (для андроида)
4. Интеграция с AD, но оказалось, что она нам не нужна, поэтому я её давно не проверял, может оказаться, что она не работает.
5. NSCA Server — нужен чтобы принимать метрики с винды или от тех кто использует nsca
6. Icinga2 API — api от icinga. Можно делать всё — устанавливать статус, добавлять/удалять хосты и сервисы итд.

Для тех кто никогда не пользовался докером, показываю как установить всё это на убунту (16.04)
Сначала ставим докер ну и для удобсва можно ещё и docker-compose

sudo apt install docker.io docker-compose -y

Потом стартуем контейнер с Icinga2 без Active Directory

sudo docker run -i -p 80:80 -p 5667:5667 -p 5665:5665 -p 8080:8080 -h monitoring.example.com \
-v /storage/icingaweb2:/icingaweb2 -v /storage/icinga2:/icinga2conf -v /storage/mysql:/mysql \
-v /storage/graphite:/var/lib/graphite/whisper \
-e NOTIFICATION_INTERVAL=0 -e GRAPHITE_HOST=192.168.42.64:8080 \
-e APIUSER=root -e APIPASS=PASS -e ICINGA_PASS="icinga" \
-e MAILSERVER="mail.example.com" -e EMAILADDR="user@example.com" -e NSCAPASS="pass" -e NSCAPORT="5667" \
--name icinga2 -t adito/icinga2

В описании на hub.docker.com есть вариант запуска с AD, посмотреть можно тут

Немного описания для переменных и остального
Порты:
80 — это понятно, тут можно всё смотреть
5667 — NSCA порт, может быть, что нужен он не всем
5665 — Icinga2 API
8080 — Страница graphite, должна быть открыта, так как icinga2 обращается к ней чтобы рисовать графики

Переменные:
»-h» — название хоста, отображается потом на странице
»-v /storage…» — хранятся конфиги и дб
«GRAPHITE_HOST» — это ip сервера где работает контейнер, через этот адрес icinga2 обращается к graphite
«APIUSER» — это ясно и так. Желательно поменять на что-то типа »0ilkasjdf09123malskdf»
«APIPASS» — это тоже ясно
«ICINGA_PASS» — пароль для пользователя «icingaadmin»
«MAILSERVER» — хост где у вас есть почтовый сервер, у меня стоит exchange в той же сети, поэтому он просто работает как relay
«EMAILADDR» — адрес который использует icinga2.
«NSCAPASS» и «NSCAPORT» я думаю понятно.

После этого у вас есть работающий сервер для мониторинга, который мониторит сам себя. Можно зайти посмотреть, что там и как.
Доступен по адресу GRAPHITE_HOST:80
Так-же есть старая версия по GRAPHITE_HOST/icinga2-classicui. Эту версию можно использовать, чтобы подключить к примеру anag и смотреть статус через телефон. Или есть ещё nagstamon это для компьютера, он вроде бы уже может и через Icinga2 API обращаться, опция есть, но я сильно не смотрел.
Говорю сразу, что лучше использовать их, чем смотреть емайлы, потому что их будет очень много, либо это всё надо очень тонко настраивать.

Если кому-то не охота работать с контейнером, то можно взять скрипт (нужет icinga2.sh) установки из git репозитория и запустить его, тоже должно работать, только надо пароли поправить, на что-то понадежнее.

Теперь к контейнеру надо добавить два шаблона один для хоста, а другой для сервисов. Их надо положить в папку /storage/icinga2 которую мы задали при старте контейнера.
Хост — passive-host.conf — можно назвать как хотите, но должен заканчиваться на .conf

template Host "passive-host" {
    max_check_attempts = 2
    check_interval          = 300s
    retry_interval          = 200s
    enable_active_checks = true
    enable_passive_checks = true
    check_command = "passive"
    vars.notification["mail"] = {
    groups = [ "icingaadmins" ]
    }
}

Сервис:

template Service "passive-service" {
    max_check_attempts = 2
    check_interval = 300s
    retry_interval = 200s
    enable_active_checks = true
    check_command = "passive"
    vars.notification["mail"] = {
    groups = [ "icingaadmins" ]
    }
}

Небольшое описание шаблонов
Ждёт пока статус придёт два раза, если оба показывают ошибку, то тогда статус меняется на ошибку.
enable_active_checks = true нужен, чтобы в случае неполучения статуса от сервера поменять его на «неизвестный».
Если два раза не правильный результат, то шлёт емайл. Кстати по опыту могу сказать, что письма сыпятся без перерыва и очень много, особенно в начале и по ним тоже не всегда ясно какой уже сервис снова заработал, а какой нет. Поэтому я советую использовать nagstamon или же всегда смотреть на станицу.
Я раньше помню некоторые письма слали сразу в OTRS, которая создавала тикет, тоже было удобно и клиент сразу всё видел.
Эти два файла надо поместить в папку »/storage/icinga2» и перезапустить контейнер, либо сервис icinga в нём

sudo docker exec -it icinga2 service icinga2 restart

Всё, шаблоны добавлены, теперь можно добавлять системы и всё что надо.

Что дальше?
В принципе до этого не было ничего нового, теперь я покажу, почему пассивный вариант лучше.
Показываю

Для виндовс

Для винды есть готовый клинт — nsclient++. Он может работать в обоих вариантах (пассивный и активный) при пассивном он посылает данные через NSCA, в контейнере Icinga2 этот сервис активен и его можно использовать, обращатся надо через порт 5667. Дла виндовс это хороший вариант, так как тут уже есть всё готовое, можно проверять статус сервисов, смотреть eventlog’и, ну и такие вещи как диск, процессор или память. Так-же при желании можно выполнять произвольные скрипты (надо их сначала написать. Я например писал для lsi raid) вывод которых можно посылать через nsca.

Я уже писал выше, что мы хотели устанавливать icinga у клиентов, но писать конфиги для nsclient++ довольно утомительно и их надо писать для каждого сервера и к тому же на стороне icinga надо тоже писать конфиги.
Я всё это упростил и написал небольшую программку (тогда я мог только AutoIt), которая может генерировать эти два файла для хоста и icinga. Программа находится ТУТ (скачать можно в релизах), называется «Agen» (Alerts Generator)

После того, как распаковали, надо подправить config.xml

    
        2
        monitoring.server.local
        NSCAPASS
    
    
        passive-host
        passive-service
        HOSTGROUP
        SERVICEGROUP
    

interval — время проверки в минутах
address — dns или ip icinga cервера
password — NSCA пароль (который написали выше при создании контейнера)
htemplate — название шаблона для хоста (было уже выше)
stemplate — название шаблона для сервисов
hgroup — группа хостов, если к примеру вы их хотите поделить. К примеру Hosting, DataCenter2 итд или для разных клиентов, как было в моём случае. Можно кстати потом привязать пользователя к одной группе
sgroup — тоже, что и выше, только для сервисов

Теперь можно запустить Agen и выбрать папку, где находится source.txt и config.xml
Выглядит это так:

Часть информации берется из congig.xml, надо только добавить «Host Alias» и «Host Display Name» (будет отображаться на странице).

Информаци слева берётся из source.txt.
Как пользоваться:
Слева выбираете, что у вас работает на этом сервере. К примеру выбираете «winExchange2013» и «eveExchange2013», пишете Host Alias (без пробелов) и Host Display Name (можно с пробелами), если нужна к этому конфигурация для icinga, то ставите галочку. После этих манипуляций появятся два файла:
hostalias.conf — его надо скопировать в контейнер (/storage/icinga2) и перезагрузить icinga
nsclient.ini — скопировать в папку, где установлен nsclient++

Что есть в source.txt
Собственно весь Аgen крутится вокруг этого файла, всё делится на две части
«win» — виндовс сервисы
«eve» — события из eventlog
То есть, если выбрать «winExchange2013», то в конфиги добавятся все сервисы, которые относятся к Exchange 2013 и будут мониторится. Если к этому выбрать ещё и «EveID Exchange 2013», то к этому добавятся ещё и события из eventlog«a.
То есть после того как вы это сделали и надавили окей у вас появятся два файла «nsclient.ini» и «SERVER.conf». После этого надо положить nsclient.ini в папку, где установлен nsclient++, а SERVER.conf добавить к контейнеру (как при сосздании passive-host.conf и passive-service.conf). А после этого надо всё перезагрузить — сервис «nsca» перезапустить, так-же надо перезапустить сервис icinga2.

Единственный момент, сервисы в source.txt нызываются по немецкий, так что их надо будет переименовать.
Пример:
MSExchangeADTopology: Windows_Dienst_Ex_AD_Topology
MSExchangeADTopology — это часть везде одинаковая, независимо от языка системы, а вот вторая часть уже везде разная.

Собственно про видновс это всё.

Линукс

Тут всё несколько сложнее, так как клиента похожего на nsclient++ нету.
Есть три способа, можно установить «send_nsca», потом написать скрипт и через «send_nsca» слать статус, скрипты будут выполняться каждые две минуты по крону.
Второй способ это слать те же самые данные через icinga2 api. Я напимер использую второй вариант, для этого я использую node.js и для него я сделал модуль, он лежит на npmjs.com.
Третий способ, это использовать готовые скрипты и всё таки настроить активные опросы. Но тут я не подскажу, так как стараюсь всё таки этого избегать.
Не смотря на то, что я в работе использую практически только линукс писать скрипты для линукса мне практически не приходиться, так как у нас всё работает через докер.

Для докера я тоже сделал контейнер, который может видеть (через docker.sock) сколько есть контейнеров на хосте. Также он может создавать для каждого контейнера в icinga2 хост и его потом мониторить. То есть получается динамичный мониторинг. Если контейнер удаляют с докер хоста, то он также удаляется и из мониторинга.

Заключение
В принципе выше уже всё сказано, могу лишь добавить, что если кто-то решает, что использовать, то может попробовать. Докер контейнер очень упрощает процесс установки и очень хорошо подходит для попробовать.
Сама по себе icinga2 довольно проста в настройке и через некоторое время становится всё ясно. Для себя я сделал несколько несколько вещей (которые я выше описал), чтобы упростить использование. Также для тех кто может использовать nodejs может писать для себя скрипты, по ссылке ниже есть библиотека для этого.
Я особо сильно не люблю углубляться в технические части, всё банально гуглится и находится.

Ссылки:
1. Icinga2 Docker — контейнер с образом icinga2 2.6
1а. Гит репозиторий, если кому-то нужны только скрипты установки icinga2.
2. Agen — генератор конфигураций для nsclient++
3. Nsclient++ — клиент для виндовс
4. dockerhost-monitoring — контейнер, чтобы мониторить состояния всех контейнеров на отдельном докер хосте.
5. Docker Container NSCA monitoring — старый вариант мониторинга контейнеров (через nsca)
6. Icinga2 API nodejs — модуль/библиотека для nodejs
7. aditosnmp — пример опроса snmp. Здесь как раз тот момент, когда приходится опрашивать статус через snmp, а потом слать статус. Надо смотреть «app.js»

И несколько не в тему, контейнер для бекапа контейнеров и не только — nodebackup. Жалко просто, что я его залил на гитхаб, а не кто не знает.

Комментарии (0)