Pull to refresh

Comments 41

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

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

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

У 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 секунд.
Угу, вот и приходится собирать мониторинг из 5 разных продуктов.

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


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

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

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

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

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

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

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

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

Из плюсов — не обязательно, чтобы на машине стоял агент sensu, достаточно отправлять метрики; можно делать довольно сложные запросы к метрикам (influxdb умеет по абсолютным значениям высчитывать изменение и количество операций в секунду); плюс метрики не собираются два раза.
Из минусов — для полноценного мониторинга надо два агента на сервере — telegraf и sensu, плюс rsyslog.
UFO just landed and posted this here
Nagios-подобные системы очень хорошо интегрируются с системами управления конфигурациями. Софт ставится на мониторинг в том же месте, в котором он устанавливается.
Как каждый из этих сервисов выглядит в контексте #monitoringsucks, упомянутого в этой статье?

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

Что у 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)»

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

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

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

> Корреляция событий также возможна и в Zabbix.
Насколько я помню, там довольно базовая корреляция в рамках одной ноды. Если можно делать связь гипервизор — вм, то это уже хорошо. У enterprise строится граф зависимостей между узлами в системе.
Ну 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 это проще, но там свои проблемы тоже есть.
не смог отредактировать комментарий. Дополню: обратите внимание, что я подписываю каждое значение, чтобы не ковыряться в документации каждый раз. И это еще только импорт экшенов. А есть еще десятки других сущностей. Я все же считаю, что мониторинг должен служить человеку, а не человек мониторингу. Потому что читая местные комменты я вижу глубокий уровень понимания мониторинга. И именно это меня пугает. Люди явно намучались с этим вместо того, чтобы писать свои основные приложения.
С sensu/nagios очень просто добавлять мониторинг через систему управления конфигурациями, причем это делается в том же месте, где устанавливается нужный компонент: Пример для Postgres на puppet, примерно то же самое можно и через ansible/salt stack делать.

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

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

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


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

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

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

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


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

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

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

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

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

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

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

Articles