Статьи

Мониторинг Страны Чудес — Метрики — API — Шлюзы

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

Один инструмент, чтобы управлять ими всеми? Не.

Если вы работаете на предприятии, есть вероятность, что у вас есть разные метрические системы: у вас могут быть некоторые Cacti, Ganglia, Collectd и т. Д. … по историческим причинам, из-за разных отделов,

Это напомнило мне ситуацию, когда я работал в Identity Management: у вас могут быть LDAP, Active Directory, локальная база данных HR и т. Д. Будут планы и обсуждения использования одного поверх другого, и необходимо будет написать шлюзы. Там я выучил несколько уроков:

  1. Иметь как можно меньше источников / хранилищ информации
  2. Не пытайтесь преследовать один инструмент, чтобы управлять ими всеми , иначе не используйте инструмент для чего-то, для чего он не создан
  3. Сделайте самообслуживание для пользователя и автоматизируйте процессы

Шлюзы 1 к 1

Возьмите в качестве примера новый графит метрик, он имеет некоторые хорошие графические преимущества по сравнению с другими инструментами. Поэтому люди задаются вопросом, должен ли я перенести мои ганглии, собранные в графит? Graphite не поставляется со сложными сценариями сбора для памяти / диска / и т. Д., Поэтому мы должны полагаться на другие инструменты, такие как Cacti, Munin, Collectd, Ganglia, чтобы сначала собрать данные.

Итак, мы начинаем писать шлюзы для передачи данных в Graphite:

Но что произойдет, если мы также используем Opentsdb для хранения долгосрочных данных? Мы должны повторно реализовать эти шлюзы:

Проблема 1: дублирование усилий

Это просто кажется пустой тратой энергии на реализацию протокола в каждом инструменте. Это точно не первый раз, когда это происходит в истории: то же самое произошло с Collectd -> Ganglia Plugin

Если вы посмотрите на данные, которые передаются, то на самом деле они почти такие же:

имя метрики, значение, временная метка, необязательно имя хоста, некоторые теги метаданных

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

Ganglia  <-> Intermediate format <-> Graphite
Collectd <-> Intermediate format <-> Opentsdb

С этим промежуточным форматом нам нужно было бы написать один конец уравнения только один раз.

Я начал думать об этом как о ffmpeg для мониторинга

Проблема 2: Сложно подключить дополнительных слушателей

Давайте добавим еще одну систему, которая хочет прослушивать метрики, что-то вроде Esper, оповещения Nagios, некоторые инструменты Dataware House и т. Д. Мы могли бы повторно использовать библиотеки от конца к другому, но нам нужно будет добавить больше шлюзов и разместить на месте каждый раз.

Лучшим подходом было бы использование подхода с шиной сообщений: каждый инструмент помещает и прослушивает шину и получает необходимые данные. Р.И. Пиенаар подробно писал об этом подходе в своей серии статей «Общие шаблоны обмена сообщениями» . Асо Джон Бергманс (Aso John Bergmans) написал отличный пост об использовании AMQP и Websockets для получения графики в реальном времени .

Некоторые инструменты уже имеют интеграцию очереди сообщений, но, похоже, отсутствует общий промежуточный формат

В качестве доказательства концепции я создал:

Строительные блоки

В этом разделе я буду искать API (ориентированный на ruby) для получения данных в различные системы метрик и из них:

Графит — ВО

Отправка метрик из рубина в графит:

Они оба реализуют простой протокол, но для высокой производительности мы хотели бы использовать средство пакетирования через формат Pickle. Я не смог найти камень Pickle для ruby, но он мог работать через шлюз Ruby-Python http://rubypython.rubyforge.org/ .

Быстрее — графитовый ретранслятор на основе Java Netty использует тот же подход https://github.com/markchadwick/graphite-relay

Другой способ перевести ваши данные в графит — это использовать Etsy’s Logster https://github.com/etsy/logster

Майк Бриттен очень объясняет, как его использовать в журналах «Возьми мои логи» … Пожалуйста! — Скоростная онлайн-сессия Видео конференции PDF

Графит — OUT

Получить все данные из Graphite невозможно через стандартный API. Вы получаете график в виде необработанных данных, но это вряд ли имеет значение.

Похоже, что лучшим вариантом будет прослушивание приемника графита-udp и дублирование информации на шине сообщений.

Альтернативой может быть прямое чтение из хранилища Whisper, вдохновение для этого можно найти в:

Opentsdb — IN

Я не мог найти рубиновый гем, который реализует протокол Opentsdb для отправки данных, но его создание должно быть тривиальным. Opentsdb просто использует простой TCP-сокет, чтобы получить данные в

Opentsdb — OUT

Получение данных из Opentsdb страдает той же проблемой, что и Graphite: вы можете выполнять запросы к определенным графическим данным.

Но вы не можете получить это, возможно, если вы напрямую взаимодействуете с Hbase / Java API. Опять же, лучше всего создать прослушиватель / прокси для простого протокола TCP.

Ganglia — IN

Отправлять метрики в Ganglia легко с помощью команды оболочки gmetric . Код ранних дней, описывающий это, все еще можно найти по адресу http://code.google.com/p/embeddedgmetric/.

Игригорик хорошо написал о том, как использовать гем Gmetric Ruby для отправки метрик

Если вы хотите ввести файлы журнала в ganglia, Logtailer может быть вашим делом https://bitbucket.org/maplebed/ganglia-logtailer

Ganglia — OUT

Владимир описывает варианты, в то время как он объясняет, как получить данные Ganglia в графит

Вариант 1 — опросить Gmond по TCP и получить XML из его текущих данных:

Варианты 2 — прослушивание протокола UDP в качестве дополнительного приемника.

Я реализовал оба подхода в https://github.com/jedi4ever/gmond-zmq

Примечание. В качестве побочного эффекта я обнаружил, что показатели, отправляемые в UDP, на самом деле более точные, чем значения при запросе XML.

Собран — В

Так что отправляя метрики в Collectd, вы можете использовать гем ruby ​​из Astro, который реализует большую часть протокола UDP

Собранный — OUT

Я даю Collectd по цене лучшего выхода.

В настоящее время он реализует разных авторов:

  • Сетевой плагин
  • Плагин UnixSock
  • Углеродный плагин
  • CSV
  • RRDCacheD
  • RRDtool
  • Написать HTTP плагин

И отключенный ZeroMQ — https://github.com/deactivation/collectd-write-zmq

Двоичный протокол http://collectd.org/wiki/index.php/Binary_protocol довольно прост для прослушивания.

Munin

Если вам случится использовать Munin, вот вам вдохновение, но я не очень его исследовал

Circonus

Если вам случится использовать Circonus, вот вам вдохновение, но я не очень его исследовал

RRD взаимодействие с ruby

Для тех, кто хочет читать и писать прямо из RRD в рубине, пожалуйста, получайте удовольствие:

Оповещение о показателях:

Со всеми инструментами, входящими и выходящими, и унифицированным промежуточным форматом будет просто переписать традиционные инструменты проверки предупреждений для прослушивания значений в шине. Это означает, что вы можете прослушивать ваши Nagios, систему тикетов, систему пейджеров и т. Д. Из того же источника.

графитовый

Opentsdb

Ганглиев

Новая Реликвия

https://github.com/kogent/check_newrelic

Вывод

Должно быть возможным создать промежуточный формат и повторно использовать некоторые из этих библиотек для реализации функций IN и OUT. Почему бы не создать туман для мониторинга информации? Как реализует метрики получать, отправлять,

Следующая остановка Nagios, потому что она заслуживает отдельного поста …