Скачать carbon c relay - загрузка исходного кода carbon c relay

Carbon-C-Relay (1)-реле графита, агрегатор и переписывание

Синопсис

carbon-c-relay -f config-file [ options ... ]

ОПИСАНИЕ

Carbon-C-Relay принимает, очищает, соответствует, переписывает, направляет и агрегирует графитные метрики, прослушивая входящие соединения и передавая сообщения на другие серверы, определенные в его конфигурации. Основная функциональность заключается в маршруте сообщений через гибкие правила в желаемые направления.

Carbon-C-Relay -это простая программа, которая считывает информацию о маршрутизации из файла. Аргументы командной строки позволяют установить местоположение для этого файла, а также объем диспетчеров (рабочие потоки) для чтения данных из входящих соединений и передачи их в правильное пункт назначения. Файл маршрута поддерживает две основные конструкции: кластеры и совпадения. Первые могут быть отправлены первые группы показателей данных хоста, последняя определяет, какие метрики следует отправлять, на какой кластер. Правила агрегации рассматриваются как совпадения. Перезаписывания - это действия, которые напрямую влияют на метрику в точке, в которой они появляются в конфигурации.

Для каждой метрики, полученной реле, выполняется очищение. Следующие изменения выполняются до того, как какое -либо совпадение, совокупное или переписывающее правило видит метрику:

