Ads
Comments 35
0
А есть возможность как-то выводить графики из Grafana, не только в дашборды, но и например на свой ресурс?
0
Да, у Grafana есть свои API для этого, в том числе шаринг. Примерно год назад пользовался, сейчас на вскидку не вспомню. Как будет время — допишу статью на эту тему. Спасибо.
0
Сам пользуюсь Graphite / Carbon для метрик и он мне дико не нравится, начиная от большой привередливости к скорости дисковой подсистемы и заканчивая колхозом в самой инфраструктуре.
0
Как говорится, на вкус и цвет. Меня вполне устраивает. Моим запросам, и запросам начальства он соответствует. Да и выглядит, на мой взгляд, очень даже.
Сам Graphite, конечно, выглядит не очень, но Grafana всё это дело очень хорошо спасает.
0
для Carbon, говорят, лучше использовать carbon-c-relay, по крайней мере на rootConf графики показывали красивые, что С-версия намнооого быстрее carbon_cache.py
0
carbon-c-relay это замена carbon-cache в роли relay и aggregator. Он действительно очень быстрый. Агрегатор может переварить порядка пары миллионов метрик в минуту на железе уровня 2xe5-2620v3, а в виде relay — несколько миллионов в секунду (сеть куда более узкое место). Но там дальше узким местом станут другие компоненты.

Требования к дисковой подсистеме идут из формата хранения данных. Whisper довольно странный и имеет очень большой write amplification. Решения на базе всевозможных influxdb, kairosdb и т.п. тоже имеют свои проблемы (например influxdb намного меньше использует диск, но даже 0.13 требует больше CPU и хуже масштабируется чем carbon-cache). Встроенная кластеризация у graphite тоже довольно странная, но тут есть carbonzipper и carbonserver, которые несколько спасают положение.

С фронтэндом тоже все не очень здорово. Читать код graphite-web не очень приятно. Есть graphite-route-api который чище и не имеет собственного интерфейса, но он в какой то момент узким местом станет питон (если много сложной математики будет). Можно конечно взять pypy, станет раз в 5 быстрее, но все равно на сотне запросов в секунду и ему станет плохо. Есть реализации на Go, например carbonapi, но они зачастую не полностью повторяют функционал graphite-web's/graphite-api и, как минимум carbonapi, требует использования carbonzipper.

Но в целом адекватных альтернатив пока что не видно, протокол графита очень много кто умеет и при желании можно получить очень неплохую производительность на чтение и запись.
0
Претензия к диску у меня простая. Ganglia c rrdcached тянула кластер в сотню виртуалок находясь сама в виртуалке. Graphite в виртуалке вообще не живет, на вращающихся дисках быстро наступает затык с высоким LA на сервере, а ram disk из-за формата whisper постоянно не хватает, у меня вот уже за 28 гигов перевалил.
0
Да, whisper на не-SSD нагрузку держит плохо и попытки заставить его нормально работу выливаются в ram-диск или долгий и упорный тюнинг кэшей.

К слову, если есть только вращающиеся диски и не очень жалко в случаи проблем потерять данные, может быть тут как раз стоит глянуть на influxdb. Ну или если смириться с его недостатками, то на kairosdb с бэкэндом в виде cassandra. Они с диском намного лучше обращаются, но особенно первый стоит очень аккуратно тыкать, раньше были проблемы со стабильностью работы.
0
И что? а где эти самые графики для cpu,mem,load,df,disk,network (плюс интеграл скорости по времени в виде потребленного трафика) и так далее? Неужели самому рисовать эти метрики?

Так что Graphite крут как идея, но я не смог найти готовых пресетов для всех системных метрик. В отличие от решений на основе rrd, вроде Cacti или Collectd+CGP — там нужно было просто нужные плагины подключить в демон и они сразу в браузере появляются как графики.
0
collectd умеет отправлять данные в graphite.

Еще можно посмотреть на diamond из популярного.
0
Про collectd напишу чуть позже. Настроить получилось, и довольно легко. Там уйма плагинов. И это очень хорошо.
0
# Log files
sudo touch /var/log/nginx/grafana.access.log
sudo chmod 666 /var/log/nginx/grafana.access.log
sudo touch /var/log/nginx/grafana.error.log
sudo chmod 666 /var/log/nginx/grafana.error.log

