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

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

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

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

В 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 она доступна тут ^[4]. Как я уже упоминал, есть deb, rpm и msi пакеты.

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

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

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

Клиент (Client)

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

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

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

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

Проверка (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). Подробности в документации ^[6].

Хендлеры (Handlers)

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

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

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

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

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

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

Попробуем сделать что-нибудь полезное. Возьмем простую задачу — выполнять проверки относительно Redis на клиентах, в случае проблем выводить алерт на панель Dashing ^[9], а также для истории слать сообщение в 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 можно найти тут ^[10], а с Dashing все и так понятно.

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

Выводы

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

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

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

Минусы Sensu

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

Плюсы Sensu

• Конфиг можно хранить в git, раскладывать все с помощью Chef/Puppet.
• Масштабируемость.
• Отказоустойчивость.
• Гибкость выбора системы хранения данных.
• Поддержка плагинов Nagios.
• Авто-подключение клиентов.
• Механизм подписок.
• Данные публикуются клиентами по мере генерации.
• Результаты проверок можно гибко направлять в разные хендлеры.

Автор: LazyWolf

Источник ^[12]