Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

Настройка Carbon

Файлы настроек Carbon живут в /opt/graphite/conf/. При первоначальной настройке файлы отсутствуют, но для каждого будет .conf.example. Просто скопируйте файлы с примерами, предварительно удалив расширение .example и внеся измененя.

carbon.conf

Это главный конфигурационный файл, описывающий параметры каждого демона Carbon.

Каждный параметр в этом файле имеет описание в виде комментариев Параметры разбиты на группы для каждого демона - за настройку carbone-cache отвечает секция [cache], за carbon-relay - [relay], а carbon-aggregator - [aggregator]. При первоначально настройке вам пока понадобится только секция [cache].

Допускается запуск carbon-cache и carbon-relay на одной машине. Вы можете поменять местами номера портов LINE_RECEIVER_PORT` и PICKLE_RECEIVER_PORT в секциях [cache] и [relay] соответственно, что бы избежать перенастройки агентов. Задавая параметр DESTINATIONS секции [relay] следует учитывать какое значение было присвоено параметру PICKLE_RECEIVER_PORT секции [cache].

storage-schemas.conf

Данный конфигурационный файл управляет коэффициентами детализации метрик. В нем задается соответствие шаблонов метрик частоте и длительности хранения точек, с которыми будет работать whisper.

Важные замечания

  • В файле могут быть несколько секций.
  • Параметры секций применяют сверхку (с первого) вниз (до последнего).
  • Шаблоны представляют из себя регулярные выражения, в отличии от символов замены в URL API.
  • Первый шаблон соответствует имени метрики.
  • Детализация задается при первой передаче метрики.
  • Изменение этого файла не повлияет на уже записанные даныне в .wsp файлах. Используйте whisper-resize.py что бы внести изменения.

Правило задается тремя строками:

  • имя, задается внутри квадратных скобок;
  • регулярное выражение - после "pattern=";
  • строка коэффициента детализации - после "retentions=".

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

Частоты и сроки хранения могут включать суффиксы:

  • s - сукенда,
  • m - минута,
  • h - час,
  • d - день,
  • y - год.

Ниже представлен простой пример настройки детализации:

[garbage_collection]
pattern = garbageCollections$
retentions = 10s:14d

Имя [garbage_collection] служит в основном для аудита и будет отражено в creates.log при создании заданной метрики.

Регулярное выражение соответствует метрике заканчивающейся на garbageCollections. Например com.acmeCorp.instance01.jvm.memory.garbageCollections сработает, а com.acmeCorp.instance01.jvm.memory.garbageCollections.full нет.

Строка задает соответствие каждой точки 10 секундам и сроку хранения точек а течение 14 дней.

Вот пример более сложной настройки детализации.

[apache_busyWorkers]
pattern = ^servers\.www.*\.workers\.busyWorkers$
retentions = 15s:7d,1m:21d,15m:5y

Допустим схема именования метрик задана как servers.<servername>.<metrics>. Этот шаблон будет соответствовать серверам с именами начинающимися с 'www', а метрикам завершающимися на '.workers.busyWorkers' (обратите внимание на '' перед символами '.')

Кроме того, пример содержит несколько уровней детализации. Основное правило - выражения должны задаваться от самых свежих к самым старым, whisper будет тщательно сэмплировать метрики (По имолчанию усредняя) по достижении заданной границы.

Задавая несколько уровней детализации, вы сможете хранить данных за длительный период, экономя на дисковом пространстве и операциях ввода-вывода. Так как whisper усредняет (по-умолчанию) во время семплирования, он получает возможность рассчитывать суммарные значения, выполняя обратный процесс в будущем.

Пример: Вы храните поминутные данные о продажах за год и почасовые за 5 лет. Вам нужно вычислить продажи за 1-е Января прошлого года. Можно получить 24 точки за каждый час, запросить сырые данные. Вероятно это будут числа с плавающей точкой. Вы можете умножить каждое значение на 60 (соотношение между детализированными и недетализированными точками) и получить почасовые продажи.

Помимо описанного виже, в целях сохранения обратной совместимости поддерживается еще устаревший формат - секунд на точку:количество точек

retentions = 60:1440

60 - количество секунд на точку, 1440 - количество хранимых точек. Для работы с этим форматом требуются избыточные и запутанные математические операции, что позволит получить аналогичный результат. Однако, мы не рекомендуем пользоваться этим мехаинизмом.

storage-aggregation.conf

Данный файл содержит правила агрегации данные для уменьшения детализации. Формат идентичен storage-schemas.conf. Важные заменания:

  • Данный файл опционален. При его отсутствии будут использованы значения по-умолчанию.
  • Здесь нет сроки retentions, вместо нее используются xFilesFactor и aggregationMethod.
  • xFilesFactor - число с плавающей точкой в диапазоне от 0 до 1, задающее долю от предыдущего значения, которую должно иметь следующее отсутствующее значение. По-умолчанию 0.5.
  • aggregationMethod задает метод агрегации значений для достижения следующего уровеня точности. Допустимые методы average, sum, min, max, and last. По-умолчанию average.
  • Значения применяют при первой передаче метрики.
  • Изменение этого файла не повлияет уже записанные даныне в .wsp файлах. Используйте whisper-set-aggregation-method.py что бы внести изменения.

Пример:

[all_min]
pattern = \.min$
xFilesFactor = 0.1
aggregationMethod = min

Шаблон сработает для любой метрики заканчивающейся символами .min.

xFilesFactor задает минимум 10% слотов предыдущего уровня точности для вычисления средних значений следующего уровня. aggregationMethod задает использование минимального значения для аггрегации.

Отсутствие значение xFilesFactor и aggregationMethod приведет к поведению предусмотренному по умолчанию.

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

relay-rules.conf

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

Пример:

[example]
pattern = ^mydata\.foo\..+
servers = 10.1.2.3, 10.1.2.4:2004, myserver.mydomain.com

Необходмо задать минимум одну строку в качестве парамера по-умолчанию.

aggregation-rules.conf

Правила аггрегации позволяют группировать метрики по мере их поступления, убирая потребность в sum() в каждой URL. Обратите внимание, что в отличии от предыдущих файлов изменения внесенные в этот файла вступят в силу автоматически. Для обеспечения необходимо запустить сервис carbon-aggregator.

Каждая строка задается следующим образом:

output_template (frequency) = method input_pattern

Будут аггрегированны все метрики соответствующие input_pattern. Аггрегация будет выполняться через каждые 'frequency' секунд. 'method' может быть 'sum' или 'avg'. Имя агрегированной метрики будет производным имени исходной метрки и задается в 'output_template' по средством вычленения значений из 'input_pattern'. Каждая метрика попавшая в carbon-aggregator останется неизменной если только не будет переопределена специальным правилом.

Например, если задана следующая схема именования метрик:

<env>.applications.<app>.<server>.<metric>

Можно задать некоторую аггрегацию следующим образом:

<env>.applications.<app>.all.requests (60) = sum <env>.applications.<app>.*.requests
<env>.applications.<app>.all.latency (60) = avg <env>.applications.<app>.*.latency

А при получении следующих метрик:

prod.applications.apache.www01.requests
prod.applications.apache.www02.requests
prod.applications.apache.www03.requests
prod.applications.apache.www04.requests
prod.applications.apache.www05.requests

Они попадут в соответствующий буфер а по прошествии 60 секунд, метрика 'prod.applications.apache.all.requests' будет рассчитана как сумма этих значений.

Другой частый подход в использовании carbon-aggregator - аггрегация нескольких точки в одну метрику. Может быть удобно при получении одинаковых метрик с нескольких хостов, или нужно получать данные чаще чем задано наиболее детальным правилом точности.

Черо-белые списки

Черно-белые списки позволяют carbon принимать только заданные в белом списке или игнорировать заданные в черном. Функционал включается флагом USE_WHITELIST в carbon.conf. Может быть полезно для управления потоком избыточных или некорректных данных.

GRAPHITE_CONF_DIR будет проверен на наличие whitelist.conf и blacklist.conf. Каждый файл должен содержать по одному регулярному выражению на строку. Если списки пусты то все метрики будут приниматься по-умолчанию.

Внимание! Этот перевод, возможно, ещё не готов. Его статус: перевод редактируется

Переведено на Нотабеноиде http://notabenoid.com/book/48729/200294

Переводчики: nipman

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.