Меню Рубрики

Установка graphite на debian

Установка и настройка связки 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 найдите нужный вам источник данных (с помощью двойных щелчков мыши). В результате вы увидите подобный график.

источник

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

Компании используют программные средства для сбора аналитической информации и отображения в графическом виде (таблицы, диаграммы и т. д.). Одним из представителей является система Grafana с дополнительными модулями. Расскажем на примере установки сервисов для серверных платформ под управлением ОС Debian и Ubuntu.

Предварительный этап

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

adduser graphite
usermod -aG sudo graphite

Установка производится под учетным именем graphite.

Установка

1. Установим ПО Graphite с плагинами, а также дополнительные пакеты. К ним относятся Python и Apache:

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

Читайте также:  Установка передних фар фольксваген пассат б3

Важно! Когда на экране появится сообщение о совместном удалении информации при удалении приложения Graphite, выбираем ответ No.

2. Чтобы отслеживать параметры работы, требуется специализированный сервис. В нашем случае — Carbon. Он установлен на предыдущем этапе, теперь внесем корректировки. Откроем через текстовый редактор Geany конфигурационный файл — его путь подчеркнут желтым цветом. Добавляем блок:

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

Важно! Операцию выполнять только через sudo.

Скриншот №2. Корректировка конфигурации.

Теперь хранение значений retentions в блоке collected составляет 60 секунд на протяжении семи дней.

3. Добавим в список разрешенных сервисов загрузку кэша Carbon. Вводим:

sudo vi /etc/default/graphite-carbon

Находим строку CARBON_CACHE_ENABLED и присваиваем true. Сохраняем изменения, закрываем редактор. Перезапустим сервис carbon-cache, чтобы корректировки вступили в силу.

4. Установим СУБД PostgreSQL для работы с системой мониторинга. Добавим новое учетное имя, которое получит доступ к БД Graphite:

sudo su — postgres
createuser graphite –pwprompt

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

5. Добавим пользователя к БД панели мониторинга и веб-интерфейсу:

createdb -O graphite graphite
createdb -O graphite grafana

Переключимся на пользователя и перейдем к конфигурированию Graphite.

Настройка Apache

1) Через редактор vi открываем шаблон конфигурации.

sudo vi /etc/graphite/local_settings.py

Находим раздел DATABASES. В строку USER вписываем новое учетное имя (graphite). В с троке PASSWORD указываем пароль:

Скриншот №3. Редактируем конфигурацию.

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

Поле TIME_ZONE заполняется в зависимости от региона пребывания. В нашем примере берем московское время.

2) Пробрасываем порты, чтобы получить доступ:

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

Перезапускаем службу PostgreSQL.

3) Чтобы избежать появления проблем в дальнейшем, активируем две команды.

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

4) Активируем БД с новыми параметрами:

sudo graphite-manage syncdb

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

5) Следующий шаг — конфигурирование Apache под систему мониторинга. Сначала копируем конфигурацию из директории Graphite в Apache.

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

6) Теперь внесем изменения в него, используя текстовый редактор Geany:

7) Вносим информацию в СУБД:

sudo vi /etc/apache2/ports.conf

Находим строку Listen 80 и дописываем Listen 8080. Сохраняем данные, закрываем конфигурацию.

8) Деактивируем веб-ресурс Apache, который используется по стандарту:

sudo a2dissite 000-default

После инициируем сайт системы мониторинга:

sudo a2ensite apache2-graphite

9) Перезапустим сервис СУБД, чтобы изменения применились.

Настройка Grafana

Подключаемся к Ubuntu Server, скачиваем последний релиз Grafana. На 16.08.2019 актуальна 6.3.3.

По окончанию загрузки – инсталлируем дистрибутив.

sudo apt-get install -y adduser libfontconfig
sudo dpkg -i grafana_.6.3.3_amd64.deb

Активируем службу для дальнейшей настройки утилиты под задачи через команду start.

Важно! После старта сервиса в ОС появится процесс, запущенный под именем пользователя grafana. Он появляется после установки.

1. Для начала пробрасываем порты.

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

2. Теперь изменим конфигурацию grafana.ini для совместной работы с PostgreSQL. Открываем его. Находим раздел Database, добавляем следующую информацию:

Скриншот №5. Редактируем файл Grafana.

В нашем примере поля принимают следующие значения. Type — тип базы данных (postgres), name — имя БД (grafana). Вводим данные о пользователе: user — имя (graphite), password — пароль.

Важно! На скриншоте вместо пароля указаны символы xxx.

3. Также вносим изменения в разделах server и security:

Скриншот №6. Корректируем блоки.

4. Запускаем прокси для СУБД Apache:

sudo a2enmod proxy proxy_http xml2enc

5. Сформируем шаблон, чтобы отправлять запросы через прокси в Grafana. Открываем apache2-grafana.conf через редактор vi.

Добавляем следующую информацию:

Скриншот №7. Добавление сетевых параметров.

Строку «IP-adr» меняем на цифровой адрес сервера Ubuntu, а в поле Server name можно указать не только IP, но и доменное имя.

6. Активируем параметры Grafana:

sudo a2ensite apache2-grafana

Установим время запуска службы «Панель мониторинга» после старта ОС, а потом запустим сервис через start:

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

Конфигурирование Collectd

Для начала выполним установку пакета:

sudo apt-get install collectd collectd-utils

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

1) Открываем файл collectd.conf через редактор.

Находим строку Hostname «localhost» и активируем её (удаляем закомментированные символы). Теперь находим блок Plugin write_graphite и выполняем аналогичные операции.

Как добавить графики

Последний этап — добавление графиков в панели администрирования Grafana. Открываем через браузер утилиту и авторизуемся.

Важно! IP-адрес, логин и пароль указаны в разделе «Настройка Grafana».

1. Открываем верхнее меню Data Sources, пункт Add. В первом блоке поле name — придумываем произвольное наименование (в нашем примере используется имя My), а во втором поле указываем Graphite.

2. Переходим к блоку HTTP Settings. Добавляем в поле URL адрес http://localhost:8080:

Скриншот №9. Раздел сетевых настроек.

3. Снова переходим к меню. Выбираем Dashboards, раздел New. Переключаем на режим Graph.

4. В пункте 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 и живут.

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

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

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

источник

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