Sensu — фреймворк для мониторинга

  • Tutorial


Немного истории

В 2011 году в DevOps-среде возникло движение, объединившееся под хештегом #monitoringsucks, и критиковавшее существующие системы мониторинга за отсутствие гибкости. Что именно их не устраивало — прекрасно иллюстрирует эта презентация.
Если вкратце — хочется людям некоего стандарта API для взаимодействия между компонентами мониторинга, ну и появления самих этих компонент, чтоб из них строить гибкий и умный мониторинг.

Итогом этой волны недовольства стали массовые обсуждения проблем и привлечение внимания к интересным утилитам типа Sensu и Riemann.

В 2013 году хештег в сообществе сменился — теперь это #monitoringlove. Произошло это благодаря развитию opensource-утилит для мониторинга.

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

Именно о Sensu я и расскажу в этой статье, опишу базовые принципы работы и приведу пример решения типичной задачи мониторинга.

Основные факты о Sensu:

* Написан на Ruby, использует EventMachine (я бы предпочел Python, но ладно).
* Конфиги в JSON
* Может использовать плагины от Nagios.
* Работает через RabbitMQ, в PUSH-режиме, когда клиенты сами шлют серверу
результаты проверок по мере готовности.
* Есть пакеты DEB, RPM и даже MSI.
* Есть модули для puppet и cookbook для Chef.

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



Система состоит из трех основных компонентов: sensu-server, sensu-api, и на клиентах sensu-client. Также доступна sensu-dashboard. Установка тривиальна и подробно освещена в документации, для последней на данный момент версии 0.12 она доступна тут. Как я уже упоминал, есть deb, rpm и msi пакеты.

Базовые понятия


Для того, чтобы понять, как все это работает, надо разобраться в терминологии. Я не ставлю целью перевод официальной документации, а хочу дать базовые понятия, чтоб было понятно, о чем будет в дальнейшем идти речь.

У нас есть следующие сущности:

Клиент (Client)

Это некий сервер с установленным и настроенным sensu-client, который публикует информацию о себе в RabbitMQ и таким образом регистрируется в системе мониторинга Sensu. От сервера Sensu он получает набор проверок, и выполняет их, складывая результат в RabbitMQ.

Для самоидентификации ему нужна конфигурация, которая выглядит примерно так (взято из документации):

{
  "client": {
    "name": "i-424242",
    "address": "127.0.0.1",
    "subscriptions": [
      "production",
      "webserver",
      "mysql"
    ]
  }
}


Все довольно очевидно, за исключением «подписок» (subscriptions). Подписки представляют собой список ролей, ассоциированных с этим сервером, и определяют список выполняющихся на нем проверок. Более тонкая настройка описана в официально документации, из полезного можно добавить любые поля, значения из которых можно будет использовать в проверках, а также интервал времени, который должен пройти для генерации события об уходе клиента в оффлайн.

Проверка (Check)

Проверки определяют команды, которые будут запускаться на клиентах, и их параметры. Полностью совместимы с плагинами Nagios, т.е. используют exit code как критерий успешности проверки, а STDOUT или STDERR как источник данных. Проверки настраиваются в конфигурации sensu-server, типичная проверка выглядит так (пример из документации):

{
  "checks": {
    "chef_client": {
      "command": "check-chef-client.rb",
      "subscribers": [
        "production"
      ],
      "interval": 60
      "handlers": [
        "pagerduty",
        "irc"
      ]
    }
  }
}


Из интересного тут опять-таки подписки и хендлеры. Подписки определяют, на каких клиентах будет эта команда запущена.

А набор хендлеров определяют список команд, которые будут выполнены при обработке данных от этой проверки. О них мы дальше поговорим.

Стоит отметить, что проверка может быть «метрикой» (metric), т.е. данные из ее STDOUT будут всегда просто передаваться в хендлеры. Таким образом можно слать данные метрик куда-нибудь для хранения или рисования графиков (например, в Graphite). Подробности в документации.

