Всем привет. Я — сисадмин linux, переехал из России в Австралию по независимой профессиональной визе в 2015 году, но статья будет не о том, как поросёнку завести трактор. Таких статей уже и так достаточно (тем не менее, если будет интерес — напишу и про это), так что я хотел бы рассказать о том, как на своей работе в Австралии в должности linux-ops-инженера я был инициатором миграции с одной системы мониторинга на другую. Конкретно — Nagios => Icinga2. Статья частично техническая и частично — про общение с людьми и проблемы, связанные с разницей в культуре и методах работы. К сожалению тэг "code" не подсвечивает код Puppet и yaml, так что пришлось использовать "plaintext". Ничто не предвещало беды утром 21 декабря 2016 года. Я, как обычно, читал Хабр незарегистрированным анонимусом в первые полчаса рабочего дня, поглощая кофе и наткнулся на эту статью. Поскольку в моей компании как раз использовался Nagios, я, недолго думая, создал тикет в Redmine и скинул ссылку в общий чат, поскольку счёл это важным. Инициатива наказуема даже в Австралии, так что ведущий инженер повесил эту проблему на меня, раз уж я её обнаружил.  У нас в отделе перед изложением своего мнения принято предложить как минимум одну альтернативу, даже если выбор очевиден, так что я начал с гуглирования какие вообще системы мониторинга на данный момент актуальны, поскольку в России на последнем месте работы у меня была своя собственная самописная система, очень примитивная, но тем не менее вполне себе рабочая и выполняющая все возложенные на неё задачи. Python, Питерский Политех и метро рулят. Нет, метро — отстой. Это личное (11 лет работы) и достойно отдельной статьи, но не сейчас. Немного о правилах внесения изменений в конфигурацию инфраструктуры на моём текущем месте. У нас используется Puppet, Gitlab и принцип Infrastructure as a Code, так что: Итак, варианты, которые я рассмотрел:  В итоге я остановился на Icinga2 по трём причинам: 1 — совместимость с Nrpe (клиентской службой, которая запускает проверки по командам от Nagios). Это было очень важно, потому что у нас на тот момент было 135 (сейчас на 2019 их 165) виртуальных машин с кучей самописных сервисов/проверок и переделывать это всё было бы лютым геморроем.
2 — все конфигурационные файлы текстовые, что позволяет легко править это дело, создавать merge requests с возможность видеть что добавлено или удалено.
3 — это живой и развивающийся OpenSource проект. У нас очень любят OpenSource и делают посильный вклад в него путём создания Pull Requests и Issues для решения проблем. Итак, поехали, Icinga2. Первое, с чем пришлось столкнуться — инертность коллег. Все привыкли к Нагиосу/Наджиосу (хотя даже здесь не смогли придти к компромису как это произносить) и интерфейсу CheckMK. У icinga интерфейс выглядит капитально иначе (это был минус), но есть возможность гибко настраивать то, что нужно видеть с помощью фильтров буквально по любому параметру (это был плюс, но я за него знатно повоевал). Оцените отношение размера скролл-бара к размеру поля для прокрутки. Второе — все привыкли видеть всю инфраструктуру на одном мониторе, потому что CheckMk позволяет работать с несколькими хостами Nagios, но интерфейс Icinga так не умел (на самом деле умел, но об этом ниже). Альтернативой была вещь под названием Thruk, но её дизайн вызывал рвотные позывы у всех членов команды, кроме одного — того, кто это предложил (не я).  Спустя пару дней мозгового шторма я предложил идею кластерного мониторинга, когда есть один мастер-хост в production-зоне и два подчинённых — один в dev/test и один внешний хост, расположенный у другого провайдера с целью мониторить наши сервисы с точки зрения клиента или постороннего наблюдателя. Такая конфигурация позволяла видеть все проблемы в одном web-интерфейсе и вполне себе работала, но Puppet… Проблема с Puppet заключалась в том, что мастер-хост теперь должен был знать о всех хостах и службах/проверках в системе и должен был распределять их между зонами (dev-test, staging-prod, ext), но отправка изменений через Icinga API занимает пару секунд, а вот компиляция каталога Puppet всех сервисов для всех хостов — пару минут. Это мне до сих пор вменяют в вину, хотя я уже несколько раз объяснял как всё работает и почему это всё так долго. Третье — куча SnowFlakes (снежинок) — вещей, которые выбиваются из общей системы, потому что в них есть что-то особенное, поэтому общие правила к ним неприменимы. Решалось путём лобовой атаки — если есть тревоги, но по факту всё в порядке, значит тут надо копать глубже и разбираться почему оно у меня алёртит, хотя не должно. Или наоборот — почему Нагиос паникует, а Icinga — нет. Четвертое — Нагиос работал тут до меня три года и к нему доверия было изначально больше, чем к моей новомодной хипстерской системе, так что каждый раз, когда Icinga поднимала панику — никто ничего не делал, пока Нагиос не возбуждался по тому же вопросу. Но очень редко Icinga выдавала реальные тревоги раньше, чем Nagios и я считаю это серьёзным косяком, о котором расскажу в разделе "Выводы". В итоге, ввод в эксплуатацию затянулся больше, чем на 5 месяцев (планировалось 28 июня 2018, по факту — 3 декабря 2018), в основном из-за "parity check" — той хрени, когда есть несколько сервисов в Нагиос, о которых никто ничего не слышал последние пару лет, но ИМЕННО СЕЙЧАС они, блин, выдали crit без какой-либо причины и мне пришлось объясняться почему их нет на моей панели и пришлось добавить их в Icinga, чтобы "parity check is complete" (Все службы/проверки в Нагиос соответствуют службам/проверкам в Icinga) Внедрение:
Первое — война Code vs Data, типа Puppet Style. Все данные, прямо вот вообще все, должны быть в Hiera и никак иначе. Весь код — в файлах .pp. Переменные, абстракции, фунции — всё идёт в pp.
В итоге — у нас есть куча виртуальных машин (165 на момент написания статьи) и 68 web-приложений, которые надо мониторить на предмет работоспособности и на действительности SSL-сертификатов. Но из-за исторического геморроя информация для мониторинга приложений берётся из отдельного gitlab-репозитория и формат данных не менялся со времён Puppet 3, что создаёт дополнительные сложности в конфигурациии. Код конфигурации хостов и сервисов тоже выглядит ужасно: Я до сих пор работаю над этой лапшой и улучшаю её по мере возможности. Однако именно такой код позволил использовать простой и понятный синтаксис в Hiera: Все проверки разбиты на группы, у каждой группы есть дефолтные настройки вида где и как часто запускать эти проверки, какие уведомления отправлять и кому. В каждой проверке можно переопределить любую опцию и всё это в итоге складывается ещё и с дефолтными настройками всех проверок в целом. Поэтому в config.pp и написана такая лапша — там идёт слияние всех дефолтных настроек с настройками групп и потом ещё с каждой индивидуальной проверкой. Так же очень важным изменением стала возможность использовать функции в настройках, к примеру, функция подмены порта, адреса и url для проверки http_regex. Это означает — если в определении хоста есть переменная http_port — использовать её, иначе 443. Например, web-интерфейс jabber висит на 9090, а Unifi — на 7443.
http_vhost означает игнорировать DNS и брать этот адрес.
Если в хосте указан uri — то идти по нему, иначе брать "/".  С http_ssl вышла забавная история — эта зараза никак не хотела отключаться по требованию. Я долго тупил в эту строку, пока до меня не дошло, что в переменная в определении хоста: Подставляется в выражение  как false и в итоге получается  то есть проверка ssl получается всегда активна. Решилось заменой синтаксиса: Выводы: Плюсы: Минусы: Но в целом — оно работает. Senior Devops/SRE