Хочу поделиться опытом установки и настройки сервиса для сбора и отображения метрик Graphite + Grafana.
Искал долго, читал много, нашёл 2 статьи на английском, добавил своё, в итоге получилась данная статья.
Немного предыстории..
Graphite — система для отображения метрик (числовых значений) для любых свойств сервера или домашнего ПК.
Carbon — демон/бэкенд, в который пишутся метрики.
Grafana — более красивая и удобная Web-морда для Graphite.
И так, приступим.
Установка и настройка Php + Nginx + MySQL
Установка Php + Nginx + MySQL
Тут всё довольно просто.
sudo apt install php5-fpm php5-json php5-mysql
sudo apt install nginx nginx-extras
sudo apt install mysql-serverВо время установки будет запрос пароля для root-пользователя MySQL.
Установка phpMyAdmin
Для более удобного доступа у базам данных MySQL установим phpMyAdmin.
Скачиваем отсюда последнюю версию
cd /usr/share/
sudo wget https://files.phpmyadmin.net/phpMyAdmin/4.6.2/phpMyAdmin-4.6.2-all-languages.zip
sudo unzip phpMyAdmin-4.6.2-all-languages.zip
sudo rm phpMyAdmin-4.6.2-all-languages.zip
sudo mv phpMyAdmin-4.6.2-all-languages phpmyadminНастраиваем Nginx для phpMyAdmin
В файл настроек /etc/nginx/conf.d/pma.conf пишем следующее:
server {
server_name pma.your.site;
listen 80;
location / {
root /usr/share/phpmyadmin/;
index index.php index.html index.htm;
location ~ ^/(.+\.php)$ {
try_files $uri =404;
root /usr/share/phpmyadmin/;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include /etc/nginx/fastcgi_params;
}
location ~* ^/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
root /usr/share/phpmyadmin/;
}
}
}И перезапускаем Nginx
sudo service nginx restartПредварительные настройки MySQL
Заходим по адресу pma.your.site, который Вы прописали в настройках выше, авторизируемся под root пользователем с тем паролем, который Вы установили во время установки MySQL.
Создадим базу данных graphite и пользователя graphite, и дадим этому пользователю все привилегии на эту базу.
Установка и настройка Graphite + Carbon
Установка Graphite + Carbon
Тут тоже всё довольно просто:
sudo apt-get install graphite-web graphite-carbonНастройка Graphite
Редактируем файл конфигурации /etc/graphite/local_settings.py.
SECRET_KEY = 'MY NICE RANDOM SALT'
TIME_ZONE = 'UTC'
USE_REMOTE_USER_AUTHENTICATION = True
DATABASES = {
'default': {
'NAME': 'graphite',
'ENGINE': 'django.db.backends.mysql',
'USER': 'graphite',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': ''
}
}Синхронизация базу данных
Синхронизируем базу данных следующей командой
sudo graphite-manage syncdbНастройка Carbon
Редактируем следующие файлы конфигурации
/etc/default/graphite-carbon
CARBON_CACHE_ENABLED = true/etc/carbon/carbon.conf
ENABLE_LOGROTATION = TrueКопируем стандартные настройки агрегации хранилища
sudo cp /usr/share/doc/graphite-carbon/examples/storage-aggregation.conf.example /etc/carbon/storage-aggregation.confИ перезапускаем Carbon
sudo service carbon-cache startУстановка uWSGI
Для установки uWSGI запустите следующие команды
sudo apt-get install python-dev
sudo pip install uwsgiЕсли в Вашей системе не установлен pip — устанавливаем его
sudo apt-get install python-pipИ выполняем команды выше.
Копируем стандартный файл конфигурации
sudo cp /usr/share/graphite-web/graphite.wsgi /usr/share/graphite-web/graphite_wsgi.pyСоздаём файл конфигурации:
sudo nano /etc/init/uwsgi-graphite.confИ вписываем туда следующие строки:
env UWSGI_BIN=/usr/local/bin/uwsgi
env PYTHONPATH=/usr/share/graphite-web
expect fork
umask 0000
start on runlevel [2345]
stop on runlevel [!2345]
script
exec $UWSGI_BIN --socket /var/run/graphite.sock --master --need-app --catch-exceptions --reload-on-exception --pp $PYTHONPATH -w graphite_wsgi:application --buffer-size 32768 -p 4 -O 2 >>/var/log/graphite.log 2>&1 &
end scriptИ запускаем Graphite
sudo service uwsgi-graphite startНастройка Nginx для Graphite
Редактируем файл конфигурации /etc/nginx/conf.d/graphite.conf
server {
server_name graphite.your.site;
listen 80;
access_log /var/log/nginx/graphite.access.log;
error_log /var/log/nginx/graphite.error.log;
root /usr/share/graphite-web;
location = /favicon.ico {
return 204;
}
location /content {
alias /usr/share/graphite-web/static;
expires max;
}
location / {
uwsgi_pass unix:/var/run/graphite.sock;
include uwsgi_params;
}
}Перезапускаем Nginx и переходим по адресу graphite.your.site
Тестирование Graphite
Для проверки работоспособности Graphite достаточно выполнить одну простую команду:
echo "test.count 9 `date +%s`" | nc -q0 127.0.0.1 2003;Ну или запустить цикл:
for i in 4 6 8 16 2; do echo "test.count $i `date +%s`" | nc -q0 127.0.0.1 2003; sleep 6; doneТеперь в Graphite модно наблюдать следующее:
Установка и настройка красивой Web-морды Grafana
Установка Grafana
Для установки Grafana выполняем следующие команды:
echo 'deb https://packagecloud.io/grafana/stable/debian/ wheezy main' | sudo tee -a /etc/apt/sources.list
curl https://packagecloud.io/gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install grafanaНастройка MySQL для Grafana
Создадим в MySQL базу данных grafana и дадим все привилегии на неё пользователю graphite, которого мы создали ранее.
Редактируем файл конфигурации /etc/grafana/grafana.ini
[database]
type = mysql
host = 127.0.0.1:3306
name = grafana
user = graphite
password = mypassword
[server]
protocol = http
http_addr = 127.0.0.1
http_port = 3000
domain = grafana.your.site
enforce_domain = true
root_url = %(protocol)s://%(domain)s/
[security]
admin_user = admin #Имя пользователя-администратора
admin_password = your_secure_password # Пароль пользователя-администратора
secret_key = your_random_secret_saltИ запускаем Grafana
sudo service grafana-server startНастройка Nginx для Grafana
Редактируем файл конфигурации /etc/nginx/conf.d/grafana.conf
server {
server_name grafana.your.site;
listen 80;
access_log /var/log/nginx/grafana.access.log;
error_log /var/log/nginx/grafana.error.log;
location = /robots.txt {
echo "User-agent: *\nDisallow: /\n";
}
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
}
}Перезапускаем Nginx и переходим по адресу grafana.your.site
Вводим логин/пароль администратора, которые Вы установили выше, и попадаем в админ-панель Grafana.
Перед тем, как создавать дашборды и выводить метрики, нужно настроить источники данных.
Переходим в раздел Data Source -> Add New
Вводим следующие данные
- Name: graphite
- URL: graphite.your.site
Вот пример:
Теперь переходим на главную страницу, жмём New Dashboard -> New,
Слева будет малозаметная зелёная кнопка, при наведении на которую она выползет из-за края экрана. Нажимаем на неё и затем Add Panel -> Graph
Внизу Вы увиlите метрики, которые мы создавали тестовой командой выше, test и count.
На этом пока что всё, позже я расcкажу о плагинах для Grafana.
Больше информации
Пожалуйста, проследуйте по приведенным ниже ссылкам, чтобы узнать больше о Grafana и его удивительных настройках.
Благодарность
За основу статьи были взяты материалы следующих статей:
- Deploy Graphite and Nginx on an Ubuntu 14.04 server
- Deploy Grafana and Graphite an Ubuntu 14.04 server
Оригинал статьи опубликован на моём блоге
Комментарии (35)
divanikus
06.06.2016 19:43Сам пользуюсь Graphite / Carbon для метрик и он мне дико не нравится, начиная от большой привередливости к скорости дисковой подсистемы и заканчивая колхозом в самой инфраструктуре.
kovalyov_makc
06.06.2016 19:47Как говорится, на вкус и цвет. Меня вполне устраивает. Моим запросам, и запросам начальства он соответствует. Да и выглядит, на мой взгляд, очень даже.
Сам Graphite, конечно, выглядит не очень, но Grafana всё это дело очень хорошо спасает.
thunderspb
06.06.2016 20:05для Carbon, говорят, лучше использовать carbon-c-relay, по крайней мере на rootConf графики показывали красивые, что С-версия намнооого быстрее carbon_cache.py
Civil
06.06.2016 21:25carbon-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.
Но в целом адекватных альтернатив пока что не видно, протокол графита очень много кто умеет и при желании можно получить очень неплохую производительность на чтение и запись.divanikus
07.06.2016 00:48Претензия к диску у меня простая. Ganglia c rrdcached тянула кластер в сотню виртуалок находясь сама в виртуалке. Graphite в виртуалке вообще не живет, на вращающихся дисках быстро наступает затык с высоким LA на сервере, а ram disk из-за формата whisper постоянно не хватает, у меня вот уже за 28 гигов перевалил.
Civil
07.06.2016 00:57Да, whisper на не-SSD нагрузку держит плохо и попытки заставить его нормально работу выливаются в ram-диск или долгий и упорный тюнинг кэшей.
К слову, если есть только вращающиеся диски и не очень жалко в случаи проблем потерять данные, может быть тут как раз стоит глянуть на influxdb. Ну или если смириться с его недостатками, то на kairosdb с бэкэндом в виде cassandra. Они с диском намного лучше обращаются, но особенно первый стоит очень аккуратно тыкать, раньше были проблемы со стабильностью работы.
bers666
06.06.2016 20:08И что? а где эти самые графики для cpu,mem,load,df,disk,network (плюс интеграл скорости по времени в виде потребленного трафика) и так далее? Неужели самому рисовать эти метрики?
Так что Graphite крут как идея, но я не смог найти готовых пресетов для всех системных метрик. В отличие от решений на основе rrd, вроде Cacti или Collectd+CGP — там нужно было просто нужные плагины подключить в демон и они сразу в браузере появляются как графики.Civil
06.06.2016 21:08collectd умеет отправлять данные в graphite.
Еще можно посмотреть на diamond из популярного.kovalyov_makc
07.06.2016 09:14Про collectd напишу чуть позже. Настроить получилось, и довольно легко. Там уйма плагинов. И это очень хорошо.
1it
06.06.2016 23:02# 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 взялся и где его править.kovalyov_makc
07.06.2016 09:35Спасибо за замечания. Действительно, эти строки оказались лишними. Исправил.
valentinmk
07.06.2016 16:54Настройки графаны для постгрес — нужно порт исправить (по-умолчанию)
type = mysql
host = 127.0.0.1:54323306
ctrlok
07.06.2016 18:45Напишу, что б пошире: сейчас графит в первозданном виде используют в основном только мамонты. Есть вполне приличный 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-howCivil
07.06.2016 19:12go-carbon принципиально не сильно отличается от carbon-cache. Да, он лучше с точки зрения CPU, но неэффективность whisper'а остается (как с точки зрения disk i/o и write amplification, так и с точки зрения того сколько места тратится на 1 точку). Плюс ко всему carbon в любом его виде довольно сложен в поддержке (требует много ручной или полуручной работы на каждый чих). Но да, с точки зрения скорости альтернатив zipper stack'у я не знаю.
ctrlok
07.06.2016 21:35а что эфективнее виспера для хранения метрик? Вот как раз в докладе выше есть часть бенчмарка, который я делал. И openTSDB и influx и prometheus медленнее go-carbon. Тоже самое могу сказать о cyanite с которым я знаком по проду.
Civil
07.06.2016 23:57На самом деле ceres немного получше, но реально работает только как single server решение (т.к. никто не делал поддержку оного в carbonserver). На самом деле за последние пару лет появилась пачка различных баз данных, возможно у какой-нибудь из них получше с эффективностью, но я пока в процессе тестирования.
Что касается carbonate и buckytools — у них есть некоторые проблемы, делающие их непригодными для использования в продакшене. Например что carbonate заставляет использовать мягко говоря посредственную реализацию consistent hash из carbon-cache'а. У второго как я понимаю та же проблема + поддержка только replication factor=1, что тоже не есть прям очень здорово. И поверх любого из них нужно писать какую-то обвязку, искать способы убедиться что все корректно, доступно и так далее, что в общем уже есть для других баз данных.
P.S. И к слову, с точки зрения нагрузки на диск InfluxDB. Cassandra, KairosDB и пр. товарищи лучше, другое дело что там с масштабированием, скоростью чтения, нагрузкой на CPU и т.п. беда (у каждого что-то свое).ctrlok
08.06.2016 00:46>возможно у какой-нибудь из них получше с эффективностью, но я пока в процессе тестирования
Ну я тестировал некоторые из них, я выше писал. Они хуже. Ceres, кстати, вроде как забросили и никто его не использует. А бакитул надо допиливать, да. И я так и не понял, что вы считаете эфективнее whisper.
disk i\o в виспере (как и в любом другом решении) решается через кеш и запись больших блоков. Место на точку пусть и критично, но не так как CPU, даже если пишешь много метрик.
И полуручная работа на каждый чих — это ребалансировка каждый чих? В общем давайте по пруфам, а не по абстрактым «может что-то быть лучше, но я не проверял», так намного интереснее :)Civil
08.06.2016 01:42Ceres не полностью заброшен, но то что на 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 и еще парочку бэкэндов.
И к слову, а чем в своих тестах Вы генерировали нагрузку, если не секрет? И в целом, если можно, чуть поподробнее про методику тестирования хотелось бы услышать.ctrlok
08.06.2016 14:02>>>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, поэтому было просто). Тестил не особо точно, потому что разница часто была очень ощутима.
Civil
08.06.2016 15:45>>> Ну выставлять несколько ретеншенов это надо быть очень смелым или жестко следить за структурой метрик, потому что разные данные постагрегируются по разному, некоторые вообще нельзя постагрегировать и данные могут оказаться нерелевантными.
Ровно так и делаем. Где можно выставляем, меняем 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 и живут.
Да, в планах тоже есть желание потестировать различные варианты хранилок, но опять же в планах.
>>> Если коротко, то я генерил нагрузку самописной тулой
Понятно, ну я примерно также своими самописными тулзами делаю сейчас. А возможность прочитать эти данные потом не проверялась? На этом еще половина бэкэндов станет хуже чем виспер.ctrlok
08.06.2016 17:53проверял конечно. На infux, например, вообще метрики терялись :) И я так и не понял это было во время компакшенов или вообще когда
картинка
Civil
08.06.2016 17:57Я скорее про то, что чтение данных отсеивает все бэкэнды на базе LevelDB, RocksDB и т.п., т.к. процесс чтения тратит слишком много ресурсов.
ctrlok
07.06.2016 21:38Кстати, по автоматизации кластера графита есть популярные https://github.com/graphite-project/carbonate и менее известный, но более мощный https://github.com/jjneely/buckytools
beho1der
А есть возможность как-то выводить графики из Grafana, не только в дашборды, но и например на свой ресурс?
kovalyov_makc
Да, у Grafana есть свои API для этого, в том числе шаринг. Примерно год назад пользовался, сейчас на вскидку не вспомню. Как будет время — допишу статью на эту тему. Спасибо.
beho1der
А может есть какие ссылки внешние, чтобы почитать?
kovalyov_makc
В статье указаны ссылки на официальную документацию. В самом низу.
Официальная документация Grafana