Хендлеры (Handlers)

Хендлеры определяют команды, которые будут запускаться на сервере мониторинга при поступлении данных от проверок, и их параметры. Например, этот хендлер при получении от какой-либо проверки не-нулевого exit code выполнит команду mail -s 'sensu event' email@address.com (пример из документации):

{
  "handlers": {
    "mail": {
      "type": "pipe",
      "command": "mail -s 'sensu event' email@address.com"
    }
  }
}


Тут все очевидно, хендлеров в репозитории плагинов куча. Можно слать в Pagerduty, и письма отправлять, и в Graylog2 слать в gelf. Подробности в документации.

Всего вышеперечисленного уже достаточно, чтобы соорудить работающую систему. Есть еще мутаторы, расширения и API, но это нам сейчас не важно.

Приступаем к самому интересному


Sensu позиционируется именно как «фреймворк для мониторинга», и это значит, что «из коробки» в нем ничего привычного по энтерпрайз-системам типа Zabbix нет. Вся функциональность добавляется благодаря плагинам.

Попробуем сделать что-нибудь полезное. Возьмем простую задачу — выполнять проверки относительно Redis на клиентах, в случае проблем выводить алерт на панель Dashing, а также для истории слать сообщение в Graylog2 и email на адрес admin@example.com. А еще снимать метрики с Redis и отправлять на хранение в Graphite, а потом по агрегированным значениям keys тоже выполнять проверки.

Клиенты имеют адреса 192.168.1.2N, Graphite развернут на 192.168.1.80:8082, RabbitMQ и Redis тоже на 192.168.1.80. Graylog2 слушает на 192.168.1.81, там же развернута Dashing.

Конфигурация


Начнем с конфигурации клиентов.

Допустим, у нас есть N серверов в роли redis.

Конфигурация клиента выглядит так:

/etc/sensu/config.json
{
  "client": {
    "graphite_server": "192.168.1.80:8082",
    "address": "192.168.1.2N",
    "name": "clientN",
    "subscriptions": [
      "redis"
    ]
  }
  "rabbitmq": {
    "vhost": "/sensu",
    "host": "192.168.1.80",
    "password": "password",
    "port": 5672,
    "user": "sensu"
  }
}


и размещается на каждом из N клиентов.

Все остальные файлы конфигураций только на сервере Sensu.

Основные настройки:

/etc/sensu/conf.d/settings.json

{
  "api": {
    "host": "192.168.1.80",
    "port": 4567
  },
  "redis": {
    "host": "192.168.1.80",
    "port": 6379
  },
  "rabbitmq": {
    "vhost": "/sensu",
    "host": "192.168.1.80",
    "password": "password",
    "port": 5672,
    "user": "sensu"
  },
  "mailer": {
    "mail_from": "sensu@example.com",
    "smtp_port": "25",
    "mail_to": "admin@example.com",
    "smtp_address": "localhost"
  },
  "dashing": {
    "auth_token": "YOUR_AUTH_TOKEN",
    "host": "http://192.168.1.81:8088"
  },
  "gelf": {
    "server": "192.168.1.81"
    "port": "12201",
  }
}


Как вы видите, мы настроили не только сам Sensu, но и параметры для хендлеров dashing, gelf и mailer.

Теперь определим сами эти хендлеры:

/etc/sensu/conf.d/handlers.json
{
  "handlers": {
    "default": {
      "type": "set",
      "handlers": [
        "mailer",
        "dashing",
        "gelf"
      ]
    },
    "gelf": {
      "type": "pipe",
      "command": "/etc/sensu/handlers/gelf.rb"
    },
    "mailer": {
      "type": "pipe",
      "command": "/etc/sensu/handlers/mailer.rb"
    },
    "dashing": {
      "type": "pipe",
      "command": "/etc/sensu/handlers/dashing.rb"
    },
    "graphite": {
      "mutator": "only_check_output",
      "type": "amqp",
      "exchange": {
        "durable": true,
        "type": "topic",
        "name": "metrics"
      }
    }
  }
}


