Comments 11
Предупреждайте людей что у вас модуль под puppet3, и использует depricated функции. (Хотя в статье у вас паппет 5, в логи сервера не заглядывали ?)
hiera вы используете «божественно». Вдумайтесь в само слово, hiera, hiera, hiera…
Объясняю: Шаблон под каждую ноду писать не нужно, нужно создать уровень объединяющий хосты. Или вообще вынести в common.
hiera вы используете «божественно». Вдумайтесь в само слово, hiera, hiera, hiera…
Объясняю: Шаблон под каждую ноду писать не нужно, нужно создать уровень объединяющий хосты. Или вообще вынести в common.
Спасибо, за комментарий. Сам модуль icinga2 совместим с Puppet >= 3.8.0 < 6.0.0. В логи конечно же смотрим — всё чисто.
Hiera мы используем по-разному, в том числе и так как вы описали, есть common (http://git.comgress64.com/external/puppet-icinga2-how-to/blob/master/code/environments/production/hieradata/common.yaml) с общими проверками. Шаблон под каждую ноду нужен, что бы описать исключительные случаи.
Hiera мы используем по-разному, в том числе и так как вы описали, есть common (http://git.comgress64.com/external/puppet-icinga2-how-to/blob/master/code/environments/production/hieradata/common.yaml) с общими проверками. Шаблон под каждую ноду нужен, что бы описать исключительные случаи.
Если выставить в конфиге puppet.com/docs/puppet/5.5/configuration.html#disablewarnings
то да, все хорошо. а так:
github.com/puppetlabs/puppetlabs-stdlib#validate_array
и прочие validate_* объявлены depricated и куча всего прочего, например is_*, и вот, кстати, в 6 версии их обещают удалить.
Ну и на производительности это не особо красиво сказывается.
то да, все хорошо. а так:
github.com/puppetlabs/puppetlabs-stdlib#validate_array
и прочие validate_* объявлены depricated и куча всего прочего, например is_*, и вот, кстати, в 6 версии их обещают удалить.
Ну и на производительности это не особо красиво сказывается.
Что бы люди не выдумывали, лишь бы не ставить Zabbix.
Про забикс я ничего не знаю, чем он выгоднее?
Zabbix — система совершенно другого уровня.
В отличие от nagios и производных — мониторит значения, а не состояние, и пишет в базу данных.
То есть мы имеем полные исторические реальные значения на любой момент времени, можем строить графики, применять функции (сумма, среднее, статистические функции, математику и прочее) на любой параметр.
Удобство — помимо point-n-click в веб-интерфейсе, с которым справится любой человек (и которых застрахован от ошибок синтаксиса текстовых файлов конфигурации) есть полноценный API. Интеграция с чем угодно и как угодно.
Разныв виды discovery. Авторегистрация (включая обнаружение) хостов, автоматическое обнаружение партиций, сетевых адаптеров + вообще чего угодно.
По сравнению с Zabbix — производные от nagios (включая icinga) — это детские поделки с кучей текстовых файлов-конфигураци и набором костылей.
Да, в Icinga есть API, но там оно тоже из раздела «костыль».
Вот пример.
Нужно мониторить диски на сервере. При создании нового диска (добавлена партиция), которые не является съемным (не флешка), нужно автоматически добавлять его к мониторингу. И, на основе правил, строить прогноз окончания дискового пространства.
Если по прогнозу место на этом диске закончится менее, чем через 24 часа — слать информативный месседж.
Если же по прогнозу место закончится менее, чем через 3 часа, но при этом места (в байтах) все еще больше, чем значение макроса для этого хоста или темплейта, и при этом значение сводобного места в процентах, чем указано в макросе для хоста — то слать уведомление с уровнем high.
Это лишь совсем простые примеры. Попробуйте построить гибкие триггеры на Icinga (с разными условиями под каждый алерт, и промониторить автоматически добавляемый не-съемный носитель с индивидуальными параметрами (при том что другие диски могут иметь свои).
Плюс ставится Zabbix быстрее и настраивается проще. Имеет гибкую систему пользовательских прав, поддерживает аудит действий всех пользователей и прочее, прочее, прочее… Тут из раздела «небо и земля», их попросту сравнивать нельзя.
В отличие от nagios и производных — мониторит значения, а не состояние, и пишет в базу данных.
То есть мы имеем полные исторические реальные значения на любой момент времени, можем строить графики, применять функции (сумма, среднее, статистические функции, математику и прочее) на любой параметр.
Удобство — помимо point-n-click в веб-интерфейсе, с которым справится любой человек (и которых застрахован от ошибок синтаксиса текстовых файлов конфигурации) есть полноценный API. Интеграция с чем угодно и как угодно.
Разныв виды discovery. Авторегистрация (включая обнаружение) хостов, автоматическое обнаружение партиций, сетевых адаптеров + вообще чего угодно.
По сравнению с Zabbix — производные от nagios (включая icinga) — это детские поделки с кучей текстовых файлов-конфигураци и набором костылей.
Да, в Icinga есть API, но там оно тоже из раздела «костыль».
Вот пример.
Нужно мониторить диски на сервере. При создании нового диска (добавлена партиция), которые не является съемным (не флешка), нужно автоматически добавлять его к мониторингу. И, на основе правил, строить прогноз окончания дискового пространства.
Если по прогнозу место на этом диске закончится менее, чем через 24 часа — слать информативный месседж.
Если же по прогнозу место закончится менее, чем через 3 часа, но при этом места (в байтах) все еще больше, чем значение макроса для этого хоста или темплейта, и при этом значение сводобного места в процентах, чем указано в макросе для хоста — то слать уведомление с уровнем high.
Это лишь совсем простые примеры. Попробуйте построить гибкие триггеры на Icinga (с разными условиями под каждый алерт, и промониторить автоматически добавляемый не-съемный носитель с индивидуальными параметрами (при том что другие диски могут иметь свои).
Плюс ставится Zabbix быстрее и настраивается проще. Имеет гибкую систему пользовательских прав, поддерживает аудит действий всех пользователей и прочее, прочее, прочее… Тут из раздела «небо и земля», их попросту сравнивать нельзя.
Sign up to leave a comment.
Автоматизация системы мониторинга на базе Icinga2 и Puppet