Я прошу прощения, но зачем это? Nginx сам создает логи (если может писать в директорию), а chmod 666 (спасибо что не 777) зачем? Это просто 5 бесполезных строк.
И зачем делать touch /etc/nginx/conf.d/grafana.conf, если можно просто сказать vim /etc/nginx/conf.d/grafana.conf и вставить содержание конфига.

Вместо стороннего модуля nginx echo, можно использовать встроенный модуль rewrite с директивой return:
  location = /robots.txt {
     default_type text/html;
     return 200 "User-agent: *\nDisallow: /\n";
  }

Хотя, как по мне, проще файлик подложить в нужное место, чем потом вспонимать откуда этот robots.txt взялся и где его править.
0
Спасибо за замечания. Действительно, эти строки оказались лишними. Исправил.
0
Настройки графаны для постгрес — нужно порт исправить (по-умолчанию)
type = mysql
host = 127.0.0.1:54323306
0
Напишу, что б пошире: сейчас графит в первозданном виде используют в основном только мамонты. Есть вполне приличный https://github.com/lomik/go-carbon для сохранения метрик. В качестве рилей можно использовать https://github.com/graphite-ng/carbon-relay-ng или более быстрый https://github.com/grobian/carbon-c-relay
Для отображения графиков\апи можно использовать как каноничный graphite-web, так и более новый http://graphite-api.readthedocs.io/en/latest/

Мы вообще сейчас перешли на zipper stack и довольны https://github.com/dgryski/carbonapi https://github.com/dgryski/carbonzipper

Я на последнем РИТ++ и на Kyiv DevOps day расказывал о производительности графита немного. http://www.slideshare.net/VsevolodPolyakov/metrics-where-and-how
0
go-carbon принципиально не сильно отличается от carbon-cache. Да, он лучше с точки зрения CPU, но неэффективность whisper'а остается (как с точки зрения disk i/o и write amplification, так и с точки зрения того сколько места тратится на 1 точку). Плюс ко всему carbon в любом его виде довольно сложен в поддержке (требует много ручной или полуручной работы на каждый чих). Но да, с точки зрения скорости альтернатив zipper stack'у я не знаю.
0
а что эфективнее виспера для хранения метрик? Вот как раз в докладе выше есть часть бенчмарка, который я делал. И openTSDB и influx и prometheus медленнее go-carbon. Тоже самое могу сказать о cyanite с которым я знаком по проду.
0
На самом деле ceres немного получше, но реально работает только как single server решение (т.к. никто не делал поддержку оного в carbonserver). На самом деле за последние пару лет появилась пачка различных баз данных, возможно у какой-нибудь из них получше с эффективностью, но я пока в процессе тестирования.

Что касается carbonate и buckytools — у них есть некоторые проблемы, делающие их непригодными для использования в продакшене. Например что carbonate заставляет использовать мягко говоря посредственную реализацию consistent hash из carbon-cache'а. У второго как я понимаю та же проблема + поддержка только replication factor=1, что тоже не есть прям очень здорово. И поверх любого из них нужно писать какую-то обвязку, искать способы убедиться что все корректно, доступно и так далее, что в общем уже есть для других баз данных.

P.S. И к слову, с точки зрения нагрузки на диск InfluxDB. Cassandra, KairosDB и пр. товарищи лучше, другое дело что там с масштабированием, скоростью чтения, нагрузкой на CPU и т.п. беда (у каждого что-то свое).
0
>возможно у какой-нибудь из них получше с эффективностью, но я пока в процессе тестирования

Ну я тестировал некоторые из них, я выше писал. Они хуже. Ceres, кстати, вроде как забросили и никто его не использует. А бакитул надо допиливать, да. И я так и не понял, что вы считаете эфективнее whisper.
disk i\o в виспере (как и в любом другом решении) решается через кеш и запись больших блоков. Место на точку пусть и критично, но не так как CPU, даже если пишешь много метрик.

