Sensu. Modern Monitoring

Моніторинг - це важлива складова будь-якої серверної архітектури. Найбільш популярні варіанти його організації - це Nagios та Zabbix. Проте вони мають багато недоліків. Основні з них - це необхідність описувати кожен сервер, що потребує спостереження, окремо на сервері моніторингу; необхідність розміщення клієнта та сервера в прямій доступності та брак гнучкості. Процес автоматичного додавання хостів в моніторинги, на зразок Nagios, не дуже легко автоматизується, адже про це в 1999 році, підозрюю, особливо не думали. І це вже не кажучи про проблеми маштабування, убогість програмних інтерфейсів і т.п.

Поставивши собі за мету вирішення згаданих вище проблем, з'явився проект Sensu. Він має дві версії: Sensu Core (free, opensource) та Sensu Enterprise. Архітектура роботи Sensu досить цікава і змушує повірити в світле майбутнє. Основні особливості:

• Написаний на Ruby. Схоже люди поділяються на тих, хто любить Ruby, за його гнучкість синтаксису і ненавидить Python за його більшу строгість, і навпаки. Я відношусь до другого табору. :) Тому в кожного емоції щодо цього різні.
• Конфігураційні файли - JSON. Шкода, що не YAML.
• Може працювати з перевірками від Nagios. Що чудово - не треба все знову переписувати.
• Перевірка описується лише одноразово на сервері і підключається до аналогічної групи серверів. Кожен новий хост додається в моніторинг значно простіше і з мінімумом ручної роботи.
• Чудова архітектура, яка добре масштабується.

Зупинюсь детальніше на схемі роботи Sensu.

Sensu-server процес у якості сервера черг використовує RabbitMQ, а у якості місця збереження результатів відпрацювань чеків - Redis. Процес sensu-server має бути відповідно сконфігурований на їх використання. Одразу після старту процесу sensu-client на вузлі, що буде моніторитись, опитує sensu-server на предмет призначених для нього перевірок і надалі відсилає результати перевірок напряму в сервер черг RabbitMQ. Sensu-server підключається до останнього, робить обробку черги і записує дані в Redis. За певних обставин sensu-server може викликати відповідний handler. Handler - це деяка логіка сповіщення у разі певних проблем чи пересилки даних на окремі бекенди у разі їх появи і т.п. Sensu-api - процес, котрий надає інтерфейс взаємодії з іншими сторонніми скриптами чи сервісами. Якраз Uchiwa (frontend на схемі) і користується API задля відображення всього, що відбувається з моніторингом.
Sensu-client теоретично може знаходитись за NAT, адже серверу не потрібна пряма його видимість.

Тобто виходить що компоненти Sensu (і навіть саму Sensu) можна зручно масштабувати: RabbitMQ, як і Redis, чудово машстабуються горизонтально, з підвищенням рівня доступності і т.п.

Надалі я буду використовувати такі адреси для серверів:

sensu_client_1    10.0.3.67    
sensu_server      10.0.3.16

Спочатку налаштуємо сервери, у якості операційної системи для яких я обрав Ubuntu. Оновимо всі доступні пакети:

# apt-get update 
# apt-get -y upgrade

Установимо wget на кожному із серверів:

# apt install wget

Він нам знадобиться для скачування ключів до репозиторіїв.

Установимо RabbitMQ, для чого скористуємось офіційними репозиторіями з останньою версією сервера:

# echo 'deb http://www.rabbitmq.com/debian/ testing main' | tee /etc/apt/sources.list.d/rabbitmq.list

# wget -O- https://www.rabbitmq.com/rabbitmq-release-signing-key.asc | apt-key add -

# apt-get update
# apt-get install rabbitmq-server

Деталі можна знайти за посиланням https://www.rabbitmq.com/install-debian.html

Офіційна документація радить підняти ліміт можливих відкритих файлів процесу до 65536:

# vim /etc/default/rabbitmq-server
...
ulimit -n 65536
...

