Сравнение систем мониторинга: Shinken vs Sensu vs Icinga 2 vs Zabbix

Original author: Dmitry Verhoturov
  • Translation

Shinken


Согласно официальному сайту, Shinken — фреймворк мониторинга; переписанный с нуля на питоне Nagios Core, с улучшенной поддержкой больших окружений и более гибкий.


Масштабируемость


Согласно документации, каждый тип используемых процессов может запускаться на отдельном хосте. Это очень полезная возможность, поскольку вы можете захотеть иметь базу данных в самом дешёвом месте, процессы сбора информации в каждом датацентре, и процессы рассылки уведомлений ближе к своему физическому расположению. Пользователь Shinken на схеме счастлив, это точно является хорошим признаком:


Shinken simple distributed architecture


Эта система также имеет готовую конфигурацию для межрегионального мониторинга, называемая Realms (Сферы).


Здесь вы можете заметить кое-что изумительное: информация собирается в региональные базы данных, а не в одну мастер-базу. Также существует меньшая разновидность конфигурации со сферами для меньших распределённых конфигураций, которая требует всего одну базу данных и несколько хостов для установки:


Shinken simple multi-regional distributed architecture


Ещё одной болевой точкой при оценке масштабируемости является отказоустойчивость. Эту информацию я процитирую из документации:


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

Интеграция с системами управления конфигурацией


Автоматическое нахождение хостов и сервисов хорошо покрывается документацией, и, поскольку конфигурация хранится в файлах, вы довольно просто можете генерировать её с помощью Chef\Puppet, основываясь на информации, уже имеющейся в системе конфигурации (например, PuppetDB).


Логирование действий


Поскольку конфигурация хранится в файлах, вы можете использовать имеющиеся инструменты типа системы контроля версий (Git, Mercurial) для отслеживания изменений и их владельцев. В документации я не нашёл никаких подтверждений того, что Shinken записывает куда-либо действия пользователя в веб-интерфейсе.


UI


Shinken UI


Shinken WebUI по заверениям использующих его людей хорошо показал себя при работе с тысячами машин и десятками групп.


Недостатки


Прошерстив документацию, я не нашёл видимых недостатков. Единственная вещь, которая меня смущает, это стремительная разработка в прошлом и очень медленный темп коммитов в настоящем: около 40 в этом году, большинство — вливание пулл-реквестов с багфиксами. Система или слишком хороша для дальнейшего развития (чего не бывает в природе, даже такие старички, как vim и emacs получают новые релизы), или теперь это ещё один открытый проект с недостаточно большим сообществом или проблемами с мейнтейнером — это такая информация, которую хотелось бы знать до начала использования такой комплексной вещи, как система мониторинга.


Frédéric Mohier, бывший когда-то в команде разработки Shinken любезно предоставил информацию по этому вопросу: больше года назад несколько разработчиков из команды, будучи несогласными с политикой разработки, покинуло проект и сделало форк, названный Alignak, в данный момент активно разрабатываемый, первый стабильный релиз (1.0) планируется на декабрь 2016.


Ссылки



Sensu


Sensu — фреймворк для мониторинга (или платформа, как они сами о себе говорят), но не готовая система мониторинга.


Её сильные стороны включают:


  • Интеграция с Puppet \ Chef — определяйте, что проверять, и куда отправлять уведомления прямо в вашей системе управления конфигурацией
  • Использование имеющихся технических решений там, где это возможно, вместо изобретения велосипедов (Redis, RabbitMQ)

Sensu вытягивает события из очереди и выполняет на них обработчики, вот и всё. Обработчики (Handlers) могут посылать сообщения, выполнять что-то на сервере, или делать что угодно ещё, чему вы их научите.


Масштабируемость


Sensu имеет гибкую архитектуру, поскольку каждый компонент может быть продублирован и заменён несколькими путями. Пример простой отказоустойчивой системы описан в следующей презентации; вот общая схема:


Sensu architectural diagram


С HAProxy и Redis-sentinel вы можете построить систему, в которой, при наличии хотя бы одной живой машины каждого типа (Sensu API, Sensu Dashboard, RabbitMQ, Redis) мониторинг будет продолжать работать без какого-либо ручного вмешательства.


