Меню Рубрики

Установка и настройка graphite

Установка и настройка связки Grafana, Graphite, Carbon, Collectd на Debian и Ubuntu

В данной инструкции описан процесс установки и настройки дашборда Grafana на виртуальный сервер под управлением операционной системы Debian или Ubuntu.

Виртуальный сервер на базе Linux

Что это такое?

Graphite — это инструмент мониторинга, который хорошо зарекомендовал себя в системах с ограниченными ресурсами. Он хранит числовые данные временных рядов и предоставляет графики этих данных по запросу. Это руководство содержит введение в установку и базовую настройку Graphite вместе с популярным открытым исходным кодом Grafana для визуализации крупномасштабных данных измерений на Ubuntu.

Collectd — собирает метрики о вашей системе.

Первоначальные требования

Все действия в данной инструкции выполняются от имени пользователя graphite с правами суперпользователя.

Для настройки и корректной работы дашборда необходимо создать нового пользователя с именем graphite:

Добавим созданного пользователя в группу sudo:

Установка Apache, Python Tools и Graphite

Установите системные пакеты, необходимые для работы с Graphite:

sudo apt-get install build-essential graphite-web graphite-carbon python-dev apache2 libapache2-mod-wsgi libpq-dev python-psycopg2

Во время установки graphite-carbon вас спросят, хотите ли вы удалить файлы базы данных whisper, при удалении Graphite со своего сервера. Ответьте No на этот вопрос. Вы всегда можете удалить файлы позже (они находятся в /var/lib/graphite/whisper).

Настройка Carbon

Для работы с метриками необходимо настроить специальный блок с глубиной их хранения в конфигурационном файле Carbon storage-schemas.conf. С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/carbon/storage-schemas.conf

Добавьте следующие строки:

[collectd]
priority = 100
pattern =^collectd\.*
retentions = 60s:7d,10m:2y

В блоке collectd время хранения retentions будет сохранять данные каждые 60 секунд в течение 7 дней и отдельный набор данных из этого агрегированного образца каждые 10 минут в течение 2 лет.

Примечание: дополнительные сведения о настройке хранилища Carbon смотрите в разделе storage-schemas.conf в документации Graphite.

Разрешите запускать при загрузке кеш Carbon. С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/default/graphite-carbon

Измените значение следующего параметра на TRUE:

Запустите сервис carbon-cache:

sudo service carbon-cache start

Установка и настройка PostgreSQL

Установите PostgreSQL для веб-приложения Graphite:

sudo apt-get install postgresql

Перейдите к пользователю postgres и создайте пользователя базы данных для Graphite:

sudo su — postgres
createuser graphite —pwprompt

Далее вам будет необходимо указать пароль для нового пользователя базы данных. После этого создайте базы данных graphite и grafana для пользователя graphite:

createdb -O graphite graphite
createdb -O graphite grafana

Закончив настройку баз данных PostgreSQL, вернитесь к пользователю graphite:

Настройка Graphite

Откройте файл для редактирования:

sudo vi /etc/graphite/local_settings.py

Найдите определение DATABASES и внесите следующие значения, указав пароль вашего пользователя:

DATABASES = <
‘default’: <
‘NAME’: ‘graphite’,
‘ENGINE’: ‘django.db.backends.postgresql_psycopg2’,
‘USER’: ‘graphite’,
‘PASSWORD’: ‘пароль’,
‘HOST’: ‘127.0.0.1’,
‘PORT’: »
>
>

Также добавьте следующие строки в конец файла:

TIME_ZONE = ‘Europe/Moscow’
SECRET_KEY = ‘somelonganduniquesecretstring’

Примечания:
TIME_ZONE — если ваша временная зона отличается, то вы можете узнать ее с помощью следующей команды: timedatectl;
SECRET_KEY — длинная и уникальная строка, используемая при хешировании паролей.

Для открытия порта выполните следующую команду:

sudo iptables -A INPUT -p tcp —dport 5432 -j ACCEPT
sudo iptables-save

sudo service postgresql restart

Так же выполните следующие 2 команды для избежания ошибок:

python /usr/lib/python2.7/dist-packages/graphite/manage.py migrate auth
python /usr/lib/python2.7/dist-packages/graphite/manage.py migrate

Выполним инициализацию баз данных:

sudo graphite-manage syncdb

На этом шаге может потребоваться ввести информацию о пользователе Django.

Настройка Apache

Скопируйте шаблон конфигурации Apache для Graphite в доступный каталог Apache:

sudo cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available

С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/apache2/sites-available/apache2-graphite.conf

Измените порт Graphite c 80 на 8080 (порт 80 будет использоваться для Grafana):

Убедитесь, что Apache прослушивает порт 8080. С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/apache2/ports.conf

Добавьте “Listen 8080” после строки “Listen 80” в открытый файл: Listen 80
Listen 8080