И полуручная работа на каждый чих — это ребалансировка каждый чих? В общем давайте по пруфам, а не по абстрактым «может что-то быть лучше, но я не проверял», так намного интереснее :)
0
Ceres не полностью заброшен, но то что на graphite-project — как минимум раньше было абсолютно не юзабельно (merge ломал данные). Использовали форки, например: https://github.com/dkulikovsky/ceres, также есть еще новая реализация демона на Ди, но ее я уже не щупал: https://github.com/iain-buclaw-sociomantic/carbond (тоже слегка подзаброшена, но возможно и что человек просто не выкладывает свежие сырцы). В целом бэкэнд не очень интересный, т.к. дает лишь незначительное улучшение эффективности хранения данных и в общем-то незначительно быстрее, а перерабатывать carbonserver придется существенно.

Whisper из-за архитектуры подвержен write amplification'у если у тебя более чем 1 retention period, большой кэш смягчает I/O но ценой задержки доставки данных до диска. Плюс ко всему, в моем случаи место более критично чем I/O и даже CPU. Требование растет из желания людей хранить как можно больше данных как можно дольше. При этом предсказать сколько будет требоваться места можно, но периодически случаются накладки (немного неожиданные запуски или еще какая-нибудь команда осознает что в графит можно слать много данных и потом их читать оттуда). Поэтому и ребалансировка, к сожалению, не такой уж редкий процесс. На вскидку за последний год мне пришлось перебалансировать 3/4 графитных кластеров которые у нас есть и предстоит еще миграция на более подходящее железо, в которое, к сожалению, нельзя просто взять и переткнуть диски. Причины миграции простые — значительный кусок располагается на серверах от одного известного вендора, у которого есть неотключаемый рейд-контроллер, который банально уходит в себя каждые недели этак три. На масштабах порядка сотен серверов это выливается в среднем в 7 падений в неделю. А что касается объема данных, то речь идет о десятках, а то уже и сотнях (с учетом всей репликации) ТБ данных в графите. В общем у нас просто другой юзкейс и реально производительности 80-100k/s на сервер более чем достаточно, а ее показывает и carbon-cache.

Что касается про полуручную работу и допиливание. carbon_ch (пользуясь терминологией из carbon-c-relay) дает очень плохое распределение метрик, но позволяет использовать «из коробки» все тулзы и carbon-link. Притом проблема настолько большая, что разница в нагрузке между carbon_ch и jump_fnv1a хэшами составляет порядка 20%. Т.е. в какой-то момент на одном из серверов кластера место закончилось, а на другом еще 200ГБ свободно. Соответственно отказываясь от carbon_ch приходится отказываться от даже потенциальной возможности реализации carbon-link и доступа к кэшу. Притом решить проблему с кэшом в целом не многим проще, чем прикрутить отдельный in-memory сторадж на, допустим, последние сутки данных. Подводя итог, любой из этих наборов утилит не очень работоспособен из коробки в моем случаи, нужно доделывать или переделывать какие-то куски. В любом случаи готового «из коробки» механизма, который бы полечил упавший сервер, смигрировал бы данные и т.п. отсутствует, нужна какая-то дополнительная работа, которая вполне вероятна сопоставима с миграцией данных.

Про Бэкэнды — увы, я не знаю ничего лучше на текущий момент. Собственно говоря я дискуссию то и затеял, чтобы узнать вдруг ком-то что-то интересное встречалось. Так у меня в планах посмотреть на RiakTS, BTrDB и еще парочку бэкэндов.

И к слову, а чем в своих тестах Вы генерировали нагрузку, если не секрет? И в целом, если можно, чуть поподробнее про методику тестирования хотелось бы услышать.
0
>>>Whisper из-за архитектуры подвержен write amplification'у если у тебя более чем 1 retention period, большой кэш смягчает I/O но ценой задержки доставки данных до диска

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

>>>А что касается объема данных, то речь идет о десятках, а то уже и сотнях (с учетом всей репликации) ТБ данных в графите. В общем у нас просто другой юзкейс

Угу. Мы решили писать много, но хранить не долго. 80-100 к на сервер показывает много чего, тут уже смотря что за сервер.

>>>Соответственно отказываясь от carbon_ch приходится отказываться от даже потенциальной возможности реализации carbon-link и доступа к кэшу.

вот это не понял :) карбон линк это же часть go-carbon\carbon-cache демона, в то время как carbon_ch это алгоритм распределения метрик через рилей. То есть всё равно что приходит на карбон, если он сам реализовывает carbon-link то любой ридер (graphite-api, graphite-web) может его вычитать.