Перевірити діючі значення можна виконавши наступну команду:

# rabbitmqctl status

Sensu використовує SSL для комунікації між компонентами, тому згенеруємо ключ та сертифікат, скориставшись їхніми скриптами:

# cd /tmp && wget http://sensuapp.org/docs/0.23/tools/ssl_certs.tar && tar -xvf ssl_certs.tar
# cd ssl_certs && ./ssl_certs.sh generate

Та скопіюємо їх для початку лише в директорію RabbitMQ:

# mkdir -p /etc/rabbitmq/ssl
# cp /tmp/ssl_certs/sensu_ca/cacert.pem /tmp/ssl_certs/server/cert.pem /tmp/ssl_certs/server/key.pem /etc/rabbitmq/ssl

І відповідно відредагуємо конфігураційний файл RabbitMQ, щоб сервер використовував шифроване з'єднання:

# vim /etc/rabbitmq/rabbitmq.config
[
    {rabbit, [
    {ssl_listeners, [5671]},
    {ssl_options, [{cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
                   {certfile,"/etc/rabbitmq/ssl/cert.pem"},
                   {keyfile,"/etc/rabbitmq/ssl/key.pem"},
                   {verify,verify_peer},
                   {fail_if_no_peer_cert,true}]}
  ]}
].

Перевантажуємо RabbitMQ:

# service rabbitmq-server restart

Створюємо окремий Vhost RabbitMQ для Sensu:

# rabbitmqctl add_vhost /sensu
Creating vhost "/sensu" ...

Створюємо користувача, що буде використовувати створений вище Vhost:

# rabbitmqctl add_user sensu p@ssword
Creating user "sensu" ...

Та виставляємо для нього всі необхідні дозволи:

# rabbitmqctl set_permissions -p /sensu sensu ".*" ".*" ".*"
Setting permissions for user "sensu" in vhost "/sensu" ...

Проінсталюємо останню доступну версію Redis (на момент написання статті - це 3.2.0), для чого використаємо репозиторій Dotdeb:

# printf 'deb http://packages.dotdeb.org jessie all\ndeb-src http://packages.dotdeb.org jessie all' |
        tee /etc/apt/sources.list.d/redis-server.list

# wget -q -O - http://www.dotdeb.org/dotdeb.gpg | sudo apt-key add -

Запустимо процес установки Redis:

# apt update
# apt-get install redis-server

Як і у випадку з RabbitMQ, необхідно підняти деякі ліміти, встановлені по-замовчуванню:

# vim /etc/default/redis-server
#
ULIMIT=65536

Перезавантажимо Redis та перевіримо його роботу:

# redis-cli ping
PONG

Так як основні компоненти для роботи моніторингу встановлені, можна перейти і до установки самої Sensu.
Додамо новий репозиторій та ключ для його роботи:

# wget -q http://repositories.sensuapp.org/apt/pubkey.gpg -O- | sudo apt-key add -
# echo "deb http://repositories.sensuapp.org/apt sensu main" | sudo tee /etc/apt/sources.list.d/sensu.list

У цьому ж репозиторії знаходиться і панель Uchiwa. Дивно, проте по-замовчуванню в репозиторії запропоновано версію 0.14.0, але в ньому ж є більш нова - 0.14.5, котра не відмічена як остання актуальна. Тому вдамося до установки з указанням конкретної версії:

# aptitude install uchiwa=0.14.5-1

Більш того, основний сайт пропонує версію 0.15.0, що в репозиторіях розміщується в категорії unstable http://repositories.sensuapp.org/apt/pool/sensu/unstable/u/uchiwa/
Надіюсь, що такі недорозуміння тимчасові.

Чи потрібна вам саме остання версія панелі можна вирішити, ознайомившись з ченджлогами https://github.com/sensu/uchiwa/blob/master/CHANGELOG.md

Скопіюємо попередньо згенеровані сертифікати також і для Sensu:

# mkdir -p /etc/sensu/ssl && sudo cp /tmp/ssl_certs/client/cert.pem /tmp/ssl_certs/client/key.pem /etc/sensu/ssl

Усі компоненти установлено, переходимо до конфігурації.
Конфігураційні файли  будемо зберігати в /etc/sensu/conf.d, це досить зручно для систем управління конфігураціями на зразок Puppet чи Ansible.

Вкажемо параметри підключення до RabbitMQ:

# vim /etc/sensu/conf.d/rabbitmq.json

{
  "rabbitmq": {
    "ssl": {
      "cert_chain_file": "/etc/sensu/ssl/cert.pem",
      "private_key_file": "/etc/sensu/ssl/key.pem"
    },
    "host": "localhost",
    "port": 5671,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "p@ssword"
  }
}

Vhost, користувача та його пароль ми створювали вище. Вкажемо параметри доступу до сховища Redis:

# vim /etc/sensu/conf.d/redis.json
{
  "redis": {
    "host": "localhost",
    "port": 6379
  }
}

Налаштуємо сервіс, що відповідає за API Sensu:

# vim /etc/sensu/conf.d/api.json
{
  "api": {
    "host": "localhost",
    "port": 4567
  }
}

Нагадаю, що цей сервіс використовує в т.ч. Uchiwa для відображення метрик.
Останння також потребує певного налаштування:

# vim /etc/sensu/uchiwa.json
{
    "sensu": [
        {
            "name": "Sensu",
            "host": "localhost",
            "ssl": false,
            "port": 4567,
            "path": "",
            "timeout": 5000
        }
    ],
    "uchiwa": {
        "port": 3000,
        "stats": 10,
        "refresh": 10,
        "user": "admin",
        "pass": "secret",
    }
}

Можна прибрати поля логіна/пароля - і доступ буде відкритий для всіх. Є можливість створення декількох користувачів (в т.ч. тільки для читання), налаштування SSL, без необхідності встановлення веб-сервера і т.п.

Uchiwa також підтримує відображення метрик з декількох Sensu-серверів (точніше, Sensu API серверів). У такому випадку конфіг uchiwa.json буде виглядати десь так:

{
  "sensu": [
    {
      "name": "Site 1",
      "host": "api1.example.com",
      "port": 4567,
      "timeout": 10
    },
    {
      "name": "Site 2",
      "host": "api2.example.com",
      "port": 4567,
      "ssl": false,
      "path": "",
      "user": "",
      "pass": "",
      "timeout": 10
    }
  ],
  "uchiwa": {
    "host": "0.0.0.0",
    "port": 3000,
    "refresh": 10
  }
}

Sensu-сервер буде моніторити також і сама себе, що реалізується за допомогою клієнта, котрого необхідно налаштувати на ньому ж:

# vim /etc/sensu/conf.d/client.json

{
  "client": {
    "name": "sensu_server",
    "address": "localhost",
    "subscriptions": [ "ALL" ]
  }
}

Ім'я сервера не може містити пробілів чи чогось такого.

Активуємо автозавантаження компонентів

# update-rc.d sensu-server defaults
# update-rc.d sensu-client defaults
# update-rc.d sensu-api defaults
# update-rc.d uchiwa defaults

Стартуємо/рестартуємо всі процеси:

$ sudo service sensu-server restart
$ sudo service sensu-client restart
$ sudo service sensu-api restart
$ sudo service uchiwa restart

Якщо всі пройшло правильно, панель Uchiwa стане доступною за адресою http://10.0.3.16:3000.

По-замовчуванню активована світла тема, проте немає ніяких складностей змінити її на темний варіант в налаштуваннях.

Проінсталюємо Sensu клієнт на сервер. котрий будемо моніторити:

# apt-get update
# apt-get -y install sensu

Скопіюємо сертифікат/ключ з сервера на клієнт, котрий генерували на самому початку:

root@sensu_server:~# scp /tmp/ssl_certs/client/cert.pem /tmp/ssl_certs/client/key.pem ubuntu@10.0.3.67:/tmp

Перемістимо їх в директорію з конфігами Sensu:

# mkdir -p /etc/sensu/ssl 
# cp /tmp/cert.pem /tmp/key.pem /etc/sensu/ssl

Конфігуруємо клієнт:

# vim /etc/sensu/conf.d/rabbitmq.json

{
  "client": {
    "name": "sensu_client_1",
    "address": "10.0.3.67",
    "subscriptions": [ "ALL" ]
  }
}

Клієнт буде надсилати метрики одразу в чергу RabbitMQ, що працює на Sensu-сервері:

# vim /etc/sensu/conf.d/rabbitmq.json

{
  "rabbitmq": {
    "ssl": {
      "cert_chain_file": "/etc/sensu/ssl/cert.pem",
      "private_key_file": "/etc/sensu/ssl/key.pem"
    },
    "host": "10.0.3.16",
    "port": 5671,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "p@ssword"
  }
}

Додамо клієнт в автозавантаження та запустимо (перезапустимо) його:

# update-rc.d sensu-client defaults
# service sensu-client start

І ось, доданий до моніторингу, сервер з'явився:

Щоб внести певне різноманіття створимо декілька додаткових перевірок. Будемо слідкувати за роботою сервера Apache, для чого проінсталюємо його як на клієнті, так і на сервері:

# apt install -y apache2

Створимо нову перевірку роботи щойновстановленого сервера:

# vim /etc/sensu/plugins/check-apache.rb

#!/usr/bin/env ruby

procs = `ps aux`
running = false
procs.each_line do |proc|
  running = true if proc.include?('apache2')
end
if running
  puts 'OK - Apache daemon is running'
  exit 0
else
  puts 'WARNING - Apache daemon is NOT running'
  exit 1
end

# chmod 755 /etc/sensu/plugins/check-apache.rb

Перевірка виглядає на диво нескладно, чи не так?
Ця перевірка має фізично знаходитись на обох серверах: сервері та клієнті.

Лише на сервері описуємо політику запуску цієї перевірки:

# vim /etc/sensu/conf.d/check_apache.json

{
  "checks": {
    "apache_check": {
      "command": "/etc/sensu/plugins/check-apache.rb",
      "interval": 60,
      "subscribers": [ "ALL" ]
    }
  }
}

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

Перевантажуємо Sensu-сервер та API-процес на сервері:

# service sensu-server restart
# service sensu-api restart

Та Sensu-клієнт на клієнті та сервері:

# service sensu-client restart

Перевіряємо Uchiwa та споглядаємо наступне:

Зупинимо Apache на клієнті та через хвилину можемо побачити результат в Uchiwa:

Створимо ще одну власну перевірку, котра буде слідкувати за наявністю файла.

# vim /etc/sensu/plugins/check-file.rb
#!/usr/bin/env ruby
require 'sensu-plugin/check/cli'

class CheckFile < Sensu::Plugin::Check::CLI

  option :file,
         :description => "Path to file",
         :short => '-f FILE',
         :long => '--file FILE',
         :required => true

  def initilize
    super
  end

  def run
    if(File.exists?(config[:file]))
      ok("The file '" + config[:file] + "' Exists!  :)")
    else
      critical("The file '" + config[:file] + "' does not Exists! :(")
    end
  end
end

Перевіримо її роботу локально:

# touch /tmp/test.file

# ./check-file.rb -f /tmp/test.file
CheckFile OK: The file '/tmp/test.file' Exists!  :)