Устранение двойной точки (необходимо для правильно функционирующей последовательной хеш -маршрутизации)
Тропинг/ведущая точка устранение
Нормализация пробела (это в основном влияет на выход реле на другие цели: метрика, значение и временная метка будут разделены только одним пространством, когда -либо)
Нерегулярная замена чара с помощью недостатков (_), в настоящее время нерегулярная определяется как не находится в [0-9a-zA-Z-_:#] , но может быть переопределена в командной строке. Обратите внимание, что теги (когда они присутствуют и разрешены) не обрабатываются таким образом.

ПАРАМЕТРЫ

Эти варианты контролируют поведение углерода-C-рела .

-v : печатная версия строка и выход.
-d : Включите режим отладки, это печатает статистику для Stdout и печатает дополнительные сообщения о некоторых ситуациях, с которыми сталкивается реле, которое обычно было бы слишком условно, чтобы их можно было включить. В сочетании с -t (режим тестирования) это также печатает маршруты заглушки и содержимое кольца с постоянным хэшем.
-s : Включить режим подачи. В этом режиме внутренняя статистика не генерируется. Вместо этого на stdout сообщается о давлении в очереди и показателях показателей. Этот режим полезен при использовании в качестве реле подчинения, какая задача просто для того, чтобы перенаправить (набор) основных реле. Статистические данные о реле подчинения в этом случае не нужны и могут легко вызвать негадацию наводнения метрик, например, при использовании на каждом хозяине локально.
-S : включить IOSTAT-подобный режим, где каждую секунду сообщается о текущем состоянии статистики. Это подразумевает режим подачи -s .
-t : тестовый режим. Этот режим вообще не выполняет никакой маршрутизации, но вместо этого считывает ввод из stdin и печатает то, какие действия будут предпринять с учетом загруженной конфигурации. Этот режим очень полезен для тестирования маршрутов реле для синтаксиса регулярного выражения и т. Д. Также позволяет понять, как маршрутизация применяется в сложных конфигурациях, поскольку также показывает переписывания и агрегаты. Когда -t повторяется, реле только проверяет конфигурацию для достоверности и выхода сразу после этого. Любой стандартный выход подавляется в этом режиме, что делает его идеальным для начальных подписей для тестирования (новой) конфигурации.
-f config-file : read configuration из конфигурации . Конфигурация состоит из кластеров и маршрутов. См. Синтаксис конфигурации для получения дополнительной информации об опциях и синтаксисе этого файла.
-l log-file : используйте журнал для написания сообщений. Без этой опции реле пишет как STDOUT и Stderr . При входе в файл все сообщения префиксируются с помощью MSG , когда они были отправлены в Stdout , и ERR , когда они были отправлены в Stderr .
-p Порт : Слушайте подключения на порту . Номер порта используется как для TCP , UDP и UNIX sockets . В последнем случае файл сокета содержит номер порта. Порт по умолчанию по умолчанию в 2003 году , который также используется исходным carbon-cache.py . Обратите внимание, что это относится только к по умолчанию, когда указания listen находятся в конфигурации, эта настройка игнорируется.
-w Работники : Используйте работники Количество потоков. Количество работников по умолчанию равно сумме обнаруженных ядер процессоров. Имеет смысл уменьшить это число на много ядра или когда трафик низкий.
-b PatchSize : Установите количество метрик, которые сразу отправляли на удаленные серверы для падения . Когда реле отправляет метрики на серверы, оно получит batchsize метрики из ожидаемой очереди метрик, ожидающих этого сервера, и отправит их один за другим. Размер партии окажет минимальное влияние на отправку производительности, но он контролирует количество блокировки в очереди. По умолчанию 2500 .
-q queuesize : каждый сервер из конфигурации, куда реле отправляет метрики, имеет очередь, связанная с ним. Эта очередь позволяет обрабатывать сбои и всплески. Размер этой очереди будет установлен на очередь , что позволяет хранить это количество метрик в очереди до его переполнения, и реле начинает сбрасывать метрики. Чем больше очередь, может быть поглощено больше метрик, но также больше памяти будет использоваться в реле. Размер очереди по умолчанию составляет 25000 .
-L стойлы : устанавливает максимальное крепление киосков для прилавков , прежде чем реле начнет сбрасывать метрики для сервера. Когда очередь заполняется, реле использует механизм, называемый остановкой, чтобы сигнализировать клиенту (написание на реле) этого события. В частности, когда клиент отправляет большое количество метрик за очень короткое время (взрыв), остановка может помочь избежать сброса метрик, поскольку клиент просто должен немного замедляться, что во многих случаях возможно (например, при котировке файла с nc (1)). Тем не менее, это поведение также может препятствовать, искусственно задерживая писателей, которые не могут так легко остановиться. Для этого киоски могут быть установлены от 0 до 15 , где каждый киоск может занять около 1 секунды на клиенту. Значение по умолчанию установлено в 4 , которое предназначено для случайного сценария сбоев и максимальных усилий, чтобы не свободно ослаблять метрики с умеренным замедлением клиентов.
-C CacertPath : Читать CA -Certs (для использования с соединениями TLS/SSL) из данного пути или файла. Когда они не дают, расположения по умолчанию используются. Проводится строгое верфирование однорангового анализа, поэтому при использовании саморегистрированных сертификатов обязательно включите CA CER в местоположение по умолчанию или предоставьте путь к сертификату с использованием этой опции.
-T тайм -аут : указывает время -аут ввода в миллисекундах, используемые для подключений к серверу. По умолчанию 600 миллисекунд, но может потребоваться увеличение, когда для целевых серверов используются ссылки WAN. Относительно низкое значение для тайм -аута подключения позволяет быстро установить сервер, и, как таковые стратегии аварийного переключения, до того, как очередь начнется высокой.
-c chars : определяет персонажей, которые рядом с [A-Za-z0-9] разрешенные в метрик для Chars . Любой символ не в этом списке заменяется реле на _ (подчеркивание). Список допустимых символов по умолчанию --_:# .
-m Длина : ограничивает метрические имена, которые имеют большую часть байтов длины. Любые строки, содержащие метрические имена, больше, чем это, будут отброшены.
-M длина ограничивает вход на линии большинства байтов длины . Любые избыточные линии будут отброшены. Обратите внимание, что -m должен быть меньше, чем это значение.
-H HostName : переопределить имя хоста, определяемое вызовом gethostname (3) с именем хоста . Имя хоста используется в основном в показателях статистики carbon.relays.<hostname>.<...> отправлено реле.
-B Backlog : устанавливает соединение TCP, прослушивание подключений к подключениям к отставанию . Значение по умолчанию составляет 32, но на серверах, которые получают много одновременных соединений, этот параметр, вероятно, должен быть увеличен, чтобы избежать отказа от ошибок подключения к клиентам.
-U Bufsize : устанавливает размеры буфера для отправки/приема сокета в байтах как для сценариев TCP и UDP. Когда используется дефолт ОС по умолчанию. Максимум также определяется ОС. Размеры устанавливаются с использованием SetSockopt с флагами SO_RCVBUF и SO_SNDBUF. Установка этого размера может быть необходимо для больших сценариев громкости, для которых также может применяться -B . Проверка значений RECV-Q и ошибок приема из NetStat дает хороший намек на использование буфера.
-E : Отключить отключение входящих подключений. По умолчанию реле отключает подключения к клиенту простаивания через 10 минут. Это делает это, чтобы предотвратить засорение ресурсов, когда неисправный или злонамеренный клиент продолжает открывать соединения, не закрывая их. Обычно это предотвращает запуск файловых дескрипторов. Однако для некоторых сценариев нежелательно, чтобы холостые соединения были отключены, поэтому проход этого флага отключит это поведение.
-D : Deamonise на задний план после запуска. Эта опция требует, чтобы флаги -l и -P также были установлены.
-P PIDFILE : Напишите PID процесса реле в файл с именем PIDFILE . Это, в частности, полезно при демонзователе в сочетании с менеджерами init.
-O порог : минимальное количество правил, которые можно найти, прежде чем пытаться оптимизировать набор правил. По умолчанию 50 , чтобы отключить оптимизатор, использовать -1 , чтобы всегда запустить оптимизатор использования 0 . Оптимизер пытается группировать правила, чтобы не тратить чрезмерное время на сопоставление выражений.

Синтаксис конфигурации

Файл конфигурации поддерживает следующий синтаксис, где комментарии начинаются с символа # и могут отображаться в любой позиции на линии и подавлять ввод до конца этой линии:

 cluster <name>
    < <forward | any_of | failover> [useall] |
      <carbon_ch | fnv1a_ch | jump_fnv1a_ch> [replication <count>] [dynamic] >
        <host[:port][=instance] [proto <udp | tcp>]
                                [type linemode]
                                [transport <plain | gzip | lz4 | snappy>
                                           [ssl | mtls <pemcert> <pemkey>]]> ...
    ;

cluster <name>
    file [ip]
        </path/to/file> ...
    ;

match
        <* | expression ...>
    [validate <expression> else <log | drop>]
    send to <cluster ... | blackhole>
    [stop]
    ;

rewrite <expression>
    into <replacement>
    ;

aggregate
        <expression> ...
    every <interval> seconds
    expire after <expiration> seconds
    [timestamp at <start | middle | end> of bucket]
    compute <sum | count | max | min | average |
             median | percentile<%> | variance | stddev> write to
        <metric>
    [compute ...]
    [send to <cluster ...>]
    [stop]
    ;

send statistics to <cluster ...>
    [stop]
    ;
statistics
    [submit every <interval> seconds]
    [reset counters after interval]
    [prefix with <prefix>]
    [send to <cluster ...>]
    [stop]
    ;

listen
    type linemode [transport <plain | gzip | lz4 | snappy>
                      [<ssl | mtls> <pemcert>
                          [protomin <tlsproto>] [protomax <tlsproto>]
                          [ciphers <ssl-ciphers>] [ciphersuites <tls-suite>]
                      ]
                  ]
        <<interface[:port] | port> proto <udp | tcp>> ...
        </ptah/to/file proto unix> ...
    ;
    # tlsproto: <ssl3 | tls1.0 | tls1.1 | tls1.2 | tls1.3>
    # ssl-ciphers: see ciphers(1)
    # tls-suite: see SSL_CTX_set_ciphersuites(3)

include </path/to/file/or/glob>
    ;

Кластеры

Несколько кластеров могут быть определены, и не нужно ссылаться на правило соответствия. Все кластеры указывают на один или несколько хостов, за исключением кластера file , который записывается в файлы в локальной файловой системе. host может быть адресом IPv4 или IPv6 или имя хоста. Поскольку за хостом следует дополнительное : и порт, для адресов IPv6 не будут интерпретироваться неправильно, должен быть указан либо порт, либо адрес IPv6, окруженный скобки, например [::1] . Дополнительные transport и proto -предложения могут использоваться для обертывания соединения в слое сжатия или шифрования или указания использования UDP или TCP для подключения к удаленному серверу. При пропущении подключения по умолчанию в простом соединении TCP. type может быть только linemode в данный момент, например, режим Python's Pickle не поддерживается.

failover соответствии с правилами предпочтений any_of RFC forward решаются useall хостов DNS. Используя эту опцию, каждый адрес любого типа становится пунктом назначения кластера. Это означает, например, добавляются как IPv4, так и IPv6 -адреса.

Есть две группы типов кластеров, простые кластеры для пересылки и последовательные хэширующие кластеры.

forward и file кластеры
Кластеры forward и file просто отправляют все, что они получают, на определенные участники (адреса хоста или файлы). Когда в кластере есть несколько членов, все входящие метрики отправляются всем членам, в основном дублируя входной метрический поток для всех участников.
any_of Cluster
Кластер any_of - это небольшой вариант forward кластера, но вместо того, чтобы отправлять входные метрики всем определенным членам, он отправляет каждую входящую метрику только одному из определенных членов. Цель этого-сбалансированный сценарий, в котором любой из участников может получить любую метрику. Как предполагает any_of , когда любой из участников станет недоступным, оставшиеся доступные участники немедленно получат полный входной поток метрик. Это конкретно означает, что при использовании 4 члена каждый получит приблизительно 25% входных метрик. Когда один участник становится недоступным (например, прерывание сети или перезапуск услуги), остальные по 3 участнику каждый получит около 25% / 3 = ~ 8% больше трафика (33%). В качестве альтернативы они получат 1/3 общего входа. При разработке кластера емкость следует учитывать, что в наиболее экстремальном случае конечный оставшийся участник получит весь входной трафик.
В частности, кластер any_of может быть полезен, когда кластер указывает на другие реле или кэши. При использовании с другими реле, он эффективно загружает баланс и немедленно адаптируется к недоступности целей. При использовании с кэшами есть небольшая деталь в том, как работает any_of , это делает его очень подходящим. Реализация этого маршрутизатора не в том, чтобы круглый робин по сравнению с любыми доступными участниками, а вместо этого он использует последовательную стратегию хэширования для постоянного обеспечения одних и тех же метрик в одно и то же место назначения. Это помогает кэшам и облегчает извлечение незавершенных данных данных (из одного кэша), но все же позволяет прокатиться перезагрузки кэша. Когда участник становится недоступным, хеш -направления не изменяются, но вместо этого трафик, предназначенный для недоступного узла, распределена по сравнению с доступными узлами.
failover кластер
failover кластер похож на кластер any_of , но придерживается порядка, в котором определяются серверы. Это для реализации чистого сценария аварийного переключения между серверами. Все показатели отправляются не более 1 члена, поэтому не происходит хеширования или балансировки. Например, failover кластер с двумя участниками отправит метрики только второму участнику, когда первый участник станет недоступным. Как только первый участник возвращается, все метрики снова отправляются в первый узел.
carbon_ch Cluster
Кластер carbon_ch посылает метрики членам, который отвечает в соответствии с последовательным алгоритмом хэша, используемого в исходном реле Carbon Python. Несколько членов возможны, если репликация устанавливается на значение, превышающее 1. Когда установлена dynamic , отказ любого из серверов не приводит к тому, что метрики будут отбрасываться для этого сервера, но вместо этого невозможно добелевшие показатели отправляются на любой другой сервер на кластере, чтобы метрики не были потеряны. Это наиболее полезно, когда репликация 1.
Расчет хешринга, который определяет способ распределения метрик, основан на хосте сервера (или IP -адреса) и необязательным instance элемента. Это означает, что использование двух целей carbon_ch в разных портах, но на одном хосте будет отображаться с одним и тем же гашким, что означает, что не происходит распределения метрик. Экземпляр используется для исправления этой ситуации. Экземпляр добавляется к участнику после порта и разделен значением равных, например, 127.0.0.1:2006=a , например a . Примеры-это концепция, представленная оригинальным углеродным кэшем Python, и ее необходимо использовать в соответствии с конфигурацией их.
Последовательные хэши последовательны в том смысле, что удаление члена из кластера не должно привести к полному повторному отображению всех метрик для участников, но вместо этого добавлять только показатели от удаленного члена ко всем оставшимся членам, примерно каждый получает свою справедливую долю. Другой путь, когда участник добавляется, каждый участник должен увидеть подмножество своих метрик, которые теперь адресованы новому участнику. Это важное преимущество в отношении обычного хэша, где каждое удаление или добавление членов (также через EG изменение их IP-адреса или имени хоста) приведет к полному повторному отображению всех показателей по всем доступным показателям.
fnv1a_ch Cluster
Кластер fnv1a_ch является несовместимым улучшением carbon_ch , введенной Carbon-C-Relay. Он использует другую технику хэш (FNV1A), которая быстрее, чем MD5-Hashing, используемое carbon_ch . Что еще более важно, кластеры fnv1a_ch используют как хост, так и порт, чтобы отличить участников. Это полезно, когда несколько целей живут на одном и том же хосте, просто разделенном портом.
Поскольку свойство instance больше не требуется с fnv1a_ch таким образом, оно используется для полного переопределения хоста: портовой строки, которую будет рассчитывать гайшизирование. Это важный аспект, так как HAHKKEY определяет, какие метрики получает участник. Такой переопределение допускает много вещей, включая маскирующие старые IP -адреса, например, когда машина была перенесена на новое оборудование. Примером этого будет 10.0.0.5:2003=10.0.0.2:2003 , где машина по адресу 5 теперь получает метрики для машины, которая была по адресу 2.
В то время как использование экземпляров таким образом может быть очень полезным для выполнения миграций в существующих кластерах, для вновь для настройки кластеров экземпляры позволяют избежать этой работы, используя экземпляр с первого дня, чтобы отделить местоположение машины от метрик, которые она получает. Рассмотрим, например, 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac , где используется случайный хэш в качестве экземпляра. Это позволило бы изменить порт и/или IP -адрес сервера, который получает данные столько раз, не имея никакого отношения к какому -либо устарею, предполагая, что случайный хэш сохраняется. Обратите внимание, что, поскольку имя экземпляра используется в качестве полного хэш -ввода, экземпляры в a , b и т. Д., Скорее всего, приведут к плохому распределению хэш, поскольку их хэши имеют очень мало ввода. По этой причине рассмотрите возможность использования более длинных и в основном различных имен экземпляров, таких как случайные хэши, как используется в примере выше для лучшего поведения в распределение хэша.
jump_fnv1a_ch Cluster
Кластер jump_fnv1a_ch также является последовательным хэш -кластером, как предыдущие два, но вообще не учитывает хост члена, порт или экземпляр. Это означает, что этот тип кластера рассматривает порядок, в котором определяются участники, см. Также ниже для получения дополнительной информации об этом порядке. Полезно ли это для вас, зависит от вашего сценария. В отличие от двух предыдущих последовательных типов хэш -кластеров, хэш прыжков имеет почти идеальную балансировку над членами, определенными в кластере. Тем не менее, это происходит за счет того, что он не может удалить любого участника, но последний из кластера, не вызывая полного повторного отображения всех показателей по сравнению с всеми участниками. Это в основном означает, что этот хэш хорош для использования с постоянными или постоянно растущими кластерами, где более старые узлы никогда не удаляются, но вместо этого заменяются.
Если у вас есть кластер, где происходит удаление старых узлов, хэш прыжков не подходит для вас. Jump Hash работает с серверами в упорядоченном списке. Поскольку этот порядок важен, он может быть сделан явным с использованием экземпляра, используемого в предыдущих типах кластеров. Когда экземпляр будет дан с участниками, он будет использоваться в качестве ключа сортировки. Без этого экземпляра порядок будет приведен в файле конфигурации, который может быть подвержен изменениям, когда, например, сгенерировано некоторым программным обеспечением для управления конфигурацией. Таким образом, это, вероятно, хорошая практика, чтобы исправить порядок серверов с экземплярами, так что это ясно, каковы правильные узлы для хэша прыжка. Можно просто использовать цифры для них, но имейте в виду, что сортировка 1, 2 и 10 приводит к 1, 10, 2, поэтому лучше использовать что -то вроде P0001, P0002, P0010.

Матчи

Правила соответствия - это способ направить входящие метрики на один или несколько кластеров. Правила соответствия обрабатываются сверху вниз, так как они определены в файле. Можно определить несколько совпадений в том же правиле. Каждое правило совпадения может отправлять данные в один или несколько кластеров. Поскольку правила соответствия «пропадают», если не добавлено ключевое слово stop , тщательно созданное выражение совпадения можно использовать для нацеливания на несколько кластеров или агрегаций. Эта способность позволяет воспроизвести метрики, а также отправлять определенные метрики в альтернативные кластеры с тщательным упорядочением и использованием ключевого слова stop . Специальный кластер blackhole сбрасывает любые показатели, отправленные ему. Это может быть полезно для отсеивания нежелательных показателей в некоторых случаях. Поскольку выбрасывание метрик бессмысленно, если другие совпадения будут принимать те же данные, совпадение с пунктом назначения в кластере Черной дыры, имеет неявную stop . Пункт validation добавляет проверку данных (что происходит после метрики) в виде регулярного выражения. Когда это выражение совпадает, правило совпадения будет выполняться так, как будто не было пункта проверки. Однако, если это не удастся, правило совпадения прерывается, и в пункты назначения не будет отправлено никаких показателей, это поведение drop . Когда используется log , метрика регистрируется в STDERR. Следует позаботиться о последнем, чтобы избежать затопления бревна. Когда существует пункт проверки, направления не должны присутствовать, это позволяет применять правило глобального валидации. Обратите внимание, что правила очистки применяются до выполнения проверки, поэтому данные не будут иметь дублирующих пространств. route using пункт, используется для выполнения временной модификации ключа, используемого для ввода для последовательных процедур хешина. Основная цель состоит в том, чтобы направить трафик, чтобы соответствующие данные были отправлены на необходимые экземпляры агрегации.

Переписывает

Правила перезаписывания принимают регулярное выражение в качестве входных данных, чтобы соответствовать входящим показателям и преобразовать их в желаемое новое метрическое имя. В замене обратные реферации разрешают соответствовать группам захвата, определенных в входном регулярном выражении. Сопоставление server.(x|y|z). Позволяет использовать, например, role.1. в замене. При необходимости, вместо n можно использовать обозначения g{n} где за обратной ссылкой следует целое число, такое как g{1}100 . Несколько предостережений применяются к текущей реализации правил переписывания. Во -первых, их местоположение в файле конфигурации определяет, когда выполняется перезапись. Перезапись выполняется на месте, как таковое правило совпадения, прежде чем переписать соответствует первоначальному имени, правило совпадения после того, как переписывание больше не соответствует первоначальному имени. Следует соблюдать осторожность при упорядочении, поскольку могут иметь место множественные правила переписывания подряд, например, a заменяется b и b , заменяется c в последующем правиле переписывания. Второе предостережение с текущей реализацией заключается в том, что переписанные метрические имена не очищаются, как в новые входящие метрики. Таким образом, двойные точки и потенциальные опасные символы могут появиться, если запасная строка изготовлена для их создания. Автор обязан убедиться, что метрики чисты. Если это проблема для маршрутизации, можно подумать, чтобы иметь экземпляр только для переписывания, который направляет все метрики в другой экземпляр, который будет выполнять маршрутизацию. Очевидно, что второй экземпляр будет очищать метрики по мере их появления. Обозначение обратной ссылки позволяет строить и опередить строку с использованием символов подчеркивания ( _ ) и Carret ( ^ ), следующих непосредственно после обратной строки. Например, role._1. в качестве замены будет снижать содержимое содержимого 1 . Точка ( . ) Может использоваться аналогичным образом или следовать после подчеркивания или кареты, чтобы заменить точки подставками в замене. Это может быть удобно для некоторых ситуаций, когда метрики отправляются на графит.

Агрегации

Определенные агрегации принимают один или несколько входных показателей, выраженных одним или несколькими регулярными эксплуатациями, аналогично правилам совпадения. Входящие метрики агрегируются в течение определенного периода времени, определяемого интервалом за считанные секунды. Поскольку события могут наступить чуть позже, время истечения за считанные секунды определяет, когда агрегации следует считать окончательными, поскольку новые записи не позволяют больше добавлять. Помимо агрегации могут быть рассчитаны несколько агрегаций. Они могут быть одинаковых или разных типов агрегации, но должны написать в уникальную новую метрику. Метрические имена могут включать в себя обратные ссылки, как в переписывании выражений, что позволяет обеспечить мощные правила единой агрегации, которые дают во многих агрегациях. Когда не будет дано send to пункт, производимые метрики отправляются в реле, как если бы они были представлены извне, следовательно, к ним применяются правила соответствия и агрегации. Следует позаботиться о том, что такими способами избегают. По этой причине используется предложение send to », чтобы направлять выходной трафик, где это возможно. Как и для правил соответствия, можно определить несколько целей кластера. Кроме того, как правила соответствия, ключевое слово stop применяется для управления потоком метрик в процессе сопоставления.

СТАТИСТИКА

send statistics to построения устарела и будет удалена в следующем выпуске. Вместо этого используйте специальную statistics конструкцию.

statistics конструкция может контролировать пару вещей о (внутренней) статистике, созданной реле. send to цель может использоваться, чтобы избежать петель маршрутизатора путем отправки статистики в определенный кластер (ы) назначения. По умолчанию метрики префикс с -H carbon.relays.<hostname> Этот префикс может быть установлен с использованием prefix with пунктом, аналогичным целевому правилу переписывания. Входной совпадение в этом случае является предварительно установленным регулярным выражением ^(([^.]+)(..*)?)$ На имя хоста. Таким образом, можно видеть, что префикс по умолчанию устанавливается carbon.relays..1 . Обратите внимание, что это использует функцию замены замены-dot-with-underscore из правил перезаписывания. Учитывая входное выражение, доступны следующие группы соответствия: 1 Все имя хоста, 2 Короткое имя хоста и 3 DomainName (с ведущей точкой). Может иметь смысл заменить по умолчанию на что -то вроде carbon.relays._2 Для определенных сценариев всегда использовать нижнее короткое имя хоста, которое после выражения не содержит точки. По умолчанию метрики представляются каждые 60 секунд, это может быть изменено с помощью submit every <interval> seconds reset counters after interval чтобы получить более совместимый набор значений для углерода.

Слушатели

Порты и протоколы. Реле должно прослушать входящие соединения, которые могут быть указаны с использованием директивы listen . В настоящее время все слушатели должны быть из типа linemode . Необязательное сжатие или обертывание шифрования может быть указано для порта и необязательного интерфейса, заданного IP -адресом или сокета Unix File. Когда интерфейс не указан, предполагается любой интерфейс по всем доступным IP -протоколам. Если директива listen не присутствует, реле будет использовать слушателей по умолчанию для порта 2003 на TCP и UDP, а также Socket Socket /tmp/.s.carbon-c-relay.2003 . Это обычно расширяется до 5 слушателей в системе с поддержкой IPv6. По умолчанию соответствует поведению версий до v3.2.

Включает

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

Примеры

Carbon-C-Relay со временем развивался, выращивая функции по спросу, поскольку инструмент оказался стабильным и хорошо подгонял работу. Ниже приведены некоторые аннотированные примеры конструкций, которые можно использовать с реле.

Кластеры могут быть определены столько, сколько необходимо. Они получают данные из правил соответствия, и их тип определяет, какие члены кластера, наконец, получают метрические данные. Самая простая форма кластера - это forward кластер:

 cluster send-through
    forward
        10.1.0.1
    ;

Любая метрика, отправленная в кластер send-through будет просто перенаправлен на сервер по адресу IPv4 10.1.0.1 . Если мы определим несколько серверов, все эти серверы получат одинаковую метрику, таким образом:

 cluster send-through
    forward
        10.1.0.1
        10.2.0.1
    ;

Вышеуказанное приводит к дублированию метрик, отправленных на обе машины. Это может быть полезно, но большую часть времени это не так. Тип кластера any_of похож на forward , но он отправляет каждую входящую метрику любому из участников. Тот же пример с таким кластером будет:

 cluster send-to-any-one
    any_of 10.1.0.1:2010 10.1.0.1:2011;

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

 cluster try-first-then-second
    failover 10.1.0.1:2010 10.1.0.1:2011;

Эти типы отличаются от двух последовательных типов хэш -кластеров:

 cluster graphite
    carbon_ch
        127.0.0.1:2006=a
        127.0.0.1:2007=b
        127.0.0.1:2008=c
    ;

Если участник в этом примере не удастся, все метрики, которые пошли бы к этому участнику, хранятся в очереди, ожидая, когда участник вернется. Это полезно для кластеров машин углерода, где желательно, чтобы одна и та же метрика всегда была на одном и том же сервере. Тип кластера carbon_ch совместим с согласованным хэш-хэшем углерода и может использоваться для существующих кластеров, заполненных углеродным реле. Однако для новых кластеров лучше использовать тип кластера fnv1a_ch , поскольку он быстрее и позволяет сбалансировать по одному и тому же адресу, но разные порты без номера экземпляра, в создании carbon_ch .

Поскольку мы можем использовать несколько кластеров, мы также можем воспроизвести без использования forward типа кластера, более интеллектуально:

 cluster dc-old
    carbon_ch replication 2
        10.1.0.1
        10.1.0.2
        10.1.0.3
    ;
cluster dc-new1
    fnv1a_ch replication 2
        10.2.0.1
        10.2.0.2
        10.2.0.3
    ;
cluster dc-new2
    fnv1a_ch replication 2
        10.3.0.1
        10.3.0.2
        10.3.0.3
    ;

match *
    send to dc-old
    ;
match *
    send to
        dc-new1
        dc-new2
    stop
    ;

В этом примере все входящие метрики сначала отправляются в dc-old , затем dc-new1 и, наконец, в dc-new2 . Обратите внимание, что тип кластера dc-old отличается. Каждая входящая метрика будет отправлена 2 членам всех трех кластеров, тем самым повторяя в общей сложности 6 направлений. Для каждого кластера участники назначения вычисляются независимо. Неспособность кластеров или членов не влияет на других, поскольку у всех есть отдельные очереди. Приведенный выше пример также может быть написан с использованием трех правил соответствия для каждого DC или одного правила совпадения для всех трех DC. Разница в основном в результате производительности, количество раз, когда входящая метрика должна соответствовать выражению. Правило stop в правиле соответствия dc-new соответствия не является строго необходимым в этом примере, потому что больше нет правил соответствия. Однако, если совпадение будет нацелено на определенное подмножество, например ^sys. и больше кластеров будут определены, это может быть необходимо, например, в следующем сокращенном примере:

 cluster dc1-sys ... ;
cluster dc2-sys ... ;

cluster dc1-misc ... ;
cluster dc2-misc ... ;

match ^sys. send to dc1-sys;
match ^sys. send to dc2-sys stop;

match * send to dc1-misc;
match * send to dc2-misc stop;

Как видно, без stop в правиле соответствия DC2-Sys все метрики, начинающиеся с sys. Также будет отправлена в DC1-MISC и DC2-MISC. Возможно, это, конечно, желательно, но в этом примере есть выделенный кластер для метрик sys .

Предположим, что будет некоторая нежелательная метрика, которая, к сожалению, генерируется, давайте предположим, что какое -то плохое/старое программное обеспечение. Мы не хотим хранить этот показатель. Для этого подходит кластер blackhole , когда на самом деле труднее в белом списке все желаемые метрики. Рассмотрим следующее:

 match
        some_legacy1$
        some_legacy2$
    send to blackhole
    stop;

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

 cluster old ... ;
cluster new ... ;

match * send to old;

match unwanted send to blackhole stop;

match * send to new;

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

Валидация может быть использована для обеспечения того, чтобы данные для метрик были как ожидалось. Глобальная проверка для значений number (без плавающей запятой) может быть:

 match *
    validate ^[0-9]+ [0-9]+$ else drop
    ;

(Обратите внимание на побег с Backslash of Space, вы можете использовать s или [:space:] Вместо этого это зависит от вашей настроенной реализации повторного положения.)

Пункт проверки может существовать в каждом правиле соответствия, поэтому в принципе следует действительное:

 match ^foo
    validate ^[0-9]+ [0-9]+$ else drop
    send to integer-cluster
    ;
match ^foo
    validate ^[0-9.e+-]+ [0-9.e+-]+$ else drop
    send to float-cluster
    stop;

Обратите внимание, что поведение отличается в предыдущих двух примерах. Когда не указана send to кластеры, ошибка проверки делает совпадение в ведении, как ключевое слово stop . Likewise, when validation passes, processing continues with the next rule. When destination clusters are present, the match respects the stop keyword as normal. When specified, processing will always stop when specified so. However, if validation fails, the rule does not send anything to the destination clusters, the metric will be dropped or logged, but never sent.

The relay is capable of rewriting incoming metrics on the fly. This process is done based on regular expressions with capture groups that allow to substitute parts in a replacement string. Rewrite rules allow to cleanup metrics from applications, or provide a migration path. In it's simplest form a rewrite rule looks like this:

 rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
    into server._1.2.3.34
    ;

In this example a metric like server.DC.role.name123 would be transformed into server.dc.role.name.name123 . For rewrite rules hold the same as for matches, that their order matters. Hence to build on top of the old/new cluster example done earlier, the following would store the original metric name in the old cluster, and the new metric name in the new cluster:

 rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
    into server._1.2.3.34
    ;
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
    into server.g{_1}.g{2}.g{3}.g{3}g{4}
    ;

The alternate syntax for backreference notation using g{n} instead of n notation shown above. Both rewrite rules are identical.

 match * send to old;

rewrite ... ;

match * send to new;

Note that after the rewrite, the original metric name is no longer available, as the rewrite happens in-place.

Aggregations are probably the most complex part of carbon-c-relay. Two ways of specifying aggregates are supported by carbon-c-relay. The first, static rules, are handled by an optimiser which tries to fold thousands of rules into groups to make the matching more efficient. The second, dynamic rules, are very powerful compact definitions with possibly thousands of internal instantiations. A typical static aggregation looks like:

 aggregate
        ^sys.dc1.somehost-[0-9]+.somecluster.mysql.replication_delay
        ^sys.dc2.somehost-[0-9]+.somecluster.mysql.replication_delay
    every 10 seconds
    expire after 35 seconds
    timestamp at end of bucket
    compute sum write to
        mysql.somecluster.total_replication_delay
    compute average write to
        mysql.somecluster.average_replication_delay
    compute max write to
        mysql.somecluster.max_replication_delay
    compute count write to
        mysql.somecluster.replication_delay_metric_count
    ;

In this example, four aggregations are produced from the incoming matching metrics. In this example we could have written the two matches as one, but for demonstration purposes we did not. Obviously they can refer to different metrics, if that makes sense. The every 10 seconds clause specifies in what interval the aggregator can expect new metrics to arrive. This interval is used to produce the aggregations, thus each 10 seconds 4 new metrics are generated from the data received sofar. Because data may be in transit for some reason, or generation stalled, the expire after clause specifies how long the data should be kept before considering a data bucket (which is aggregated) to be complete. In the example, 35 was used, which means after 35 seconds the first aggregates are produced. It also means that metrics can arrive 35 seconds late, and still be taken into account. The exact time at which the aggregate metrics are produced is random between 0 and interval (10 in this case) seconds after the expiry time. This is done to prevent thundering herds of metrics for large aggregation sets. The timestamp that is used for the aggregations can be specified to be the start , middle or end of the bucket. Original carbon-aggregator.py uses start , while carbon-c-relay's default has always been end . The compute clauses demonstrate a single aggregation rule can produce multiple aggregates, as often is the case. Internally, this comes for free, since all possible aggregates are always calculated, whether or not they are used. The produced new metrics are resubmitted to the relay, hence matches defined before in the configuration can match output of the aggregator. It is important to avoid loops, that can be generated this way. In general, splitting aggregations to their own carbon-c-relay instance, such that it is easy to forward the produced metrics to another relay instance is a good practice.

The previous example could also be written as follows to be dynamic:

 aggregate
        ^sys.dc[0-9].(somehost-[0-9]+).([^.]+).mysql.replication_delay
    every 10 seconds
    expire after 35 seconds
    compute sum write to
        mysql.host.1.replication_delay
    compute sum write to
        mysql.host.all.replication_delay
    compute sum write to
        mysql.cluster.2.replication_delay
    compute sum write to
        mysql.cluster.all.replication_delay
    ;

Here a single match, results in four aggregations, each of a different scope. In this example aggregation based on hostname and cluster are being made, as well as the more general all targets, which in this example have both identical values. Note that with this single aggregation rule, both per-cluster, per-host and total aggregations are produced. Obviously, the input metrics define which hosts and clusters are produced.

With use of the send to clause, aggregations can be made more intuitive and less error-prone. Consider the below example:

 cluster graphite fnv1a_ch ip1 ip2 ip3;

aggregate ^sys.somemetric
    every 60 seconds
    expire after 75 seconds
    compute sum write to
        sys.somemetric
    send to graphite
    stop
    ;

match * send to graphite;

It sends all incoming metrics to the graphite cluster, except the sys.somemetric ones, which it replaces with a sum of all the incoming ones. Without a stop in the aggregate, this causes a loop, and without the send to , the metric name can't be kept its original name, for the output now directly goes to the cluster.

When configuring cluster you might want to check how the metrics will be routed and hashed. That's what the -t flag is for. For the following configuration:

 cluster graphite_swarm_odd
    fnv1a_ch replication 1
        host01.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
        host03.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
        host05.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313
;

cluster graphite_swarm_even
    fnv1a_ch replication 1
        host02.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
        host04.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
        host06.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313

;

match *
    send to
        graphite_swarm_odd
        graphite_swarm_even
    stop
;

Running the command: echo "my.super.metric" | carbon-c-relay -f config.conf -t , will result in:

 [...]
match
    * -> my.super.metric
    fnv1a_ch(graphite_swarm_odd)
        host03.dom:2003
    fnv1a_ch(graphite_swarm_even)
        host04.dom:2003
    stop

You now know that your metric my.super.metric will be hashed and arrive on the host03 and host04 machines. Adding the -d flag will increase the amount of information by showing you the hashring

СТАТИСТИКА

When carbon-c-relay is run without -d or -s arguments, statistics will be produced. By default they are sent to the relay itself in the form of carbon.relays.<hostname>.* . See the statistics construct to override this prefix, sending interval and values produced. While many metrics have a similar name to what carbon-cache.py would produce, their values are likely different. By default, most values are running counters which only increase over time. The use of the nonNegativeDerivative() function from graphite is useful with these.

The following metrics are produced under the carbon.relays.<hostname> namespace:

metricsReceived
The number of metrics that were received by the relay. Received here means that they were seen and processed by any of the dispatchers.
metricsSent
The number of metrics that were sent from the relay. This is a total count for all servers combined. When incoming metrics are duplicated by the cluster configuration, this counter will include all those duplications. In other words, the amount of metrics that were successfully sent to other systems. Note that metrics that are processed (received) but still in the sending queue (queued) are not included in this counter.
metricsDiscarded
The number of input lines that were not considered to be a valid metric. Such lines can be empty, only containing whitespace, or hitting the limits given for max input length and/or max metric length (see -m and -M options).
metricsQueued
The total number of metrics that are currently in the queues for all the server targets. This metric is not cumulative, for it is a sample of the queue size, which can (and should) go up and down. Therefore you should not use the derivative function for this metric.
metricsDropped
The total number of metric that had to be dropped due to server queues overflowing. A queue typically overflows when the server it tries to send its metrics to is not reachable, or too slow in ingesting the amount of metrics queued. This can be network or resource related, and also greatly depends on the rate of metrics being sent to the particular server.
metricsBlackholed
The number of metrics that did not match any rule, or matched a rule with blackhole as target. Depending on your configuration, a high value might be an indication of a misconfiguration somewhere. These metrics were received by the relay, but never sent anywhere, thus they disappeared.
metricStalls
The number of times the relay had to stall a client to indicate that the downstream server cannot handle the stream of metrics. A stall is only performed when the queue is full and the server is actually receptive of metrics, but just too slow at the moment. Stalls typically happen during micro-bursts, where the client typically is unaware that it should stop sending more data, while it is able to.
connections
The number of connect requests handled. This is an ever increasing number just counting how many connections were accepted.
disconnects
The number of disconnected clients. A disconnect either happens because the client goes away, or due to an idle timeout in the relay. The difference between this metric and connections is the amount of connections actively held by the relay. In normal situations this amount remains within reasonable bounds. Many connections, but few disconnections typically indicate a possible connection leak in the client. The idle connections disconnect in the relay here is to guard against resource drain in such scenarios.
dispatch_wallTime_us
The number of microseconds spent by the dispatchers to do their work. In particular on multi-core systems, this value can be confusing, however, it indicates how long the dispatchers were doing work handling clients. It includes everything they do, from reading data from a socket, cleaning up the input metric, to adding the metric to the appropriate queues. The larger the configuration, and more complex in terms of matches, the more time the dispatchers will spend on the cpu. But also time they do /not/ spend on the cpu is included in this number. It is the pure wallclock time the dispatcher was serving a client.
dispatch_sleepTime_us
The number of microseconds spent by the dispatchers sleeping waiting for work. When this value gets small (or even zero) the dispatcher has so much work that it doesn't sleep any more, and likely can't process the work in a timely fashion any more. This value plus the wallTime from above sort of sums up to the total uptime taken by this dispatcher. Therefore, expressing the wallTime as percentage of this sum gives the busyness percentage draining all the way up to 100% if sleepTime goes to 0.
server_wallTime_us
The number of microseconds spent by the servers to send the metrics from their queues. This value includes connection creation, reading from the queue, and sending metrics over the network.
dispatcherX
For each indivual dispatcher, the metrics received and blackholed plus the wall clock time. The values are as described above.
destinations.X
For all known destinations, the number of dropped, queued and sent metrics plus the wall clock time spent. The values are as described above.
aggregators.metricsReceived
The number of metrics that were matched an aggregator rule and were accepted by the aggregator. When a metric matches multiple aggregators, this value will reflect that. A metric is not counted when it is considered syntactically invalid, eg no value was found.
aggregators.metricsDropped
The number of metrics that were sent to an aggregator, but did not fit timewise. This is either because the metric was too far in the past or future. The expire after clause in aggregate statements controls how long in the past metric values are accepted.
aggregators.metricsSent
The number of metrics that were sent from the aggregators. These metrics were produced and are the actual results of aggregations.

Ошибки

Please report them at: https://github.com/grobian/carbon-c-relay/issues

AUTHOR

Fabian Groffen <[email protected]>

Благодарности

This program was originally developed for Booking.com, which approved that the code was published and released as Open Source on GitHub, for which the author would like to express his gratitude. Development has continued since with the help of many contributors suggesting features, reporting bugs, adding patches and more to make carbon-c-relay into what it is today.

Расширять