Файлы настроек Carbon живут в /opt/graphite/conf/. При первоначальной настройке файлы отсутствуют, но для каждого будет .conf.example. Просто скопируйте файлы с примерами, предварительно удалив расширение .example и внеся измененя.
Это главный конфигурационный файл, описывающий параметры каждого демона Carbon.
Каждный параметр в этом файле имеет описание в виде комментариев Параметры разбиты на группы для каждого демона - за настройку carbone-cache отвечает секция [cache], за carbon-relay - [relay], а carbon-aggregator - [aggregator]. При первоначально настройке вам пока понадобится только секция [cache].
Tip
Допускается запуск carbon-cache и carbon-relay на одной машине. Вы можете поменять местами номера портов LINE_RECEIVER_PORT и PICKLE_RECEIVER_PORT в секциях [cache] и [relay] соответственно, что бы избежать перенастройки агентов. Задавая параметр DESTINATIONS секции [relay] следует учитывать какое значение было присвоено параметру PICKLE_RECEIVER_PORT секции [cache]`.
Данный конфигурационный файл управляет коэффициентами детализации метрик. В нем задается соответствие шаблонов метрик частоте и длительности хранения точек, с которыми будет работать 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:144060 - количество секунд на точку, 1440 - количество хранимых точек. Для работы с этим форматом требуются избыточные и запутанные математические операции, что позволит получить аналогичный результат. Однако, мы не рекомендуем пользоваться этим мехаинизмом.
Данный файл содержит правила агрегации данные для уменьшения детализации. Формат идентичен storage-schemas.conf. Важные заменания:
- Данный файл опционален. При его отсутствии будут использованы значения по-умолчанию.
- Здесь нет сроки
retentions, вместо нее используютсяxFilesFactorиaggregationMethod. xFilesFactor- число с плавающей точкой в диапазоне от 0 до 1, задающее долю от предыдущего значения, которую должно иметь следующее отсутствующее значение. По-умолчанию 0.5.aggregationMethodзадает метод агрегации значений для достижения следующего уровеня точности. Допустимые методыaverage,sum,min,max, andlast. По-умолчаниюaverage.- Значения применяют при первой передаче метрики.
- Изменение этого файла не повлияет уже записанные даныне в .wsp файлах. Используйте whisper-set-aggregation-method.py что бы внести изменения.
Пример:
[all_min]
pattern = \.min$
xFilesFactor = 0.1
aggregationMethod = minШаблон сработает для любой метрики заканчивающейся символами .min.
xFilesFactor задает минимум 10% слотов предыдущего уровня точности для вычисления средних значений следующего уровня. aggregationMethod задает использование минимального значения для аггрегации.
Отсутствие значение xFilesFactor и aggregationMethod приведет к поведению предусмотренному по умолчанию.
Параметры аггрегации задаются отдельно от параметров точности, потому как первые зависят от типа сбора данных, а вторые от объема и приоритета.
Правила рэлеев используются для управлением передачей определенных метрик заданным бэкэндам. Их необходимо задать для работы релеев. Допустимо использование регулярных выражений для определения соответсвтия метрик и серверов.
Пример:
[example]
pattern = ^mydata\.foo\..+
servers = 10.1.2.3, 10.1.2.4:2004, myserver.mydomain.comНеобходмо задать минимум одну строку в качестве парамера по-умолчанию.
Правила аггрегации позволяют группировать метрики по мере их поступления, убирая потребность в 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