06.06.2016 15:15
kovalyov_makc 35 10500 Источник

Хочу поделиться опытом установки и настройки сервиса для сбора и отображения метрик 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


Для проверки работоспособности 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 модно наблюдать следующее:


Так выглядит Graphite


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


Установка 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


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


Так выглядит админка Grafana


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


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


Вводим следующие данные


  • Name: graphite
  • URL: graphite.your.site

Вот пример:


Пример настройки источника данных Grafana


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


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


Выводим графики


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


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


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



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


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



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

Поделиться с друзьями
-->

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


  1. beho1der
    06.06.2016 18:35
    #9645614

    А есть возможность как-то выводить графики из Grafana, не только в дашборды, но и например на свой ресурс?


    1. kovalyov_makc
      06.06.2016 18:37
      #9645616

      Да, у Grafana есть свои API для этого, в том числе шаринг. Примерно год назад пользовался, сейчас на вскидку не вспомню. Как будет время — допишу статью на эту тему. Спасибо.


      1. beho1der
        06.06.2016 18:38
        #9645618

        А может есть какие ссылки внешние, чтобы почитать?


        1. kovalyov_makc
          06.06.2016 18:40
          #9645622

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


          Официальная документация Grafana


  1. divanikus
    06.06.2016 19:43
    #9645688

    Сам пользуюсь Graphite / Carbon для метрик и он мне дико не нравится, начиная от большой привередливости к скорости дисковой подсистемы и заканчивая колхозом в самой инфраструктуре.


    1. kovalyov_makc
      06.06.2016 19:47
      #9645694

      Как говорится, на вкус и цвет. Меня вполне устраивает. Моим запросам, и запросам начальства он соответствует. Да и выглядит, на мой взгляд, очень даже.
      Сам Graphite, конечно, выглядит не очень, но Grafana всё это дело очень хорошо спасает.


    1. thunderspb
      06.06.2016 20:05
      #9645712

      для Carbon, говорят, лучше использовать carbon-c-relay, по крайней мере на rootConf графики показывали красивые, что С-версия намнооого быстрее carbon_cache.py


      1. kovalyov_makc
        06.06.2016 20:34
        #9645738

        Спасибо, как-нибудь найду время, опробую и отпишусь.


      1. Civil
        06.06.2016 21:25
        #9645828

        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.

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


        1. divanikus
          07.06.2016 00:48
          #9645970

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


          1. Civil
            07.06.2016 00:57
            #9645972

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

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


            1. divanikus
              07.06.2016 00:58
              #9645976

              Смотрю в этом направлении, но пока руки не дошли.


  1. bers666
    06.06.2016 20:08
    #9645718

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

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


    1. kovalyov_makc
      06.06.2016 20:12
      #9645728

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


    1. Civil
      06.06.2016 21:08
      #9645800

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

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


      1. kovalyov_makc
        07.06.2016 09:14
        #9646100

        Про collectd напишу чуть позже. Настроить получилось, и довольно легко. Там уйма плагинов. И это очень хорошо.


      1. kovalyov_makc
        07.06.2016 20:30
        #9647282

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


  1. leoleovich
    06.06.2016 22:47
    #9645898
    +2

    На кой чёрт, извините, вам phpmyadmin там?


  1. 1it
    06.06.2016 23:02
    #9645914

    # 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 взялся и где его править.


    1. kovalyov_makc
      07.06.2016 09:35
      #9646146

      Спасибо за замечания. Действительно, эти строки оказались лишними. Исправил.


  1. leahch
    07.06.2016 07:55
    #9646058

    А мы пользуем связку из collectd + influxdb + grafana.


  1. valentinmk
    07.06.2016 16:54
    #9646984

    Настройки графаны для постгрес — нужно порт исправить (по-умолчанию)
    type = mysql
    host = 127.0.0.1:54323306


    1. kovalyov_makc
      07.06.2016 16:54
      #9646986

      Да, спасибо. Исправил. В оригинале была настройка на PostgerSQL.


  1. ctrlok
    07.06.2016 18:45
    #9647208

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


    1. Civil
      07.06.2016 19:12
      #9647226

      go-carbon принципиально не сильно отличается от carbon-cache. Да, он лучше с точки зрения CPU, но неэффективность whisper'а остается (как с точки зрения disk i/o и write amplification, так и с точки зрения того сколько места тратится на 1 точку). Плюс ко всему carbon в любом его виде довольно сложен в поддержке (требует много ручной или полуручной работы на каждый чих). Но да, с точки зрения скорости альтернатив zipper stack'у я не знаю.


      1. ctrlok
        07.06.2016 21:35
        #9647336

        а что эфективнее виспера для хранения метрик? Вот как раз в докладе выше есть часть бенчмарка, который я делал. И openTSDB и influx и prometheus медленнее go-carbon. Тоже самое могу сказать о cyanite с которым я знаком по проду.


        1. Civil
          07.06.2016 23:57
          #9647480

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

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

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


          1. ctrlok
            08.06.2016 00:46
            #9647510

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

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

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


            1. Civil
              08.06.2016 01:42
              #9647536

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

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


              1. ctrlok
                08.06.2016 14:02
                #9648228

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


                1. Civil
                  08.06.2016 15:45
                  #9648418

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

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

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

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

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


                  1. ctrlok
                    08.06.2016 17:53
                    #9648670

                    проверял конечно. На infux, например, вообще метрики терялись :) И я так и не понял это было во время компакшенов или вообще когда

                    картинка
                    image


                    1. Civil
                      08.06.2016 17:57
                      #9648680

                      Я скорее про то, что чтение данных отсеивает все бэкэнды на базе LevelDB, RocksDB и т.п., т.к. процесс чтения тратит слишком много ресурсов.


      1. ctrlok
        07.06.2016 21:38
        #9647340

        Кстати, по автоматизации кластера графита есть популярные https://github.com/graphite-project/carbonate и менее известный, но более мощный https://github.com/jjneely/buckytools


  1. Suvitruf
    07.06.2016 21:52
    #9647360

    Я для таких вещей контейнер делал.