Ввод данных

Получение данных в Graphite очень гибко. Существует три основных метода отправки данных в Graphite: текстовый, Pickle и AMQP.

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

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

• Существуют некоторые инструменты и API, которые могут помочь вам получить ваши данные в Carbon.
• Для отдельного скрипта или тестовых данных текстовый протокол является наиболее простым методом.
• Для отправки больших объемов данных вам необходимо объединить эти данные и отправить их в приемник Pickle Carbon.
• Наконец, Carbon может прослушивать шину сообщений через AMQP.

Существующие инструменты и API

• Клиентские демоны и инструменты
• Клиентские API

Текстовый протокол

Текстовый протокол — это наиболее простой протокол, поддерживаемый Carbon.

Отправляемые данные должны иметь следующий формат: <metric path> <metric value> <metric timestamp>. Carbon затем поможет преобразовать эту строку текста в метрику, которую понимают веб-интерфейс и Whisper.

В Unix программе nc (netcat) можно использовать для создания сокета и отправки данных в Carbon (по умолчанию 'текстовый' работает на порту 2003):

PORT=2003
SERVER=graphite.your.org
echo "local.random.diceroll 4 `date +%s`" | nc ${SERVER} ${PORT}

Поскольку существует множество реализаций netcat, может потребоваться параметр для указания nc закрыть сокет после отправки данных. Такой параметр обычно будет -q0, -c или -N. Обратитесь к руководству вашей реализации nc для определения этого параметра.

Обратите внимание, что если ваш экземпляр Carbon прослушивает с помощью протокола UDP, вам также понадобится параметр -u.

Протокол Pickle

Протокол Pickle — это гораздо более эффективный подход к текстовому протоколу, который поддерживает отправку наборов метрик в Carbon за один раз.

Общая идея заключается в том, что данные Pickle образуют список многоуровневых кортежей:

[(path, (timestamp, value)), ...]

После формирования списка достаточного размера (не делайте его слишком большим!) и его сериализации (если ваш клиент работает с более новой версией Python, чем ваш сервер, вам может потребоваться указать протокол), отправьте данные через сокет в приемник Pickle Carbon (по умолчанию порт 2004). Вам нужно будет упаковать свои сериализованные данные в пакет, содержащий простой заголовок:

payload = pickle.dumps(listOfMetricTuples, protocol=2)
header = struct.pack("!L", len(payload))
message = header + payload

Затем вы отправите объект message через сетевой сокет.

Использование AMQP

Когда AMQP_METRIC_NAME_IN_BODY установлено в значение True в файле carbon.conf, данные должны иметь тот же формат, что и текстовый протокол, например, echo “local.random.diceroll 4 date +%s”. Когда AMQP_METRIC_NAME_IN_BODY установлено в значение False, вы должны опустить ‘local.random.diceroll’.

Получение данных в Graphite

Основная идея

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

Шаг 1 — Планирование иерархии имён

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

В традиционной иерархии website.orbitz.bookings.air или что-то подобное будет представлять количество бронирований авиабилетов на orbitz. Перед созданием данных вам необходимо определить вашу схему именования. В пути, таком как “foo.bar.baz”, каждый элемент, окруженный точками, называется компонентом пути. Таким образом, “foo” — это компонент пути, как и “bar”, и т. д.

Каждый компонент пути должен иметь четкую и хорошо определенную цель. Изменчивые компоненты пути следует хранить как можно глубже в иерархии.

У Мэтта Аймонетти есть достаточно разумная статья, описывающая организацию вашего пространства имен.

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

Для решения этих проблем Graphite также поддерживает использование тегов для описания ваших метрик, что значительно упрощает разработку начальной структуры и ее развитие с течением времени. Ряд с тегами состоит из имени и набора тегов, например, “disk.used;datacenter=dc1;rack=a1;server=web01”. В этом примере имя ряда — “disk.used”, а теги — “datacenter” = “dc1”, “rack” = “a1” и “server” = “web01”. Когда ряды именованны таким образом, их можно выбрать с помощью функции seriesByTag, как описано в Поддержка тегов Graphite.

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

Шаг 2 — Настройка сохранения данных

Graphite построен на базе баз данных с фиксированным размером (см. Whisper.), поэтому нам необходимо заранее настроить объем хранимых данных и точность измерения. Например, вы можете хранить данные с точностью в 1 минуту (то есть, вы будете иметь одну точку данных для каждой минуты) в течение, скажем, 2 часов. Кроме того, вы можете хранить данные с точностью в 10 минут в течение 2 недель и т. д. Идея заключается в том, что стоимость хранения определяется количеством точек данных, которые вы хотите сохранить, чем меньше точность, тем больше времени вы можете покрыть меньшим количеством точек.

Для определения наилучшей конфигурации хранения данных необходимо ответить на все следующие вопросы:

1. Насколько часто вы можете производить ваши данные?
2. Какова наименьшая точность, которая вам потребуется?
3. Насколько назад вам нужно будет посмотреть на эту точность?
4. Какова наибольшая точность, которую вы можете использовать?
5. Насколько далеко назад вам нужно будет увидеть данные? (да, это должно быть конечное число и определено заранее)

После выбора схемы именования и ответа на все вопросы о сохранении данных необходимо создать схему, создав/отредактировав файл /opt/graphite/conf/storage-schemas.conf.

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

servers.HOSTNAME.METRIC

Где HOSTNAME будет именем хоста сервера, а METRIC — чем-то вроде cpu_load, mem_usage, open_files и т. д. Также предположим, что мы хотим хранить эти данные с минутной точностью в течение 30 дней, а затем с точностью в 15 минут в течение 10 лет.

Подробности реализации вашей схемы см. в документе Настройка Carbon.

В общем случае, когда Carbon получает метрику, он определяет, где на файловой системе должен находиться файл данных Whisper для этой метрики. Если файла данных не существует, Carbon знает, что должен создать его, но поскольку Whisper — это база данных с фиксированным размером, некоторые параметры должны быть определены во время создания файла (поэтому мы создаём схему). Carbon просматривает файл schemas, и в порядке приоритета (от самого высокого к самому низкому) ищет первую схему, шаблон которой соответствует имени метрики. Если ни одна схема не соответствует, используется схема по умолчанию (2 часа данных с минутной точностью). После определения соответствующей схемы Carbon использует настройки сохранения для схемы, чтобы создать файл данных Whisper должным образом.

Шаг 3 — Понимание формата сообщения Graphite

Graphite понимает сообщения с таким форматом:

metric_path value timestamp\n

metric_path — это пространство имен метрики, которое вы хотите заполнить.

value — это значение, которое вы хотите присвоить метрике в данный момент.

timestamp — это количество секунд с момента эпохи Unix. Carbon-cache будет использовать время получения, если timestamp установлено в -1.

Простой пример выполнения этого из терминала Unix выглядит так:

echo "test.bash.stats 42 `date +%s`" | nc graphite.example.com 2003

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