Тут все просто. Заметьте, что в Graphite мы данные шлем через AMQP. Хендлеры надо разложить на сервере мониторинга в /etc/sensu/handlers.

Теперь настроим проверки, которые будут выполняться на клиентах:

/etc/sensu/conf.d/checks.json
{
  "checks": {
    "redis_processes": {
      "interval": 60,
      "command": "/etc/sensu/plugins/processes/check-procs.rb -p redis -c 8 -C 0 -w 7 -W 1",
      "subscribers": [
        "redis",
      ],
      "handlers": [
        "default"
      ]
    },
    "redis_memory": {
      "dependencies": [
        "redis_processes"
      ],
      "command": "/etc/sensu/plugins/redis/check-redis-memory.rb -c 204800 -w 51200",
      "interval": 60,
      "subscribers": [
        "redis",
      ],
      "handlers": [
        "default"
      ]
    },
    "redis_metric": {
      "handlers": [
        "graphite"
      ],
      "interval": 60,
      "dependencies": [
        "redis_processes"
      ],
      "command": "/etc/sensu/plugins/redis/redis-graphite.rb --scheme stats.:::name:::.redis",
      "subscribers": [
        "redis",
      ],
      "type": "metric"
    },
    "redis_keys_from_graphite": {
      "interval": 60,
      "command": "/etc/sensu/plugins/graphite/check-data.rb -s :::graphite_server::: -t stats.:::name:::.redis.db0.keys -w 500 -c 900 -a 120",
      "subscribers": [
        "redis"
      ],
      "dependencies": [
        "redis_processes"
      ],
      "handlers": [
        "default"
      ]
    }
  }
}


Проверки осуществляются плагинами Sensu, которые надо разложить на клиентах в /etc/sensu/plugins. Для знакомых с Nagios тут ничего нового, интересна только метрика redis_metric, из которой мы в Graphite данные кладем, а потом в проверке redis_keys_from_graphite достаем и проверяем данные за последние 10 минут. Вообще, почти каждый плагин имеет ключ --help, который выдает вполне вменяемую справку по использованию.

Вот и вся конфигурация. Все наглядно, все можно хранить в репозитории, и это прекрасно.

Конечно, надо настроить еще Dashing и Graphite, но это я оставлю за рамками статьи. Инструкция по настройке Sensu + Graphite можно найти тут, а с Dashing все и так понятно.

А еще у Sensu есть простенький dashboard, на котором можно увидеть список клиентов, проверок, и сработавших алертов. Через API и с помощью dashboard можно выключать генерацию алертов для любых хостов или проверок, а также видеть общее состояние системы.
Выглядит он как-то так (скрин не мой):


Выводы


Как мы видим, Sensu берет на себя только роль маршрутизатора и организатора, а вся грязная работа делается внешними программами. Это позволяет сохранять небольшой размер исходного кода, и общую простоту системы. Регистрация клиентов через RabbitMQ позволяет избавиться от механизма «обнаружения» клиентов, что особенно удобно для облаков. Масштабируется все очень просто, пример HA + load balancing можно увидеть тут.

Я использую Sensu в продакшне, параллельно с Zabbix, уже около месяца, ну и в тестовом варианте пару месяцев использовал. Гибкость Sensu позволила настроить мониторинг ключевых параметров и метрик проекта с выводом на панель Dashing, в то время как Zabbix я использую уже очень давно, и занимается он сейчас более комплексным мониторингом. В общем, для многих проектов, особенно в облаках, Sensu будет прекрасным выбором, поскольку дает возможность гибко маршрутизировать события, а также хорошо приспособлен к динамической натуре облаков. В презентациях я встречал цифры в тысячи серверов под наблюдением Sensu, так что с производительностью проблем нет.