Интеграция с системами управления конфигурацией


Встроенная (Puppet, Chef, EC2?!) но только в платной версии, что плохо, особенно если у вас тысячи серверов и вы не хотите платить за что-то, имеющее бесплатные аналоги.


Логирование действий


Встроенное, однако только в платной редакции.


UI


Uchiwa screenshot


Интерфейс по-умолчанию для Sensu, Uchiwa, имеет много ограничений. Он выглядит слишком простым для окружения с тысячами хостов, которые имеют большой разброс по ролям. Платная версия имеет свой собственный дашборд, однако он не сильно отличается от бесплатной редакции, и только добавляет несколько выключенных из-коробки возможностей открытой версии.


Недостатки


  • Отсутствие исторической информации и очень ограниченные возможности создания проверок, основанной на ней;
  • Подход "сделай сам" — нет готового мониторинга, который можно было бы включить для вашей системы сразу после установки;
  • Агрегирование событий нетривиально;
  • Замудрёная отправка сообщений, что страшно (потому что это та часть системы, которая должна быть самой простой и надёжной) — неправда, я получил неправильное впечатление от документации, спасибо x70b1 за разъяснение;
  • Путь "мы не хотим изобретать колесо" имеет свои ограничения, которые могут быть вам знакомы, если вы когда-либо использовали подобные системы (в моём случае, это была система мониторинга Prometheus, которая оставляла ряд функций на откуп пользователю, например, авторизацию\аутентификацию\идентификацию).

Ссылки



Icinga 2


Icinga это форк Nagios'а, во второй версии переписанный с нуля. В отличии от Shinken, этот живой, часто обновляющийся проект.


Масштабируемость


Общая архитектура:


Icinga 2 architecture


Icinga 2 имеет хорошо продуманную схему распределённого мониторинга. Единственный минус, который я обнаружил при поднятии тестового кластера — сложная изначальная настройка даже самой простейшей распределённой схемы.


Интеграция с системами управления конфигурацией


Интеграция довольно хороша, вот две презентации по теме: The Road to Lazy Monitoring with Icinga 2 and Puppet от Tom de Vylder, и Icinga 2 and Puppet: Automated Monitoring от Walter Heck. Ключевой особенностью Icinga является хранение конфигурации в файлах, что позволяет легко генерировать конфигурацию средствами Puppet, что в моём случае получилось, используя PuppetDB в качестве источника информации о всех хостах и сервисах.


Логирование действий


Как я обнаружил, логирование действий представлено в модуле director. Встроенной поддержки аудита в IcingaWeb2 в данный момент нет.


UI


Icinga 2 web interface


IcingaWeb2 выглядит неплохим UI с большим количеством дополнений под разные нужды. Из того, что я видел, он выглядит самым гибким и расширяемым, в то же время из коробки поддерживая все возможности, которые вы можете ожидать.


Недостатки


Единственным недостатком, который я встретил, является сложность изначальной настройки. Непросто понять взгляд Icinga на мониторинг, если вы до этого использовали что-то совершенно иное, как, в моём случае, Zabbix.


Zabbix


Zabbix — стабильная и надёжная система мониторинга с устойчивой скоростью развития. Он имеет огромное сообщество пользователей и большинство вопросов, которыми вы зададитесь, уже где-то отвечены, так что вам не прийдётся лишний раз волноваться, а возможно ли то или иное в Zabbix.


Масштабируемость


Сервер работает с единственной базой данных, и вне зависимости от ваших действий, с любыми другими ресурсами на руках (память, сеть, CPU), вы в какой-то момент упрётесь в ограничения IO на диске, используемом базой данных. С 6000 IOPS в Amazon мы поддерживаем около двух тысяч nvps, новых значений в секунду, что неплохо, но всё же оставляет желать лучшего. Прокси и partitioning базы данных улучшает производительность, однако с точки зрения отказаустойчивости вы всё ещё имеете одну-единственную БД, которая является точкой отказа для всей системы.


Интеграция с системами управления конфигурацией