Сохраните изменения и закройте файл.

Отключите сайт Apache по умолчанию, чтобы избежать конфликты:

sudo a2dissite 000-default

Включите виртуальный сайт Graphite:

sudo a2ensite apache2-graphite

Перезагрузите Apache, чтобы применить изменения:

sudo service apache2 reload

Установка и настройка Grafana

На момент написания инструкции последняя стабильная версия Grafana 4.6.3. Подключитесь к виртуальному серверу и для установки выполните следующие команды:

wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.6.3_amd64.deb
sudo apt-get install -y adduser libfontconfig
sudo dpkg -i grafana_4.6.3_amd64.deb

Запустите Grafana с помощью следующей команды:

sudo service grafana-server start

В результате в системе появится процесс grafana-server принадлежащий пользователю grafana, который был создан во время установки пакета.

Для открытия порта выполните следующую команду:

sudo iptables -A INPUT -p tcp —dport 80 -j ACCEPT
sudo iptables-save

Настройте Grafana для использования базы данных PostgreSQL, созданной ранее.

С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/grafana/grafana.ini

В блоке [database] укажите тип базы данных, имя базы данных, пользователя graphite и его пароль:

[database]
type = postgres
host = 127.0.0.1:5432
name = grafana
user = graphite
password =

В блоке [server] укажите следующие значения:

[server]
protocol = http
http_addr = 127.0.0.1
http_port = 3000
domain = localhost
enforce_domain = true
root_url = %(protocol)s://%(domain)s/

В блоке [admin] укажите логин администратора и пароль:

[security]
admin_user = admin
admin_password =
secret_key = somelongrandomstringkey

Включить прокси-модули для работы Apache:

sudo a2enmod proxy proxy_http xml2enc

Создайте файл конфигурации сайта Apache для прокси-запросов в Grafana:

sudo vi /etc/apache2/sites-available/apache2-grafana.conf

Вставьте следующие строки. Не забудьте указать ваш внешний ip-адрес или домен:

ProxyPreserveHost On
ProxyPass / http:// :3000/
ProxyPassReverse / http:// :3000/
ServerName

Включите конфигурацию сайта Grafana:

sudo a2ensite apache2-grafana

Настройте Grafana для запуска после загрузки, а затем запустите службу:

sudo update-rc.d grafana-server defaults 95 10
sudo service grafana-server start

Перезапустите Apache для загрузки новых модулей и изменений конфигурации:

sudo service apache2 restart

Теперь вы можете открыть веб-приложение Grafana в браузере по адресу:

Установка и настройка Collectd

Для установки collectd выполните следующую команду:

sudo apt-get install collectd collectd-utils

После установки остановите сервис:

sudo service collectd stop

Внесем изменения в конфигурационный файл collectd. С помощью текстового редактора, например vi, откройте файл для редактирования:

sudo vi /etc/collectd/collectd.conf

Раскомментируйте в файле следующее значение:

Также необходимо раскоментировать следующий модуль:

sudo service collectd restart

Читайте также:  Установка защиты картера опель мокка

Добавление графиков в веб-интерфейсе

Откройте веб-приложение Grafana в браузере по адресу:

Войдите в Grafana, используя учетные данные администратора, указанные вами в grafana.ini выше.

В вертикальном меню Grafana выберете Data Sources. В открывшемся окне нажмите на кнопку Add data sources.

В поле Name введите любое удобное для вас название, в качестве Type выберете Graphite. В поле URL вставьте строку следующего формата: http://localhost:8080

Далее в вертикальном меню выберете Dashboards->New. В новом окне выберете Graph. Наведите на название графика и нажмите кнопку Edit. В разделе Metrics найдите нужный вам источник данных (с помощью двойных щелчков мыши). В результате вы увидите подобный график.

источник

Установка связки Carbon + Graphite + Grafana + Nginx + MySQL для сбора и отображения метрик в Ubuntu

Хочу поделиться опытом установки и настройки сервиса для сбора и отображения метрик Graphite + Grafana .
Искал долго, читал много, нашёл 2 статьи на английском, добавил своё, в итоге получилась данная статья.

Graphite — система для отображения метрик (числовых значений) для любых свойств сервера или домашнего ПК.

Carbon — демон/бэкенд, в который пишутся метрики.

Grafana — более красивая и удобная Web-морда для Graphite .

Установка и настройка Php + Nginx + MySQL

Установка Php + Nginx + MySQL

Во время установки будет запрос пароля для root -пользователя MySQL .

Установка phpMyAdmin

Для более удобного доступа у базам данных MySQL установим phpMyAdmin .

Скачиваем отсюда последнюю версию

Настраиваем Nginx для phpMyAdmin

В файл настроек /etc/nginx/conf.d/pma.conf пишем следующее:

Предварительные настройки MySQL