>>>Притом решить проблему с кэшом в целом не многим проще, чем прикрутить отдельный in-memory сторадж на, допустим, последние сутки данных.

есть такая штука carbon-ram, у них метрики хранятся в redix tree, работает быстро. Но чтобы правильно его реквестить надо понимать где мы храним сутки, а где всё остальное и делать математику исходя из этого.

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

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

Кстати, может будет интересно — недавно общался с ребятами, так они вообще за go-carbon поставили ceph и живут. Говорят что всё работает быстро, а за хранение и распределение данных отвечает ceph. Может вам такой вариант подойдет? Он достаточно легко масштабируется и неплохо выдерживает различного рода нагрузки.

>>>И к слову, а чем в своих тестах Вы генерировали нагрузку, если не секрет? И в целом, если можно, чуть поподробнее про методику тестирования хотелось бы услышать.

Если коротко, то я генерил нагрузку самописной тулой (потому что тестил много разных бекендов) с 10 t3.medium инстансов, каждый элемент тестился 3-4 раза (я сразу делал через terraform и docker, поэтому было просто). Тестил не особо точно, потому что разница часто была очень ощутима.

0
>>> Ну выставлять несколько ретеншенов это надо быть очень смелым или жестко следить за структурой метрик, потому что разные данные постагрегируются по разному, некоторые вообще нельзя постагрегировать и данные могут оказаться нерелевантными.

Ровно так и делаем. Где можно выставляем, меняем aggregation method'ы и т.п., есть некоторые правила даже (для ряда кластеров если у метрики постфикс _count то агрегируем как sum).

>>> Угу. Мы решили писать много, но хранить не долго. 80-100 к на сервер показывает много чего, тут уже смотря что за сервер.

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

>>> вот это не понял :) карбон линк это же часть go-carbon\carbon-cache демона, в то время как carbon_ch это алгоритм распределения метрик через рилей. То есть всё равно что приходит на карбон, если он сам реализовывает carbon-link то любой ридер (graphite-api, graphite-web) может его вычитать.

Его нужно переписывать, т.к. в graphite-web carbonlink тесно завязан на carbon_ch. Также как и во всех утилитах определение положения метрик идет исходя из того что все используют carbon_ch. Т.е. эту часть кода нужно соответственным образом переписывать. Ну и да, фронтэнд на python тоже уже является узким местом достаточно давно, поэтому для значительной части запросов мы используем carbonapi.

>>> есть такая штука carbon-ram, у них метрики хранятся в redix tree, работает быстро. Но чтобы правильно его реквестить надо понимать где мы храним сутки, а где всё остальное и делать математику исходя из этого.

Не смог с ходу найти проект. Если речь про carbonmem, то он быстрый, но требует некоторого допиливания под general purpose задачи (там оптимизация под запросы типа topk, что делает его не таким эффективным для запросов общего вида) и Вы правы, нужно реализовывать поддержку в carbonzipper. Вся проблема в том, что 24 часа данных будет занимать больше 1ТБ (из рассчета что 1 точка занимает 8 байт) и даже хорошие решения в такой ситуации могут не подойти без доработки, а доработка это время.

>>> Кстати, может будет интересно — недавно общался с ребятами, так они вообще за go-carbon поставили ceph и живут.

Да, в планах тоже есть желание потестировать различные варианты хранилок, но опять же в планах.

>>> Если коротко, то я генерил нагрузку самописной тулой

Понятно, ну я примерно также своими самописными тулзами делаю сейчас. А возможность прочитать эти данные потом не проверялась? На этом еще половина бэкэндов станет хуже чем виспер.
0
проверял конечно. На infux, например, вообще метрики терялись :) И я так и не понял это было во время компакшенов или вообще когда
картинка
image
0
Я скорее про то, что чтение данных отсеивает все бэкэнды на базе LevelDB, RocksDB и т.п., т.к. процесс чтения тратит слишком много ресурсов.
0
Кстати, по автоматизации кластера графита есть популярные https://github.com/graphite-project/carbonate и менее известный, но более мощный https://github.com/jjneely/buckytools
Only those users with full accounts are able to leave comments.  , please.