Zabbix слабо подготовлен для разнообразного окружения, которое управляется системой управления конфигураций. Он имеет встроенные возможности для low-level обнаружения хостов и сервисов, но они имеют свои ограничения и не имеют привязки к системе конфигурации. Единственная возможность для подобной интеграции — собственное решение, использующее API.


Логирование действий


Zabbix хорошо логирует действия пользователей, за исключением одного слепого пятна: изменения, сделанные через API, большей частью не логгируются, что может быть или может не быть проблемой для вас. Ещё одна вещь, которую я хотел бы упомянуть, это то, что все проблемы с Zabbix записаны где-то в баг-трекере, и, если они получают достаточно внимания со стороны сообщества, то рано или поздно устраняются.


UI


Dashboard is a main screen of Zabbix


UI Zabbix'а удобен и включает в себя много возможностей. Обратная сторона — он практически не расширяем, вы или смиряетесь с тем, что предлагает вам стандартный dashboard, либо создаёте свой собственный. Доработка стандартного UI является очень нетривиальной задачей из-за его сложности.


Недостатки


  • Только базовая аналитика о том, что происходит в данный момент (не в плане текущих проблем, а частоты из происхождения и подобной информации). Ситуация сильно улучшилась с появлением "топ 100 стреляющих триггеров" в 3.0;
  • Настройка плановых работ (maintenance), в отличии от систем, основанных на Nagios, не может быть выставлена на уровне триггера, и была довольно сложной до недавней переделки 3.2;
  • Генерация алертов из-коробки оставляет желать лучшего (что, впрочем, является проблемой всех до единой систем мониторинга). В нашем случае пришлось разработать внешнюю систему аггрегации алертов (возможно, когда-нибудь она будет опубликована в opensource);
  • Расследование проблем с производительностью без соответствующего опыта превращается в беспорядок, потому что у вас есть один неделимый сервер, который вам необходимо диагностировать.

Disclaimer


Это длинная запись с большим количеством картинок и ещё большим количеством текста. Здесь вы не найдёте однозначного ответа на простые вопросы наподобие "что лучше", но информацию для ответа на эти вопросы, основываясь на вашем опыте и желаниях. Я рассматриваю условия работы в Linux и слежения за Linux-хостами, поэтому поддержка системой разных платформ в расчёт не принималась. Также за условие принималось требование возможности следить за тысячами машин и тысячами сервисов.


По моему мнению, только Zabbix и Icinga 2 являются достаточно зрелыми для использования в "энтерпрайзе", главный вопрос, который должен задать себе тот, кто выбирает систему — какая философия мониторинга ему ближе, поскольку обе они позволяют получить один и тот же результат, используя совершенно разные подходы.

Share post

Similar posts