Заходим по адресу pma.your.site , который Вы прописали в настройках выше, авторизируемся под root пользователем с тем паролем, который Вы установили во время установки MySQL .

Создадим базу данных graphite и пользователя graphite , и дадим этому пользователю все привилегии на эту базу.

Установка и настройка Graphite + Carbon

Установка Graphite + Carbon

Тут тоже всё довольно просто:

Настройка Graphite

Редактируем файл конфигурации /etc/graphite/local_settings.py .

Синхронизация базу данных

Синхронизируем базу данных следующей командой

Настройка Carbon

Редактируем следующие файлы конфигурации

Копируем стандартные настройки агрегации хранилища

Установка uWSGI

Для установки uWSGI запустите следующие команды

Если в Вашей системе не установлен pip — устанавливаем его

Копируем стандартный файл конфигурации

Создаём файл конфигурации:

И вписываем туда следующие строки:

Настройка Nginx для Graphite

Редактируем файл конфигурации /etc/nginx/conf.d/graphite.conf

Перезапускаем Nginx и переходим по адресу graphite.your.site

Тестирование Graphite

Для проверки работоспособности Graphite достаточно выполнить одну простую команду:

Теперь в Graphite модно наблюдать следующее:

Установка и настройка красивой Web-морды Grafana

Установка Grafana

Для установки Grafana выполняем следующие команды:

Настройка MySQL для Grafana

Создадим в MySQL базу данных grafana и дадим все привилегии на неё пользователю graphite , которого мы создали ранее.

Редактируем файл конфигурации /etc/grafana/grafana.ini

Настройка Nginx для Grafana

Редактируем файл конфигурации /etc/nginx/conf.d/grafana.conf

Перезапускаем Nginx и переходим по адресу grafana.your.site

Вводим логин/пароль администратора, которые Вы установили выше, и попадаем в админ-панель Grafana .

Перед тем, как создавать дашборды и выводить метрики, нужно настроить источники данных.

Переходим в раздел Data Source -> Add New

Теперь переходим на главную страницу, жмём New Dashboard -> New ,
Слева будет малозаметная зелёная кнопка, при наведении на которую она выползет из-за края экрана. Нажимаем на неё и затем Add Panel -> Graph

Внизу Вы увиlите метрики, которые мы создавали тестовой командой выше, test и count .

На этом пока что всё, позже я расcкажу о плагинах для Grafana .

Больше информации

Пожалуйста, проследуйте по приведенным ниже ссылкам, чтобы узнать больше о Grafana и его удивительных настройках.

Благодарность

За основу статьи были взяты материалы следующих статей:

Оригинал статьи опубликован на моём блоге

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Собственное корпоративное облако ownCloud с NGINX во frontend и несколькими серверами backend

MySQL в NGINX: использование блокирующих библиотек в неблокирующем сервере

Сервер на стероидах: FreeBSD, nginx, MySQL, PostgreSQL, PHP и многое другое

Заказы

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 35

В статье указаны ссылки на официальную документацию. В самом низу.

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.

Но в целом адекватных альтернатив пока что не видно, протокол графита очень много кто умеет и при желании можно получить очень неплохую производительность на чтение и запись.

Да, whisper на не-SSD нагрузку держит плохо и попытки заставить его нормально работу выливаются в ram-диск или долгий и упорный тюнинг кэшей.

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

И что? а где эти самые графики для cpu,mem,load,df,disk,network (плюс интеграл скорости по времени в виде потребленного трафика) и так далее? Неужели самому рисовать эти метрики?

Читайте также:  Установка в газель узета

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

Есть метрики по умолчанию, они записаны в разделе carbon .
Вот пример:

collectd умеет отправлять данные в graphite.

Еще можно посмотреть на diamond из популярного.

Вот и статья про collectd + Graphite.

# 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:

Хотя, как по мне, проще файлик подложить в нужное место, чем потом вспонимать откуда этот robots.txt взялся и где его править.

Напишу, что б пошире: сейчас графит в первозданном виде используют в основном только мамонты. Есть вполне приличный 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

На самом деле ceres немного получше, но реально работает только как single server решение (т.к. никто не делал поддержку оного в carbonserver). На самом деле за последние пару лет появилась пачка различных баз данных, возможно у какой-нибудь из них получше с эффективностью, но я пока в процессе тестирования.

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

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

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

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

И полуручная работа на каждый чих — это ребалансировка каждый чих? В общем давайте по пруфам, а не по абстрактым «может что-то быть лучше, но я не проверял», так намного интереснее 🙂

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 и еще парочку бэкэндов.

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

>>>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, поэтому было просто). Тестил не особо точно, потому что разница часто была очень ощутима.

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

Ровно так и делаем. Где можно выставляем, меняем 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 и живут.

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

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

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

источник

Добавить комментарий