Готовый перевод Graphite / Graphite: Configuring Carbon

Настройка Carbon
================

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

carbon.conf
----------------

Это главный конфигурационный файл, описывающий параметры каждого демона 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]``.

storage-schemas.conf
--------------------

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

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

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

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

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

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

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

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

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

.. code-block:: none

[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 дней.

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

.. code-block:: none

[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 (соотношение между детализированными и недетализированными точками) и получить почасовые продажи.

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

.. code-block:: none

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 что бы внести изменения.

Пример:

.. code-block:: none

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

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

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

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

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

relay-rules.conf
--------------------

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

Пример:

.. code-block:: none

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

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

aggregation-rules.conf
-----------------------------

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

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

.. code-block:: none

output_template (frequency) = method input_pattern

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

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

.. code-block:: none

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

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

.. code-block:: none

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

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

.. code-block:: none

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.org/book/48729/200294

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