Comments 41

    0
    Сколько же этих систем мониторинга существует — жуть.
    Вот тут 51 насчитали.
      0
      Там смешались в кучу сервисы, софт. И все возможные весовые категории: monit в одном ряду со стеком продуктов HP/IBM.
      0
      Сравнивать клоны игрушечной системы типа Nagios не предназначенной для настоящей работы и Zabbix глупо. Zabbix — система мониторинга продакшен-левела, с сильной командой за ней, с платной поддержкой, с курсами, с собственными железными решениями с заббиксом на борту(до сих пор только в Японии вроде продающимся, правда) и нагиос написанный фриком для фрика и не способный работать больше чем с пятком серверов.

      Использовал и то, и другое. О нагиосе вспоминаю, как о страшном сне. Хвала Владышеву и его команде, что есть Zabbix.
        0
        нагиос написанный фриком для фрика и не способный работать больше чем с пятком серверов
        Чтобы писать о Nagios такое, надо либо ничего про него не знать, либо быть обиженным неосилятором. В любом из этих двух случаев, лучше взять себя в руки и промолчать.
          –5
          Знаете, какая штука, вы еще учились в школе, а я уже админил *nix-like системы. Вот я до сих пор админю, а вы до сих пор не выросли из школьного уровня.
          Я использовал нагиос около пяти лет, так что я могу очень хорошо судить об этой поделке. Извините, но поделие в котором для добавления адреса алерта нужно править конфиги на сервере, а не сказать секретарю «Добавь там в веб-морде» не имеет право на существование. И это я молчу про все остальное.

          Лучше молчите, чем говорите глупости. Я понимаю, что вы админите свой локалхост и там этой глючной поделки хватает за глаза и уши, но однажды родители перестанут вас кормить и вам придется пойти работать, а там нагиос использовать не выйдет.
            0
            нужно править конфиги на сервере, а не сказать секретарю «Добавь там в веб-морде»
            Сколько хостов можно добавить с помощью веб-морды? 10, 50, 100? Веб-морда как раз более ассоциируется с «пятком серверов». Когда нужно связать CMDB с сотней хостов и систему мониторинга, то в первую очередь думаешь об автоматически генерящихся конфигах или API, а в последнюю — о добавлении объектов через веб.
              –1
              И у заббикса есть API, а у Нагиоса нет. Как-то неудачно вышло с вашей защитой этой поделки.
                +1
                Ничего не имею против Zabbix. Четыре года не испытывал проблем с конфигами Nagios. Сейчас использую Icinga, с apply… where массовое управление стало ещё удобнее, а потребности что-то конфигурять из веба так и не возникло.
                  –2
                  Изначально вы пытались оскорблять меня защищая глючную поделку под названием Nagios. Я понимаю, что делать это вас заставляет подростковый комплекс неполноценности, ведь вы же на локалхосте его используете, а тут кто-то посмел о нем сказать правду. Или вы уже забыли, что делали несколько комментов назад?
                    0
                    Изначально вы пытались оскорбить разработчиков и пользователей Nagios. Если отбросить желчный неконструктив, то останется одна претензия — отсутствие настройки из веба. Вот мне и интересно, в каких случаях на масштабах больше «пятка серверов» может остро понадобиться такая настройка.
                      –2
                      Я могу выложить тут список на сотню пунктов претензий к этой детской поделке. Только это смысла не имеет.
                      Поймите вы, что это поделие используют только мамкины какиры на своих локалхостах. Оно не работает в продакшене. Как только вы начнете админить хотя бы один реальный сервер вы забудете о нагиосе и поделиях на его основе.
                        +1
                        вы пытались оскорбить разработчиков и пользователей Nagios
                        мамкины какиры на своих локалхостах
                        Ч. т. д.
                        Пейте ромашковый чай, хорошего настроения и здоровья.
                          –2
                          Оскорбить пользователя Nagios? ЛММ с вами! Я не могу это сделать. Он уже сам себя оскорбил использованием нагиоса и навязыванием его нормальным людям.
                +3
                Знаете… Я вот тоже начинал с нагиоса. И один из критериев моего выбора тогда был — правка конфигов, а не внесение хостов через веб-морду. Тогда я к заббиксу относился на «так себе» как раз, потому что думал, что запарюсь его настраивать через веб морду. Да и любитель консоли я, а не мышки. Но когда серверов перевалило за 30, я задумался…
                Вспомнил про заббикс, прочитал документацию и понял, что эта система на много гибче и лучше нагиоса. После настройки я не добавляю хосты совсем, заббикс их сам обнаруживает и добавляет, автоматически настраивает необходимые элементы данных (что мониторим) и триггеры, автоматически обнаруживает новые диски, интерфейсы и т.п., автоматически обнаруживает виртуальные машины на гипервизорах и начинает отслеживание их состояния и много чего другого.
                Все, что нужно было сделать — это один раз настроить/создать несколько шаблонов и низкоуровневое обнаружение. Все! Дальше заббикс самостоятельно обнаруживает и начинает мониторить все, что мне необходимо. И все это сделано средствами самого заббикса, без каких-либо вспомогательных инструментов.
                  0
                  Какой апи и конфиги? Качайте вот это и подключайте хоть миллион машин к заббиксу с одной команды. Заходить на вебморду при этом не придётся.
                    0
                    У Zabbix как минимум 4 варианта добавления хостов.
                    1) Ручками через веб (по одному)
                    2) XML файлом через веб (пачками)
                    3) API (пачками)
                    4) LLD (пачками)
                0
                Кажется вы чего-то не знаете про нагиос — это давно уже система энтерпрайз-класса и она в принципе платная, то что доступно в опен сорс вообще не сравнимо с их готовым решением
                +1
                Также есть замечательный плагин для связи Zabbix и Grafana — grafana-zabbix, который позволяет реализовать дополнительные дашборды, алерты и прочее, комбинация классического интерфейса Zabbix и Grafana помогает, когда надо наблюдать много параметров(вроде как в классическом интерфейсе Zabbix еще нет возможности на один график наложить несколько метрик сразу от нескольких узлов?) и в том числе визуализировать проблемы производительности какой либо системы.
                Это если говорить про плюсы…
                Про минусы — до сих пор нельзя сделать нормальную выгрузку событий, которые не умещаются на одной странице… экспортируется в CSV стабильно первая страница. Приходится извращаться с API и прямой выгрузкой из базы.
                  +2
                  У всех опенсорсных решений, с которыми я сталкивался, есть общая беда — нельзя одним продуктом покрыть все задачи мониторинга.

                  У Nagios-подобных не хватает статусов (critical/warning/ok недостаточно для кластеров).
                  У Zabbix не хватает возможности вывести подробное описание ошибки (mysql не работает, потому что: connection refused, connection timed out, no route to host, проблемы с dns или сам mysqld себя плохо чувствует?). Хотя здесь могу быть не прав — работал с Zabbix редко.

                  В обоих системах нельзя красиво реализовать уведомления на страшные вещи, наподобие «Пришел OOM Killer и всех убил».

                  В итоге использую связку Sensu + InfluxDB (grafana, telegraf) + Graylog (rsyslog), все уведомления от которых прилетают в alerta. С такой связкой у эксплуатации есть оперативный мониторинг с правильными приоритетами и максимумом информации, у разработчиков есть доступ к логам приложения с поиском, у тестировщиков есть APM c разрешением в 10 секунд.
                    0
                    Угу, вот и приходится собирать мониторинг из 5 разных продуктов.
                      0

                      Подробного описания ошибок Zabbix действительно не хватает. Ситуация улучшается, но всё равно для диагностики проблем самой системы мониторинга нужно иметь довольно большой объём знаний — много нюансов, и сообщения об ошибках дают только необходимый минимум информации.


                      По моему опыту, можно обходится и одной системой, если дописывать свои обвязки к ней. У нас возле Zabbix крутится порядка двадцати разных скриптов и есть штук шесть-восемь патчей к коду (большинство опубликовано в zabbix-patches и в соответствующих ZBX- и ZBXNEXT-), я ещё подумаю, и, скорее всего, напишу о них отдельную запись — пока непонятно, будет ли это полезно\интересно сообществу.

                        0
                        У нас аналогично крутятся обвязки для sensu, по API скармливающие результаты проверок.

                        Если нужен только инфраструктурный мониторинг и базовый APM — тогда Zabbix может и подойти. Если же нужно с сотни серверов собирать 100-200 метрик с разрешением в 10 секунд и потом собирать данные в один dashboard — заббиксу с большой вероятностью станет плохо. InfluxDB такую нагрузку даже не замечает.
                        Если нужно собирать логи с серверов и делать поиск по ним — опять же, нужна еще одна система.

                        Опять же, для APM нужно вывести breakdown вида «10 самых тяжелых запросов в базу», плюс по statsd получать метрики самого приложения.
                          0

                          Для метрик есть Graphite, мы делим мониторинг и метрики, поскольку метрик очень много. В системе мониторинга есть только то, что важно (то есть то, по чему есть триггеры).
                          Я пока не видел живых систем, где всё пишется в метрики и мониторинг смотрит ровно туда же, куда и люди — думаю, это интересный подход, хотя и не без своих недостатков.

                            0
                            Вот, то есть у вас уже минимум две системы для мониторинга :)

                            > Я пока не видел живых систем, где всё пишется в метрики и мониторинг смотрит ровно туда же, куда и люди
                            Я примерно такой подход реализую — в Sensu напрямую заводятся только те проверки, в которых nagios хорош: отпинать порт; проверить код ответа http; подключиться к БД; проверить, что на хосте нормально собираются метрики (запущены все агенты); плюс пара критичных проверок CPU/LA (на случай, если telegraf по какой-либо причине упадет).

                            Остальные метрики попадают в InfluxDB, дальше отдельная проверка делает select метрик и по API отправляет статусы (а-ля external check в nagios).

                            Из плюсов — не обязательно, чтобы на машине стоял агент sensu, достаточно отправлять метрики; можно делать довольно сложные запросы к метрикам (influxdb умеет по абсолютным значениям высчитывать изменение и количество операций в секунду); плюс метрики не собираются два раза.
                            Из минусов — для полноценного мониторинга надо два агента на сервере — telegraf и sensu, плюс rsyslog.
                      0
                      Пробовал всё, nagios-подобное интересно, но плохо администрируется руками множества администраторов одновременно. Мой выбор — Zabbix. Ему главное партиционировать базу и выжидать на форуме не менее 2 месяцев с момента очередного релиза, даже если речь о минорных релизах, иначе будете немедленно наказаны сексом в неожиданных местах. Релизная политика не подразумевает выпуск фикса найденного бага ASAP, скажем фиксы ODBC-запросов в базы несколько релизов как сломана. Но остальные гораздо слабее по фичам и удобству для команды админов.

                      В мире опенсорса никто никому ничего не обязан, и я не устаю повторять: огромное спасибо Алексею и команде за этот замечательный продукт, которыми они так щедро делятся. Мои брюзжания это брюзжания того, работа кого каждый день добровольно связана с zabbix.
                        0
                        Nagios-подобные системы очень хорошо интегрируются с системами управления конфигурациями. Софт ставится на мониторинг в том же месте, в котором он устанавливается.
                        0
                        Как каждый из этих сервисов выглядит в контексте #monitoringsucks, упомянутого в этой статье?
                          0

                          Не знаю. Я всегда думал, что проблемы с плохим мониторингом — не технические, хорошему мониторингу мешает плохое видение, а не ограничения или архитектура системы. Конечно, если вы не используете Nagios.

                            0
                            Что у Zabbix, что у Nagios-подобных есть большие ограничения в плане архитектуры :)
                            Zabbix хочет, чтобы результат проверки был числом (и хочет иметь локальную копию этого числа), Nagios же хочет видеть exit code 0-3.

                            У Enterprise таких ограничений нет — в них системы генерируют Event-ы с произвольным текстом и метаданными. Под капотом может быть как проверка числовых метрик (Zabbix-like), так и проверка статуса (Nagios-like), так и единичные события, полученные из логов (Out of memory: kill process XXXX).

                            Более того, такой подход позволяет делать корреляцию событий, идеальная система может сразу искать root cause: «Сервис поиска выдает ответ более чем за 5 секунд, потому что одна VM лежит (гипервизор упал — нет питания), а вторая виртуалка упирается в I/O (на гипервизоре ребилдится raid)»
                              0

                              Zabbix может хранить какие угодно значения и делать очень продвинутые условия срабатывания, в случае с OOM killer — парсится dmegs на предмет сообщений об OOM, любые новые записи в моём случае поднимают триггер (и в сообщении приходят строки, которые увидел мониторинг на момент срабатывания триггера).
                              Другое дело, что OOM — очень плохой алерт, он говорит о проблеме с тысячей возможных причин, но это скорее тема для упомянутого #monitoringsucks.
                              Корреляция событий также возможна и в Zabbix, отличить "просел disk IO" от "просел disk IO из-за перестройки raid" можно, однако это никакая не магия — тебе нужно знать, чем одно событие отличается от другого, и соответствующим образом настроить триггеры. Насколько я понимаю, абсолютно везде делается так же, серебряной пули не существует — все системы требует вдумчивой настройки и продолжительной подгонки для нормальной работы.

                                0
                                > Другое дело, что OOM — очень плохой алерт, он говорит о проблеме с тысячей возможных причин, но это скорее тема для упомянутого #monitoringsucks.

                                Здесь соглашусь, если в случае OOM пришел один alert (и он про OOM) — надо допиливать мониторинг.
                                Я его привожу в качестве примера event-а который пуляется один раз и висит в консоли независимо от метрик/проверок.

                                > Корреляция событий также возможна и в Zabbix.
                                Насколько я помню, там довольно базовая корреляция в рамках одной ноды. Если можно делать связь гипервизор — вм, то это уже хорошо. У enterprise строится граф зависимостей между узлами в системе.
                              +1
                              Ну Ok, а что по поводу DevOps? Мне, например, кажется, что Zabbix API (других способов вроде нет) слишком сложен для постоянного изменения и деливери настроек мониторинга. Мне приходится выписывать вот такие кренделя каждый раз, когда мне что-то надо:

                                  for node_type in node_types_list:
                                      groups_list = zapi.hostgroup.get(
                                          {
                                              "output": "extend",
                                              "filter": {"name": [node_type]}
                                          })
                                      groupid = next(item for item in groups_list if item["name"] == node_type).get('groupid')
                              
                                      templates_list = zapi.template.get({"output": "extend"})
                                      templateid = next(item for item in templates_list if item["name"] == 'Template_Fides_{}'.format(node_type)).get('templateid')
                              
                                      try:
                                          zapi.action.create(
                                              {
                                                  "name": "Auto registration {}".format(node_type),
                              
                                                  # https://www.zabbix.com/documentation/3.2/manual/api/reference/event/object#event
                                                  "eventsource": 2,  # 2 - event created by active agent auto-registration
                              
                                                  "status": 0,
                                                  "esc_period": 120,
                                                  "def_shortdata": "Auto registration: {HOST.HOST}",
                                                  "def_longdata": "Host name: {HOST.HOST}\r\nHost IP: {HOST.IP}\r\nAgent port: {HOST.PORT}\r\n",
                              
                                                  "filter": {
                                                      "evaltype": 0,
                                                      "conditions": [
                                                          {
                                                              # https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
                                                              "conditiontype": 22,  # 22 - host name.
                              
                                                              "operator": 2,  # 2 - like
                                                              "value": node_type
                                                          }
                                                      ]
                                                  },
                                                  "operations": [
                                                      {
                                                          # https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
                                                          "operationtype": 0,  # 0 - send message
                              
                                                          "esc_period": 0,
                                                          "esc_step_from": 1,
                                                          "esc_step_to": 2,
                                                          "evaltype": 0,
                                                          "opmessage_grp": [
                                                              {
                                                                  "usrgrpid": "7"  # Group 7 is Zabbix Admins
                                                              }
                                                          ],
                                                          "opmessage": {
                                                              "default_msg": 1,
                                                              "mediatypeid": "1"
                                                          }
                                                      },
                                                      {
                                                          # https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
                                                          "operationtype": 2,  # 2 - add host
                                                          "evaltype": 0,
                                                      },
                                                      {
                                                          # https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
                                                          "operationtype": 4,  # 4 - add to host group
                              
                                                          "evaltype": 0,
                                                          "opgroup": [
                                                              {
                                                                  "operationid": 1,
                                                                  "groupid": groupid,
                                                              }
                                                          ]
                                                      },
                                                      {
                                                          # https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
                                                          "operationtype": 6,  # 6 - link to template
                                                          "optemplate": [
                                                              {
                                                                  "operationid": 0,
                                                                  "templateid": templateid,
                                                              },
                                                          ],
                                                      },
                                                  ]
                                              },
                                          )
                              
                                          tools.log('Action for {} has been imported to Zabbix.'.format(node_type))
                              
                                      except ZabbixAPIException as e:
                                          tools.error(e)
                              
                              


                              не перебор? нужно жить системой мониторинга, чтобы в ней быстро ориентироваться и что-то менять. В Nagios это проще, но там свои проблемы тоже есть.
                                +1
                                не смог отредактировать комментарий. Дополню: обратите внимание, что я подписываю каждое значение, чтобы не ковыряться в документации каждый раз. И это еще только импорт экшенов. А есть еще десятки других сущностей. Я все же считаю, что мониторинг должен служить человеку, а не человек мониторингу. Потому что читая местные комменты я вижу глубокий уровень понимания мониторинга. И именно это меня пугает. Люди явно намучались с этим вместо того, чтобы писать свои основные приложения.
                                  0
                                  С sensu/nagios очень просто добавлять мониторинг через систему управления конфигурациями, причем это делается в том же месте, где устанавливается нужный компонент: Пример для Postgres на puppet, примерно то же самое можно и через ansible/salt stack делать.

                                  С Zabbix сложнее, но вроде бы есть puppet-модуль, который умеет лезть в API Zabbix и добавлять нужные сущности.
                                    0
                                    Puppet тут не причем. Он мне даст возможность сделать это на тысячах Zabbix'ов. Но на каждом из тысячи я встречусь именно с этой же проблемой. Потому что проблема не дуплицировать изменения, а автоматизировать. Соответственно, всё равно, чтобы добавить какую-то сущность, я должен каждый раз лезть в документацию к Zabbix API и вспоминать какой код что значит и какие параметры он принимает в каждом конкретном случае.
                                      0
                                      > Puppet тут не причем. Он мне даст возможность сделать это на тысячах Zabbix'ов.

                                      Здесь вы не правы. Puppet даст возможность сконфигурировать один Zabbix-мастер на основании информации с тысячи агентов — для этого есть:

                                      1. В puppet — exported resources
                                      2. В salt stack — salt mine
                                      3. В ansible — delegation


                                      Вот документация по exported resources, один из предполагаемых use-кейсов — настроить сервер мониторинга.

                                      > Соответственно, всё равно, чтобы добавить какую-то сущность, я должен каждый раз лезть в документацию к Zabbix API

                                      Для этого есть модули puppet, которые абстрагируют вызовы API в понятные ресурсы.
                                        0
                                        С экспортированными ресурсами в puppet будет примерно такой flow (предположим, что модуль умеет такое делать):

                                        На сервере с агентом:
                                        @@zabbix_action { 'Auto registration ..'
                                         ...
                                        }
                                        


                                        На сервере Zabbix:
                                        Zabbix_action <<| |>>
                                        

                                          0
                                          Спасибо. Попробую.
                                            0

                                            На всякий случай напишу для будущих поколений: это всё костыли, данная система может ломаться, и, скорее всего, будет ломаться в странных местах — Zabbix очень плохо подготовлен к такому использованию, вдобавок ко всему при таком тяжёлом использовании API отдельно встаёт вопрос производительности.
                                            По поводу глубины знаний: я подозреваю, что многие участники дискуссии занимаются только и только мониторингом (и соответствующими частями ITIL), альтернатива этому не разработка основного приложения (это не в нашей зоне ответственности), а внедрение практик SRE.

                                              0
                                              > На всякий случай напишу для будущих поколений: это всё костыли, данная система может ломаться, и, скорее всего, будет ломаться в странных местах — Zabbix очень плохо подготовлен к такому использованию

                                              Я не вижу никакого смысла отказываться от управления чем-либо в обход puppet. Если action должны оказаться в zabbix — лучше пусть это будет заливаться централизованно, заббиксу ничего не станет от сотни вызовов API раз в час.

                                              > По поводу глубины знаний: я подозреваю, что многие участники дискуссии занимаются только и только мониторингом (и соответствующими частями ITIL)

                                              В современных командах человек, который занимается только мониторингом — слишком большая роскошь. Да и ни к чему хорошему это не приводит — для того, чтобы поставить приложение на мониторинг, нужно уметь его поднимать и укладывать руками.
                              0
                              Пользовался icinga2.
                              Удобно добавлять удалять сервера и сервисы.

                              Из минусов хочу отметить:
                              1. веб-интерфейс очень плохо оптимизирован и зачастую кладёт базу. Может быть уже и исправили.
                              2. активные коммиты — хорошо, но иногда приводят к сегфолтам, что несколько неприятно.

                              Only users with full accounts can post comments. Log in, please.