Поднимаем микромониторинг на icinga2 с минимальными затратами

[@de1m]

Я на старой работе делал мониторинг на icinga1 и теперь на нынешней сделал на icinga2.
Когда надо следить за системами в другой сети, то приходится открывать порты, что не очень хорошо, поэтому я советую делать пассивные сервисы(это когда сервера сами шлют свой статус в icinga2). Раньше я использовал для этого nsca, теперь потихоньку перехожу на api.
Вот тут(смотреть релизы) я написал небольшую програмку, которая сидит в трее и показывает статус, если что не так(это была моя первая программа в electron и вторая в javascript, поэтому код ужасен).
Если кто-то хочет сделать с nsca, то вот тут есть небольшая программа которая может писать для клиента nsclient++ конфигурации. Очень удобно.
Если кому интерсно, то есть еще docker container с icinga2 и соответственно штука, чтобы мониторить контейнеры и создавать для них автоматом сервисы, ну и стирать разумеется.

Но у меня создаётся впечетление, что icinga2 не очень сильно распростаннена.

[@Kostyanych]

А можно ткнуть в примеры пассивных сервисов — как раз такой подход хотелось бы реализовать.

[@de1m]

Да без проблем.
Вот тут есть готовый докер контейнер, где уже есть icinga2, nsca, graphite и при желании аутентификация через active directory. Там в контейнере есть одни косяк — надо руками включать icinga2 api (icinga2 feature enable api), пока времени нету переделать.
Если нет желания возиться с докером, то можно тут выдрать скрипты(icinga24.sh работает в убунту) и по ним всё поставить. Там уже будет нсца.
Потом надо, сделать шаблон, сперва для сервиса:

template Service "passive-service" {
        max_check_attempts = 2
        check_interval = 3m
        retry_interval = 0
        enable_active_checks = true
        check_command = "passive"
        vars.notification["mail"] = {
        groups = [ "icingaadmins" ]
        }
}е

Потом шаблон для хоста:

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

Пеперь пример конфигурации для хоста:

object Host "4demo" {
        import  "passive-host"
        display_name =          "testserveradito"
        vars.group =            "demo"
}

Для сервиса:

object Service "cpu" {
        import  "passive-service"
        host_name       ="4demo"
        vars.group      ="demo"
}

Если хочешь мониторить виндовс, то для него есть клиент — nsclient++
Конфигурация для него выглядит как-то так:
[/modules]
CheckSystem=enabled
CheckDisk=enabled
CheckEventLog=enabled
CheckLogfile=enabled
CheckWMI=enabled
CheckExternalScripts=enabled
CheckHelpers=enabled
Scheduler=enabled
NSCAClient=enabled
[/settings/external scripts/alias]
alias_cpu = checkCPU warn=99 crit=100 time=5m time=1m time=30s
alias_mem = checkMem MaxWarn=99% MaxCrit=100% ShowAll=long type=physical type=virtual type=paged type=page
alias_disk = checkDriveSize MinWarn=8% MinCrit=5% CheckAll FilterType=FIXED
alias_up = checkUpTime MinWarn=1d MinWarn=20m
[/settings/scheduler/schedules/default]
interval=2m
[/settings/scheduler/schedules]
cpu=alias_cpu
host_check=check_ok
[/settings/NSCA/client]
hostname=4demo
[/settings/NSCA/client/targets/default]
address=monitoring.server.local
encryption=1
password=ANf8m348asmfa8asdfasdf(gleich wie in NSCA SERVER)


Вот тут я когда-то написал небольшую програмку, которая может генерирвать конфиги для nsclient++ и для icinga2. На выходе получаешь два файла — nsclient.ini (nslient++) и host.conf(для icinga2). Эти файлы надо только скопировать и перезагрузить сервисы.

Ну и теперь немного как это всё в целом работает:
Сервер (icinga2) ждёт на порте 5667 пока ему сервер пришлёт данные, если они не приходят в течении периода «check_interval», то выполняется команда «check_command» и статус сервиса или хоста меняется.

Я перехожу потихоньку с nsca на icinga2 api. Пишу скрипты на ноде, можно динамически удалять или добавлять сервисы. Иногда это полезно.
Вот тут я к примеру сделал докер контейнер, который сморит на все остальные контейнеры и проверяет работают ли они. Если контейнер стереть, то хост так-же удаляется из мониторинга, тоесть получается динамический мониторинг.

[@las68]

icinga2 — хорошая штука. Надо статью про Director написать.

[@ArjLover]

А где-то можно посмотреть на демо icinga2? Интересует именно конфигурирование через веб и графики.

[@mrpsycho]

очень надо!

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

[@las68]

С коробки, в норме, не встаёт. Есть пара нюансов, но надо внимательно читать форум и иногда читать немецкие комментарии.

Там Das Bubenshamanen, но работает! и Томас Гельф пилит Директор каждый день. Немцы молодцы — они тщательные.

Начну потихоньку писать. В icinga2 всё по другому, но когда это будет доведено до конца, это будет очень круто!

[@SchmeL]

Перешли недавно с Zabbix на Icinga2 + Grafana + Graphite (icinga2 берет метрики для анализа из графита).
Очень не хватает звукового уведомления о проблемах. Может есть какое-нибудь внешнее средство для этого?

[@plsatin]

Есть модуль к icingaweb2 — NagVis, у него есть звуковые уведомления.

[@de1m]

Посмотрите вот это. Использует icinga2 api и в винде, да и линуксе тоже выдаёт системные сообщения со звуком

[@SchmeL]

Спасибо, попробую. Пока нашел модуль для icinga2web — icinga2-dashboard

[@xtotec]

Из всех клонов и потомков Nagios болше всего мне пришелся по душе omdistro.
всё продумано, можно выбрать себе «морду» по эстетическим требованиям. Хочешь — nagios classic, icinga, suriken, WATO. NagVis в комплекте, настраивается всё очень разумно. За счёт того что check_mk написан на python куда приятнее пользоваться им, а он уж сам генерит конфиги для nagios core. Всячески рекомендую.

[@Kostyanych]

Спасибо за статью.
На данном этапе делаю начальные шаги…
Надо будеть попробовать прикруть Grafana + Graphite