Один инструмент, чтобы управлять ими всеми? Не.
Если вы работаете на предприятии, есть вероятность, что у вас есть разные метрические системы: у вас могут быть некоторые Cacti, Ganglia, Collectd и т. Д. … по историческим причинам, из-за разных отделов,
Это напомнило мне ситуацию, когда я работал в Identity Management: у вас могут быть LDAP, Active Directory, локальная база данных HR и т. Д. Будут планы и обсуждения использования одного поверх другого, и необходимо будет написать шлюзы. Там я выучил несколько уроков:
- Иметь как можно меньше источников / хранилищ информации
- Не пытайтесь преследовать один инструмент, чтобы управлять ими всеми , иначе не используйте инструмент для чего-то, для чего он не создан
- Сделайте самообслуживание для пользователя и автоматизируйте процессы
Шлюзы 1 к 1
Возьмите в качестве примера новый графит метрик, он имеет некоторые хорошие графические преимущества по сравнению с другими инструментами. Поэтому люди задаются вопросом, должен ли я перенести мои ганглии, собранные в графит? Graphite не поставляется со сложными сценариями сбора для памяти / диска / и т. Д., Поэтому мы должны полагаться на другие инструменты, такие как Cacti, Munin, Collectd, Ganglia, чтобы сначала собрать данные.
Итак, мы начинаем писать шлюзы для передачи данных в Graphite:
- Collectd -> Графит плагин (с использованием Perl)
- Collectd -> Graphite (Loggly — Nodejs) — прокси httpd
- Diamond-gmond — питон — ганглии -> графит
Но что произойдет, если мы также используем Opentsdb для хранения долгосрочных данных? Мы должны повторно реализовать эти шлюзы:
Проблема 1: дублирование усилий
Это просто кажется пустой тратой энергии на реализацию протокола в каждом инструменте. Это точно не первый раз, когда это происходит в истории: то же самое произошло с Collectd -> Ganglia Plugin
Если вы посмотрите на данные, которые передаются, то на самом деле они почти такие же:
имя метрики, значение, временная метка, необязательно имя хоста, некоторые теги метаданных
Таким образом, мы могли легко представить себе «универсальный» формат, который будет использоваться для перевода с и на.
Ganglia <-> Intermediate format <-> Graphite Collectd <-> Intermediate format <-> Opentsdb
С этим промежуточным форматом нам нужно было бы написать один конец уравнения только один раз.
Я начал думать об этом как о ffmpeg для мониторинга
Проблема 2: Сложно подключить дополнительных слушателей
Давайте добавим еще одну систему, которая хочет прослушивать метрики, что-то вроде Esper, оповещения Nagios, некоторые инструменты Dataware House и т. Д. Мы могли бы повторно использовать библиотеки от конца к другому, но нам нужно будет добавить больше шлюзов и разместить на месте каждый раз.
Лучшим подходом было бы использование подхода с шиной сообщений: каждый инструмент помещает и прослушивает шину и получает необходимые данные. Р.И. Пиенаар подробно писал об этом подходе в своей серии статей «Общие шаблоны обмена сообщениями» . Асо Джон Бергманс (Aso John Bergmans) написал отличный пост об использовании AMQP и Websockets для получения графики в реальном времени .
Некоторые инструменты уже имеют интеграцию очереди сообщений, но, похоже, отсутствует общий промежуточный формат
- Графит — интеграция Rabbit Mq: http://www.somic.org/2009/05/21/graphite-rabbitmq-integration/
- Графит — интеграция AMQP: https://code.launchpad.net/~lucio.torre/graphite/graphite-add-rabbitmq/+merge/16816
-
Графилия — Графит AMQP: https://github.com/fetep/graphlia/blob/master/graphlia.py
-
Collectd — плагин: AMQP — передавать или получать значение с помощью collectd: http://collectd.org/wiki/index.php/Plugin:AMQP
- Collectd- ZeroMQ: https://github.com/deactivation/collectd-write-zmq/
В качестве доказательства концепции я создал:
- Шлюз Ganglia-Zeromq в Ruby: https://github.com/jedi4ever/gmond-zmq
- Шлюз Collectd-Zeromq в Ruby: https://github.com/jedi4ever/collectd-zmq
Строительные блоки
В этом разделе я буду искать API (ориентированный на ruby) для получения данных в различные системы метрик и из них:
Графит — ВО
Отправка метрик из рубина в графит:
- Графит Gem: https://github.com/otherinbox/graphite
- Простой графит Gem: https://github.com/imeyer/simple-graphite
Они оба реализуют простой протокол, но для высокой производительности мы хотели бы использовать средство пакетирования через формат 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, вдохновение для этого можно найти в:
- Whisper — рубиновый камень: https://github.com/eric/whisper-rb
- Интерфейс Ruby для формата файла Graphis’s Whisper: https://github.com/mleinart/graphite_storage
- Объединение файлов Whisper: https://github.com/damaex17/whisper-merge
- Hoard — шепот для нодейцев: https://github.com/cgbystrom/hoard
Opentsdb — IN
Я не мог найти рубиновый гем, который реализует протокол Opentsdb для отправки данных, но его создание должно быть тривиальным. Opentsdb просто использует простой TCP-сокет, чтобы получить данные в
Opentsdb — OUT
Получение данных из Opentsdb страдает той же проблемой, что и Graphite: вы можете выполнять запросы к определенным графическим данным.
- Ruby gem — API opentsdb: https://github.com/j05h/continuum
Но вы не можете получить это, возможно, если вы напрямую взаимодействуете с Hbase / Java API. Опять же, лучше всего создать прослушиватель / прокси для простого протокола TCP.
Ganglia — IN
Отправлять метрики в Ganglia легко с помощью команды оболочки gmetric . Код ранних дней, описывающий это, все еще можно найти по адресу http://code.google.com/p/embeddedgmetric/.
Игригорик хорошо написал о том, как использовать гем Gmetric Ruby для отправки метрик
- Gmetric Ruby Gem — https://github.com/igrigorik/gmetric
- Оболочка HTTP для отправки метрик: https://github.com/garethr/gmetric-web
Если вы хотите ввести файлы журнала в 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
- Собранный рубиновый камень от Astro — https://github.com/astro/ruby-collectd/
Собранный — 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, вот вам вдохновение, но я не очень его исследовал
- Клиент API — https://github.com/sosedoff/munin-ruby
- Мунинский сетевой протокол — http://munin-monitoring.org/wiki/network-protocol
- Rails Plugin, который реализует протокол munin-node, чтобы позволить внутренним объектам Rails быть понятными Munin — https://github.com/jamesotron/Muninator
- Munin Node — Ruby: http://www.devco.net/archives/2011/10/02/interact-with-munin-node-from-ruby.php
Circonus
Если вам случится использовать Circonus, вот вам вдохновение, но я не очень его исследовал
RRD взаимодействие с ruby
Для тех, кто хочет читать и писать прямо из RRD в рубине, пожалуйста, получайте удовольствие:
- FFI -RRD — https://github.com/morellon/rrd-ffi
- RRD-RB Ruby — RRD — http://code.google.com/p/rrd-rb/
- RRD-graph-ruby — https://github.com/ion1/rrd-graph-ruby
- RRDtool — rrdruby — http://oss.oetiker.ch/rrdtool/prog/rrdruby.en.html
Оповещение о показателях:
Со всеми инструментами, входящими и выходящими, и унифицированным промежуточным форматом будет просто переписать традиционные инструменты проверки предупреждений для прослушивания значений в шине. Это означает, что вы можете прослушивать ваши Nagios, систему тикетов, систему пейджеров и т. Д. Из того же источника.
графитовый
Opentsdb
- Check_TSD — Opentsdb: http://opentsdb.net/nagios.html
Ганглиев
- http://blog.vuksan.com/2011/04/19/use-your-trending-data-for-alerting/
- https://github.com/mconigliaro/check_ganglia_metric
- https://github.com/daniyalzade/nagios-ganglia-plugin
- https://github.com/larsks/check_ganglia
Новая Реликвия
https://github.com/kogent/check_newrelic
Вывод
Должно быть возможным создать промежуточный формат и повторно использовать некоторые из этих библиотек для реализации функций IN и OUT. Почему бы не создать туман для мониторинга информации? Как реализует метрики получать, отправлять,
Следующая остановка Nagios, потому что она заслуживает отдельного поста …