Настройка Carbon

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

pushd /opt/graphite/conf
cp carbon.conf.example carbon.conf
cp storage-schemas.conf.example storage-schemas.conf

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

carbon.conf

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

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

storage-schemas.conf

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

Важные замечания перед продолжением:

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

Заданное правило состоит из 3 строк:

• Имя, указанное в квадратных скобках.
• Регулярное выражение, указанное после «pattern =»
• Строка параметров сохранения, указанная после «retentions =»

В строке сохранения можно указать несколько параметров сохранения. Каждое сохранение frequency:history разделяется запятой.

Частоты и периоды хранения указываются с помощью следующих суффиксов:

• s — секунда
• m — минута
• h — час
• d — день
• w — неделя
• 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 — нет.

Строка retentions означает, что каждый момент данных представляет 10 секунд, и мы хотим сохранить достаточно данных, чтобы они суммировались до 14 дней данных.

Вот более сложный пример с несколькими параметрами сохранения:

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

В этом примере представьте, что ваша схема метрик — servers.<servername>.<metrics>. Шаблон будет соответствовать именам серверов, начинающимся с «www», за которыми следует что-либо, отправляющим метрики, которые заканчиваются на ‘.workers.busyWorkers’ (обратите внимание на экранированные символы ‘.’).

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

Использование нескольких параметров сохранения позволяет хранить длинные истории метрик, экономя место на диске и I/O. Поскольку whisper усредняет (по умолчанию) при уменьшении, можно определить общие значения метрик, обратившись к процессу усреднения в будущем.

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

Кроме того, whisper поддерживает спецификацию сохранения старого формата по причинам обратной совместимости — seconds-per-datapoint:count-of-datapoints

retentions = 60:1440

60 представляет количество секунд на момент данных, а 1440 — количество моментов данных для хранения. Это требовало некоторых излишне сложных математических вычислений, поэтому, хотя оно допустимо, оно не рекомендуется.

storage-aggregation.conf

Этот файл определяет, как агрегировать данные с сохранением с более низкой точностью. Формат аналогичен storage-schemas.conf. Важные замечания перед продолжением:

• Этот файл необязателен. Если он отсутствует, будут использованы значения по умолчанию.
• Разделы применяются в порядке от верхнего (первого) к нижнему (последнему), аналогично storage-schemas.conf.
• Используется первый шаблон, который соответствует имени метрики, аналогично storage-schemas.conf.
• Нет строки retentions. Вместо этого есть строки xFilesFactor и/или aggregationMethod.
• xFilesFactor должно быть числом с плавающей точкой от 0 до 1 и указывает, какая доля слотов предыдущего уровня сохранения должна иметь значения, отличные от null, для агрегирования в значение, отличное от null. Значение по умолчанию — 0.5.
• aggregationMethod указывает функцию, используемую для агрегирования значений для следующего уровня сохранения. Допустимые методы: average, sum, min, max, и last. Значение по умолчанию — average.
• Эти значения устанавливаются в момент отправки первой метрики.
• Изменение этого файла не повлияет на файлы .wsp, которые уже созданы на диске. Используйте whisper-set-aggregation-method.py для изменения этих файлов.

Вот пример:

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

Вышеуказанный шаблон будет соответствовать любой метрике, которая заканчивается на .min.

Строка xFilesFactor означает, что для следующего уровня сохранения необходимо, чтобы как минимум 10% слотов на предыдущем уровне сохранения имели значения. Строка aggregationMethod означает, что функция агрегирования должна быть min.

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

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

Если вы хотите изменить методы агрегирования для существующих данных, убедитесь, что вы также обновили файлы whisper.

Пример:

/opt/graphite/bin/whisper-set-aggregation-method.py /opt/graphite/storage/whisper/test.wsp max

В этом примере устанавливается агрегирование для test.wsp в max. (Расположение скрипта python зависит от вашей установки)

relay-rules.conf

Правила реле используются для отправки определенных метрик на определенный бэкенд. Это обрабатывается системой carbon-relay. Для работы реле она должна быть запущена. Вы можете использовать регулярное выражение для выбора метрик и определения серверов, на которые они должны быть отправлены, с помощью строки servers.

Пример:

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

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

aggregation-rules.conf

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

Формат каждой строки в этом файле должен быть следующим:

output_template (frequency) = method input_pattern

Это захватывает любые полученные метрики, которые соответствуют input_pattern, для расчета агрегированной метрики. Вычисление происходит каждые frequency секунд с помощью допустимого method. Название агрегированной метрики будет получено из output_template, заполнив любые захваченные поля из input_pattern. Любая метрика, которая поступит в carbon-aggregator, будет проходить на вывод без изменений, если это не будет переопределено каким-либо правилом.

Доступные методы агрегирования: sum, avg, min, max, p50, p75, p80, p90, p95, p99, p999, и count — где p50 означает 50-й перцентиль, а p999 означает 99,9-й перцентиль и т. д.

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

Например, если ваша схема именования метрик:

<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 путем суммирования их значений.

Компоненты шаблонов, такие как <env>, будут соответствовать всему до следующей точки. Чтобы соответствовать метрике нескольким компонентам, включая точки, используйте <<метрика>> в шаблоне ввода:

<env>.applications.<app>.all.<app_metric> (60) = sum <env>.applications.<app>.*.<<app_metric>>

Также возможно использование регулярных выражений. Следуя приведенному выше примеру, при использовании:

<env>.applications.<app>.<domain>.requests (60) = sum <env>.applications.<app>.<domain>\d{2}.requests

Вы получите prod.applications.apache.www.requests вместо prod.applications.apache.all.requests.

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

rewrite-rules.conf

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

Формат каждой строки в этом файле должен быть следующим:

regex-pattern = replacement-text

Это захватывает любые полученные метрики, которые соответствуют ‘regex-pattern’, и переписывает соответствующую часть текста с помощью ‘replacement-text’. ‘regex-pattern’ должно быть допустимым регулярным выражением Python, а ‘replacement-text’ может быть любым значением. Вы также можете использовать группы захвата:

^collectd\.([a-z0-9]+)\. = \1.system.

Что приведет к:

collectd.prod.cpu-0.idle-time => prod.system.cpu-0.idle-item

rewrite-rules.conf состоит из двух разделов, [pre] и [post]. Правила в разделе pre применяются к именам метрик сразу после их получения. Правила в разделе post применяются после агрегирования.

Например:

[post]
_sum$ =
_avg$ =

Эти правила удалят суффикс _sum или _avg из имен метрик после агрегирования.

Примечание: если вы планируете использовать символ = в своих правилах переписывания. Используйте его восьмеричное значение: \075. Например, foo=bar = foo.bar будет соответствовать foo\075bar = foo.bar

список разрешенных и запрещенных значений

Функциональность белого списка позволяет любым демонам carbon принимать только те метрики, которые явно включены в белый список и/или отклонять метрики из чёрного списка. Функциональность может быть включена в carbon.conf с флагом USE_WHITELIST. Это может быть полезно, когда слишком много метрик отправляется в экземпляр Graphite или когда существуют отправители метрик, отправляющие бесполезные или недопустимые метрики.

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