# ./check-file.rb -f /tmp/test.file1
CheckFile CRITICAL: The file '/tmp/test.file1' does not Exists! :(

Тепер, як і минулого разу, описуємо перевірку на Sensu-сервері:

# vim /etc/sensu/conf.d/check_file.json

{
  "checks": {
    "check_file": {
      "command": "/etc/sensu/plugins/check-file.rb -f /tmp/test.file",
      "interval": 60,
      "subscribers": [ "ALL" ]
    }
  }
}

І перевантажуємо, як завжди. На клієнті та сервері:

# service sensu-client restart

Та лише на сервері:

# service sensu-server restart
# service sensu-api restart

Перевіряємо панель Uchiwa:

Через те, що ми не додавали перевірку на обидва сервери, проте всі сервери в підписці ALL, ми можемо спостерігати Unknown статус на Sensu-сервері.

Є і інші рекомендації того як писати перевірки. Наприклад, https://github.com/sensu/sensu-plugin.

Sensu має власний набір вже готових перевірок, котрий можна знайти за адресою http://sensu-plugins.io/ та встановити наступним чином:

# /opt/sensu/embedded/bin/gem install sensu-plugins-disk-checks

Команда вище проінсталює скрипти перевірки диску http://sensu-plugins.io/docs/installation_instructions.html
sensu-plugins-disk-checks має бути встановлена як на сервері, так і на клієнті задля перевірки на обох вузлах.

Також для роботи завантажених плагінів можуть бути потрібні додаткові залежності, котрі необхідно встановити як на клієнті, так і на сервері:

# apt-get install -y ruby ruby-dev build-essential
# /opt/sensu/embedded/bin/gem install sensu-plugin

По-замовчуванню, sensu-плагіни використовують не системну, а embedded версію ruby. Тому в попередніх командах ми скористались gem-установщиком embedded-версії. Проте, за бажанням, цю логіку можна змінити, відредагувавши значення змінної EMBEDDED_RUBY з true на false:

# vim /etc/default/sensu
...
EMBEDDED_RUBY=false
...

А нові gem-и встановлювати загально для всієї системи звичним способом:

# gem install sensu-plugins-disk-checks

Використовувати embedded ruby, як на мене, більш правильно, адже в разі поломок чи несумісностей пакетів не буде задіто системного ruby. Та і системні оновлення не будуть його оновлювати заодно.

Як і в попередніх випадках, перевірка має бути описана в conf.d на сервері:

# vim /etc/sensu/conf.d/check_disk.json

{
  "checks": {
    "check_disk": {
      "command": "/opt/sensu/embedded/bin/check-disk-usage.rb -w 80 -c 90",
      "interval": 60,
      "subscribers": [ "ALL" ]
    }
  }
}

sensu-client на клієнті та сервері має бути перевантажений, sensu-server та sensu-api має бути перевантажений лише на сервері.

Sensu чудово працює з перевірками від Nagios, причому не важливо на якій мові вони були написані.

Як і у випадку з Nagios, Sensu перевірки відпрацьовують по коду повернення скрипта:

Exit   Code Status
0      OK
1      WARNING
2      CRITICAL
3      UNKNOWN

Знайти приклад написання перевірки зовсім не складно.

Спробуємо додати перевірку роботи MongoDB, що написана на мові Python https://github.com/mzupan/nagios-plugin-mongodb і яка від самого початку була написана для Nagios. Для її роботи, очевидно, необхідна робоча MongoDB, та пакет python-pymongo:

# apt install mongodb
# apt install python-pymongo

Скачуємо, розпаковуємо, переміщуємо:

# cd /tmp
# wget https://github.com/mzupan/nagios-plugin-mongodb/archive/master.zip
# unzip master.zip
# cd nagios-plugin-mongodb-master
# cp check_mongodb.py /etc/sensu/plugins

Протестуємо чи нормально відпрацьовує перевірка:

# ./check_mongodb.py -A connect -W 2 -C 4 -D
OK - Connection took 0 seconds |connection_time=0.0;2.0;4.0

Все описане вище відбувається на клієнті.
Активуємо перевірку на Sensu-сервері:

# vim /etc/sensu/conf.d/check_mongod.json

{
  "checks": {
    "check_mongodb": {
      "command": "/etc/sensu/plugins/check_mongodb.py -A connect -W 2 -C 4 -D",
      "interval": 60,
      "subscribers": [ "ALL" ]
    }
  }
}

Перевантажуємо компоненти, як я вже згадував вище.

За допомогою параметру subscription можна управляти підписками перевірок. Тобто якщо сервер належить до якоїсь із груп - до нього одразу буде підключена певна група перевірок. Це зручно для однотипних серверів. Аналогічні опції є і у конкурентів: наприклад, в Nagios це називається hostgroups.

До цього часу всі скрипти перевірок, що описані в /etc/sensu/conf.d/ мали параметр "subscribers": [ "ALL" ], але який сенс підключати перевірку роботи серверу баз даних MongoDB, у разі її відсутності? Тому відредагуємо описано перевірку check_mongod.json на сервері Sensu:


# vim /etc/sensu/conf.d/check_mongod.json

{
  "checks": {
    "check_mongodb": {
    ...
      "subscribers": [ "MONGO" ]
    }
  }
}

Та заодно і перевірку check_file.json :

# vim /etc/sensu/conf.d/check_file.json

{
  "checks": {
    "check_file": {
      "command": "/etc/sensu/plugins/check-file.rb -f /etc/mongodb.conf",
      "interval": 60,
      "subscribers": [ "MONGO" ]
    }
  }
}

Аргумент було змінено на адресу конфігураційного файлу MongoDB, щоб в цьому був хоча б якийсь сенс.
Клієнт має бути оголошений як підписник "MONGO" перевірок:

# vim /etc/sensu/conf.d/client.json

{
  "client": {
    "name": "sensu_client_1",
    "address": "10.0.3.67",
    "subscriptions": [ "MONGO","ALL" ]
  }
}

Під "ALL" у нас описані всі інші перевірки. Як правило, під "ALL" мають бути описані всі базові перевірки, котрі стосуються всіх серверів інфраструктури. Після цього варто очистити всі неактивні чеки, благо, остання версія Uchiwa вже це робити вміє. Або ж можна очистити всі дані в Redis, на Sensu сервері, якщо це звісно не production сервер:

# redis-cli
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> exit

Через декілька хвилин все має з'явитись в Uchiwa:

Окремо хотілось би згадати про можливість відсилати метрики на Graphite. Так вже сталось, що Uchiwa не вміє графічно відображати історію метрик, тому практика відсилати їх на Graphite досить поширена. Подібний брак функціоналу спостерігається і в багатьох інших opensource-рішеннях.

Про установку Graphite та установку бекенду Grafana я зовсім нещодавно писав, тому дуже раджу попередньо про них прочитати:

http://blog.ipeacocks.info/2016/04/graphite-configuration-sending-metrics.html
http://blog.ipeacocks.info/2016/05/grafana-frontend-to-graphite.html

Скрипти для формування метрик для Graphite часто поширюються одразу з офіційними плагінами. Наприклад, одразу з установкою плагіну для перевірки диску check-disk-usage.rb (gem sensu-plugins-disk-checks) було установлено купу інших, в тому числі плагіни збору метрик для Graphite:

metrics-disk.rb
metrics-disk-usage.rb
metrics-disk-capacity.rb
check-smart.rb
check-smart-status.rb
check-fstab-mounts.rb
check-disk-usage.rb

І ось запуск скрипта metrics-disk-usage.rb на sensu клієнті:

# /opt/sensu/embedded/bin/ruby /opt/sensu/embedded/bin/metrics-disk-usage.rb

sensu_client_1.disk_usage.root.used 16161 1465400142
sensu_client_1.disk_usage.root.avail 29314 1465400142
sensu_client_1.disk_usage.root.used_percentage 36 1465400142
sensu_client_1.disk_usage.root.dev.used 0 1465400142
sensu_client_1.disk_usage.root.dev.avail 1 1465400142
sensu_client_1.disk_usage.root.dev.used_percentage 0 1465400142
sensu_client_1.disk_usage.root.run.used 9 1465400142
sensu_client_1.disk_usage.root.run.avail 3925 1465400142
sensu_client_1.disk_usage.root.run.used_percentage 1 1465400142

Що більше ніж годиться для Graphite. Ключ "--scheme" до скрипта збору метрик може дещо змінювати схему іменування метрики, котру буде надіслано.

Після його установки на клієнті, традиційно опишемо його на сервері:

# vim /etc/sensu/conf.d/metrics_disk.json

{
  "checks": {
    "metrics_disk": {
      "type": "metric",
      "command": "/opt/sensu/embedded/bin/metrics-disk-usage.rb",
      "interval": 10,
      "subscribers": ["MONGO"],
      "handlers": ["graphite"]
    }
  }
}

Тобто перевірка буде активна лише для групи MONGO, результати перевірок будуть передаватись на обробник (handler) graphite, котрий необхідно описати наступним чином:

# vim /etc/sensu/conf.d/graphite_handler.json
{
  "handlers": {
    "graphite": {
      "type": "tcp",
      "socket": {
        "host": "10.0.3.95",
        "port": 2003
      },
      "mutator": "only_check_output"
    }
  }
}

10.0.3.95:2003 - адреса мого Graphite-сервера, на котрий будуть надсилатись метрики. Перезапускаємо sensu-client на клієнті та сервері, та sensu-server та sensu-api лише на сервері. Спостерігаємо нову перевірку в Uchiwa:

І, на жаль, її приховати ніяк не можна, як мінімум поки. Є запит на цю фічу на GitHub https://github.com/sensu/uchiwa/issues/310, але мені не відомо чи вона реалізована.

Через декілька хвилин можна спостерігати відображені метрики в Graphite:

Для різноманіття, я також додав чек на збирання метрик роботи CPU. Установлюється і активується все аналогічним чином.

На клієнті:

# /opt/sensu/embedded/bin/gem install sensu-plugins-cpu-checks

Опис перевірки на сервері:

# vim /etc/sensu/conf.d/metrics_cpu.json
{
  "checks": {
    "metrics_cpu": {
      "type": "metric",
      "command": "/opt/sensu/embedded/bin/metrics-cpu-pcnt-usage.rb",
      "interval": 10,
      "subscribers": ["MONGO"],
      "handlers": ["graphite"]
    }
  }
}

Наразі картина в Graphite більш динамічна:

Є ще декілька схем інтеграції Sensu з Graphite. Graphite також може опитувати сервер черг, що вміє працювати по протоколу AMQP і, отримавши необхідні дані, відображати їх на своїй стороні. Така конфігурація може бути більш прийнятна у разі високих навантажень на Graphite. Відповідно Sensu має записувати метрики в черги.

Наступний варіант - за допомогою WizardVan. У цьому разі Sensu-сервер буде надсилати дані до Graphite не одразу по приходу нових значень, а фіксованими об'ємами. Звісно, такий варіант буде викликати деякі затримки в відображенні нових даних на стороні Graphite (ромір блоку, котрий надсилатиме WizardVan, можна змінювати), але, з іншої сторони, буде зменшувати к-ть створених підключень, що має призвести до зменшення навантажень на сервери.

Проте на момент написання статті мені не вдалось налаштувати ці варіанти інтеграції. Про подібні проблеми рапортують і інші користувачі.

У кінці статті також хотілось би згадати про налаштування роботи handler-а, що може відсилати пошту у разі появи проблем з перевірками. Він також налаштовується достатньо просто, проте попередньо необхідно мати робочий email-relay. Перевірити роботу останнього можна просто надіславши тестове повідомлення з bash на зразок наступного:

$ echo "hello world" | mail -s "a subject" someone@somewhere.com

Опишемо сам handler:

# vim /etc/sensu/conf.d/handler_email.json

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

Та додамо його до якоїсь з перевірок і після перевантажуємо всі sensu-* процеси на сервері:

# vim /etc/sensu/conf.d/check_apache.json

{
  "checks": {
    "apache_check": {
      "command": "/etc/sensu/plugins/check-apache.rb",
      "interval": 60,
      "handlers": ["email"],
      "subscribers": [ "ALL" ]
    }
  }
}

Зупиняємо Apache2 на клієнті та спостерігаємо наступне в логах sensu-сервера:

# tail -f /var/log/sensu/sensu-server.log
...
{"timestamp":"2016-06-10T12:47:52.425251+0000","level":"info","message":"publishing check request","payload":{"name":"apache_check","issued":1465562872,"command":"/etc/sensu/plugins/check-apache.rb"},"subscribers":["ALL"]}
{"timestamp":"2016-06-10T12:47:52.499917+0000","level":"info","message":"processing event","event":{"id":"cf6125ff-ade8-44e5-a6b1-3e723dd31814","client":{"name":"sensu_client_1","address":"10.0.3.67","subscriptions":["MONGO","ALL"],"version":"0.23.3","timestamp":1465562855},"check":{"command":"/etc/sensu/plugins/check-apache.rb","interval":60,"handlers":["email"],"subscribers":["ALL"],"name":"apache_check","issued":1465562872,"executed":1465562872,"duration":0.07,"output":"WARNING - Apache daemon is NOT running\n","status":1,"history":["0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","1","1","0","0","1"],"total_state_change":17},"occurrences":1,"action":"create","timestamp":1465562872}}
{"timestamp":"2016-06-10T12:47:52.515727+0000","level":"info","message":"handler output","handler":{"type":"pipe","command":"mail -s 'sensu event' someone@somewhere.com","name":"email"}}
...

Різноманітних хендлерів, в т.ч. для нотифікацій, існує досить багато. Sensu вміє розсилати повідомлення в багато різноманітних месенджерів на зразок HipChat, Slack, IRC.

Посилання:

https://www.digitalocean.com/community/tutorials/how-to-configure-sensu-monitoring-rabbitmq-and-redis-on-ubuntu-14-04
http://www.whiteboardcoder.com/2014/10/sensu-getting-started.html
http://www.whiteboardcoder.com/2015/02/second-sensu-reporting-to-uchiwa.html
http://www.joemiller.me/2012/01/19/getting-started-with-the-sensu-monitoring-framework/
http://www.joemiller.me/2012/02/02/sensu-and-graphite/
http://www.joemiller.me/2013/12/07/sensu-and-graphite-part-2/
http://roobert.github.io/2014/11/03/Sensu-with-Embedded-Graphite-Graphs/
http://roobert.github.io/2014/11/08/Sensu-Events-and-Graphite-Graphs/
http://roobert.github.io/2015/11/09/Sensu-What/
https://ianunruh.com/2014/05/monitor-everything-part-4.html
https://ianunruh.com/2014/05/monitor-everything-part-5.html
https://www.ovni.io/post/sensu-grid-the-missing-dashboard
http://develify.com/sensu-metrics-to-graphite-with-tcp-handler/
https://sensuapp.org/docs/latest/overview/architecture.html
https://sensuapp.org/docs/latest/installation/install-sensu-server-api.html
https://dzone.com/articles/monitoring-sensu-and-graphite
http://www.programblings.com/2013/11/06/creating-a-sensu-check/
https://habrahabr.ru/post/205804/
https://xakep.ru/2014/09/11/sensu-framework/
https://github.com/solarkennedy/sensu-training/tree/master/intermediate/lectures/Writing%20Your%20Own%20Sensu%20Checks
https://imansson.wordpress.com/2012/10/05/graphite-and-sensu/
http://blog.airwoot.com/post/137688775104/monitoring-using-sensu-statsd-graphite-grafana
https://github.com/sensu-plugins/sensu-plugins-graphite
https://www.reddit.com/r/sysadmin/comments/1vedbf/monitoring_alert_graph_sensu_kibana_graphite/
https://www.udemy.com/sensu-introduction/learn/v4/overview
http://www.slideshare.net/solarkennedy/sensu-yelp-a-guided-tour
http://www.slideshare.net/jeremy_carroll/sensu-14485155
http://www.slideshare.net/bethanyaerskine/sense-and-sensubility