В заключение хочу указать на минусы и плюсы Sensu (все IMHO):

Минусы Sensu


  • Имеющиеся хендлеры уведомлений куцые по настройкам. Это сейчас главный минус, если вы не пользуетесь сервисами типа PagerDuty. Единственное решение — писать свой хитрый хендлер.
  • Конфиг в json, а не в yaml.
  • Нужен внешний хранитель метрик, он же рисователь графиков.
  • Не слишком полная документация. К счастью, проект простой, можно разобраться, просто читая код.


Плюсы Sensu


  • Конфиг можно хранить в git, раскладывать все с помощью Chef/Puppet.
  • Масштабируемость.
  • Отказоустойчивость.
  • Гибкость выбора системы хранения данных.
  • Поддержка плагинов Nagios.
  • Авто-подключение клиентов.
  • Механизм подписок.
  • Данные публикуются клиентами по мере генерации.
  • Результаты проверок можно гибко направлять в разные хендлеры.
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 26
  • 0
    а как с snmp? Через внешние плагины? Непонятно, как делать проверки по расписанию, например.
    • +1
      Snmp тоже через внешние плагины. Проверки по расписанию — можно выставить большой интервал проверок, можно запускать в ручном режиме через API, можно выставить периоды, в которые не будет алерт создаваться через subdue. В документации описаны все возможности.
      • 0
        управление очередью есть? Вот есть у меня за тысячу свитчей на сети, хочу снимать с них данные. Если начну (всего лишь) пинговать все полторы тысячи раз в секунду — то всё обвалится, а если распределить более-менее равномерно (не более 50 проверок одновременно, например), то будет работать нормально.

        в мануале не нашёл.

        нагиос сейчас со всей этой радостью справляется отлично, лоадавг по нулям.
        • 0
          Надо смотреть исходники. По логике, клиент должен проверки раз в N секунд запускать, где N для каждой проверки свое. А уж как он распределяет их по этому интервалу — вопрос. Вообще Sensu создан для мониторинга серверов с агентами и проверками на них, а не для проверки сетевых устройств по SNMP.
          • 0
            ну представьте себе 1000 серверов, делов-то. Не вижу разницы, если их проверки точно так же не будут рейтлимититься.
            • +1
              С 1000 серверов никаких проблем. Каждый из них запустит свои (локальные) проверки, и опубликует их результаты в очереди RabbitMQ, а потом из этой очереди N серверов Sensu будут их забирать.
          • 0
            Дык RabbitMQ. Там и рулите. Это как раз сервер сообщений.
        • 0
          Вот вроде, официальный плагин:

          https://github.com/sensu-plugins/sensu-plugins-snmp
        • –1
          Среди плюсов не вижу ничего, чего нет в том же zabbix-е. Сообщество ruby-программистов уткнулось в проблему фундаментального недостатка?
          • 0
            Серьезно?
            а когда заббикс научился использовать скрипты проверок от нагиоса и хранить конфиг в git вместо базы?
            • +1
              А оно надо это забиксу? Они идут своим путем.
              • 0
                Посредством сторонних костылей, вроде бы, да, научился — dev.aperto.fr/projects/3/wiki/Nagios_plugin_wrapper
                Я не проверял — мне проще написать параметр в конфиг, чем прыгать с чужими проверялками.
                Кто мешает хранить кусок mysqldump-а в git, если так уж хочется?
                • 0
                  это просто те плюсы, которые кому-то будут очень важны, я бы не стал так говорить, что заббикс однозначно лучше. Но все же дело тут не в фундаментальном недостатке, а в другом подходе к вопросу управления мониторингом.
                • 0
                  Эм, вообще говоря это проблемы не составляет.
                • 0
                  Я специально в начале статьи сделал экскурс в истрию, чтобы показать, что появление Sensu — ответ сообщества на проблемы и недостатки имеющихся утилит. Даже ссылку на презентацию привёл.
                  • –1
                    Вот, что характерно, презентация совершенно ни о чем и скорее свидетельствует об уровне бардака в голове у докладывающего. На 95% — совершенно общие слова о том, как человек замучен Nagios'ом и о неких недостатках архитектуры Nagios'а (и всяких внешних штуковин, к нему подключающихся).

                    Из того, что я вижу — радикально нового ничего по сути не предложено и ни одна из действительно актуальных проблем мониторинга современности не затронута. Использование «более generic» протоколов типа того же AMQP и написанных на коленке плагинов вместо специализированных эффективных протоколов и агентов — скорее огромный шаг назад, повышающий на порядок-два требования к железу. Очереди и модульность системы вообще не является чем-то сверхновым, подавляющее большинство систем мониторинга построены по таким принципам.

                    На вопросы типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Sensu будет что-то типа «поставьте сбоку еще пару сотен серверов под роутинг мониторинга и попытайтесь придумать сами что-нибудь для Graphite для хранения такого потока данных». Вопросы типа application domain метрик не рассматривались вообще — видимо, за ненадобностью.
                    • +1
                      Вы сравниваете теплое с мягким, пытаясь сравнить Sensu с энтерпрайз-мониторингом. Задача Sensu — дать возможность максимально гибко направлять результаты проверок в различные обработчики. Это именно то, чего не хватает тому же Zabbix-у. Если нужен в качестве бекенда именно Graphite с его продвинутыми возможностями анализа данных — как вы завернете данные из Zabbix-а туда? Если нужно построить простой и наглядный Dashboard и слать данные туда, как вы это сделаете из Zabbix? Только через API, а это не самый простой способ. А если нужна история проверок не в убогом виде Zabbix, а в искабельном виде, в том же Logstash или Graylog2? Zabbix вроде бы все умеет, но не так хорошо, как специализированные инструменты.

                      Да и вообще — Zabbix развивается с 1998 года, Nagios с 1999, а Sensu с 2011, и сейчас в версии 0.12. У него хватает надостатков, но при этом он решает многие задачи, которые энтерпрайз-системы могут решить только с помощью каких-то костылей. Ну и на ваш вопрос типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Zabbix будет примерно на том же уровне — «поставьте сбоку 100 zabbix-прокси, каждый с максимально прокачанной СУБД для хранения потока данных». Про Nagios говорить не буду, я в нем не эксперт, а тем же Zabbix-ом пользуюсь уже не первый год, и ясно вижу его недостатки. Для каждой задачи нужен свой инструмент, и Sensu появился именно потому, что многие задачи с помощью Nagios/Zabbix решаются слишком неудобно для решающего.
                      • –1
                        Я ровно к тому, что задача на самом деле надуманная. Ну, не вижу я в реальном мире такой сверхсамозадачи — роутить трафик метрик. Если мне нужно что-то проанализировать сложное по метрикам — то я в жизнь не подумаю брать Graphite для post-mortem аналитики, а обойдусь каким-то специализированным решением (отгружу, что нужно из базы в сторонку и как-то обработаю). Если говорить о дашбордах в Zabbix — встроенные dashboard'ы Zabbix'а покрывали пока 100% встреченных мною задач, и, опять же, я скорее пойду по пути наименьшего сопротивления и допишу соответствующую функциональность в Zabbix, нежели буду городить какой-то отдельный dashboard. Гонять весь объем логов через систему мониторинга — с моей точки зрения — вообще варварство и дикость. Если нужно трекать логи — они и будут трекаться (и индексироваться — хотя, опять же, как показывает практика — индексирование — скорее порочная практика) отдельно, а в Zabbix/Nagios/whatever будут отсылаться только коротенькие результаты проверки.

                        На вопрос про 10K серверов ответ у Zabbix будет на уровне «30-40 zabbix proxy», у хорошо настроенного Nagios — штук 5-7. Боюсь, что у Sensu количество серверов, только разгребающих очередь, будет на порядок-полтора-два больше, не считая того, что такая инфраструктура плагинов будет страшно жрать ресурсы на каждом проверяемом сервере и не считая всего того, что будет стоять за серверами, разгребающими очередь.

                        Собственно, я даже заочно могу сразу сказать, что идея «разгребать MQ-очередь метрик по одной» при достижении определенных нагрузок — дурацкая и порочная сама по себе, даже вне зависимости от эффективности реализации MQ и клиентов. Спасение — только буферизация, только отказ от real-time-с-точностью-до-события, от timing consistency, выставление четких параметров рабочего sliding window и следование им…
                        • +2
                          Вот смотрите — вы не видите такой задачи. А люди увидели, и решили таким образом. Дашборд у Zabbix-а ужасный, хоть и весьма функциональный. Все зависит от задач. Для вас Zabbix покрывает 100% встреченных задач. Я до недавнего времени тоже думал, что это все блажь хипстерская, а потом выяснилось, что вместо насилия над Zabbix и построения костылей, для одной из задач мониторинга проще использовать Sensu. Я вас переубедить не пытаюсь, просто показываю, что спектр задач у всех сильно разный, а для каждой задачи лучше использовать подходящий инструмент.
                          • 0
                            Ну так и поделитесь — если не секрет — что же за задачу вы лично решали с помощью Sensu? Думаю, с живым примером было бы куда интереснее читать о сравнительно новой системе.
                            • +3
                              Задача примерно такая: мониторинг доступности самих серверов, а также неких внешних веб-сервисов с конкретных серверов, с записью всех неуспешных попыток в историю (Graylog2), и выводом всех проблем (вместе с адекватным описанием) на Dashboard для саппорта, который кроме этого показывает внутренние метрики проекта и внутренние же очереди для обрабоки саппортом. Т.е. веб-мониторинг самого Zabbix никак не подходил — запросы требовалось слать именно с конечных серверов. Как и дашборд Zabbix-а не подходил для этой задачи вывода информации никак.

                              Я прекрасно понимаю, что все это можно сделать и через Zabbix через запуск скрипта для проверки веб-сервисов через UserParameters, и выдергивание через API данных для Dashboard, и даже можно было пережить неудобную историю в самом Zabbix-е. Но лично мне проще было вынести эту специфичную задачу в Sensu, и производить развертывание и настройку всего этого через Ansible, и, соответственно, хранить все в git вместе с другими playbook-ами для развертывания проекта с нуля. Теперь все логично — dashboard и внутренние проверки/метрики развертываются вместе со всем проектом, а общий мониторинг площадки все также выполняется Zabbix-ом.
                              • 0
                                Спасибо — это уже совсем другой разговор! Может быть стоит вынести этот пример в начало статьи? То есть вы по сути делаете не систему мониторинга, а развернутый комплекс для мониторинга внешних систем?
                                • 0
                                  Да нет, именно система мониторинга, как внешних, так и внутренних сервисов. Просто сильно кастомизированная под конкретный веб-проект. И именно в таких условиях sensu с возможностью роутить алерты очень удобен.
                • 0
                  Меня в мониторинге использование очередей одновременно и радует и пугает: радует в том смысле, что становится легко масштабировать, а пугает в том смысле, что это еще одна точка отказа в сервисе, который в общем-то и должен заниматься слежением за точками отказа.
                  • 0
                    Чтобы еще больше испугаться, можно вспомнить о том, что внутри того же Заббикса реализованы свои аналоги очередей, и вообще внутренней логики наворочено ну очень много. А тут сам сервер весьма прост — тысяча строк кода, а очередями занимается специализированный сервер.
                  • 0
                    А Sensu может использовать nagios сhecks? Или все равно нужно все нагиос конфиги переписать в JSON формат?

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.