riemannx
v4.2.0
Полностью изготовленный клиент Riemann, построенный на надежности Poolboy и потрясающей силы Эликсира!
Riemannx - это клиент Riemann, встроенный в Elixir, в настоящее время это единственный клиент в Elixir, который поддерживает UDP и TLS (а также TCP). Существует также пакетный режим, который вы можете использовать, который работает с любым транспортом.
Он имеет экспериментальный комбинированный вариант, который делает наилучшим образом как TCP, так и UDP - в комбинированном режиме UDP является предпочтительным подходом, но если размер сообщения превышает максимальный набор размеров UDP TCP.
Как всегда, существуют предпосылки, необходимые перед использованием Riemannx, большинство из них очевидны (Elixir, Erlang), но содержат некоторую информацию о том, какие версии проверены и поддерживаются.
В настоящее время все версии erlang ~> 18 поддерживаются. Это включает в себя 20, 20,1 еще не протестировано, но я не предвижу никаких больших проблем.
Протестировано Трэвисом:
18.019.320.0Я пытался обеспечить совместимость с 1.3.4 и буду продолжать делать это, где это необходимо. Протестированные комбинации:
18.0 Эликсир: 1.3.4 / 1.4.5 / 1.5.119.3 Эликсир: 1.3.4 / 1.4.5 / 1.5.120.0 Эликсир: 1.4.5 / 1.5.1Как это часто бывает, клиент довольно бесполезен без его аналога сервера - для получения дополнительной информации о Riemann посетите http://riemann.io.
Клиент провел только боевую проверку: 0.2.11 . От версии 4.0.0 клиента вам нужно будет установить use_micro в false, если вы используете версию Riemann старше 0.2.13 и не устанавливаете полю времени самостоятельно. Это должно работать с 0.3.0 но опять же, ранее не проверялось (любой, кто хочет работать над интеграционными тестами, я очень ценю это).
Установка происходит так же, как любая другая библиотека Elixir, добавьте ее в файл микса, а остальное - история:
def deps do
[ { :riemannx , "~> 4.0" } ]
endУбедитесь, что вы добавили Riemannx в список приложений в вашем файле mix.exs, это гарантирует, что он запускается с вашего приложения и будет включено в ваши выпуски (если вы используете диспетчер релизов):
applications : [ :logger , :riemannx ] Чтобы использовать Riemannx, все, что вам нужно сделать, это заполнить некоторые записи конфигурации - после этого все происходит автоматически (за исключением фактической отправки, конечно). Ниже приведен полный список доступных вариантов:
config :riemannx , [
host: "localhost" , # The riemann server
event_host: "my_app" , # You can override the host name sent to riemann if you want (see: Host Injection)
send_timeout: 30_000 , # Synchronous send timeout
checkout_timeout: 30_000 , # Timeout for checking out a poolboy worker
type: :batch , # The type of connection you want to run (:tcp, :udp, :tls, :combined, :batch)
settings_module: Riemannx.Settings.Default # The backend used for reading settings back
metrics_module: Riemannx . Metrics.Default # The backend used for sending metrics
use_micro: true # Set to false if you use a riemann version before 0.2.13
batch_settings: [
type : :combined # The underlying connection to use when using batching.
size: 50 , # The size of batches to send to riemann.
interval: { 1 , :seconds } , # The interval at which to send batches.
limit: :infinity # The max limit of batches allowed in the batching queue
]
tcp: [
port : 5555 ,
retry_count: 5 , # How many times to re-attempt a TCP connection
retry_interval: 1000 , # Interval to wait before the next TCP connection attempt (milliseconds).
priority: :high , # Priority to give TCP workers.
options: [ ] , # Specify additional options to be passed to gen_tcp (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
pool_size: 5 , # How many TCP workers should be in the pool.
max_overflow: 5 , # Under heavy load how many more TCP workers can be created to meet demand?
strategy: :fifo # The poolboy strategy for retrieving workers from the queue
] ,
udp: [
port: 5555 ,
priority: :high ,
options: [ ] , # Specify additional options to be passed to gen_udp (NOTE: [:binary, sndbuf: max_udp_size()] will be added to whatever you type here as they are deemed essential)
max_size: 16_384 , # Maximum accepted packet size (this is configured in your Riemann server)
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
] ,
tls: [
port: 5554 ,
retry_count: 5 , # How many times to re-attempt a TLS connection
retry_interval: 1000 , # Interval to wait before the next TLS connection attempt (milliseconds).
priority: :high ,
options: [ ] , # Specify additional options to be passed to :ssl (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
]
] Riemannx поддерживает два метода send , один асинхронный другой синхронный:
Синхронная отправка позволяет обрабатывать ошибки, которые могут возникнуть во время отправки, ниже приведен пример, показывающий, как выглядит эта ошибка и что происходит при успешной отправке:
event = [ service: "riemannx-elixir" ,
metric: 1 ,
attributes: [ a: 1 ] ,
description: "test" ]
case Riemannx . send ( event ) do
:ok ->
"Success!"
[ error: error , msg: encoded_msg ] ->
# The error will always be a string so you can output it as it is.
#
# The encoded message is a binary blob but you can use the riemannx proto
# msg module to decode it if you wish to see it in human readable form.
msg = encoded_msg |> Riemannx.Proto.Msg . decode ( )
Logger . warn ( "Error: #{ error } Message: #{ inspect msg } " )
endАсинхронная отправка намного быстрее, но вы никогда не знаете, сделано ли ваше сообщение, во многих случаях этот вид отправки достаточно безопасен, и для большинства случаев использования рекомендуемый выбор. Это довольно просто в реализации:
event = [ service: "riemannx-elixir" ,
metric: 1 ,
attributes: [ a: 1 ] ,
description: "test" ]
Riemannx . send_async ( event )
# Who knows if it made it? Who cares? 60% of the time it works everytime!Примечание. Если работник не может отправить его, умрет и будет перезагружен, давая ему возможность вернуться в «правильное» состояние. На асинхронной отправке это выполняется путем соответствия шаблона: OK с командой Send, для синхронных отправков, если возвратное значение является ошибкой, мы убиваем работника, прежде чем вернуть результат.
Поддержка TLS позволяет вам использовать безопасное соединение TCP с вашим сервером Riemann, чтобы узнать больше о том, как настроить это. Посмотрите здесь: Secure Riemann Traffic с помощью TLS
Если вы решите использовать TLS, вы будете использовать чисто настройку TCP, комбинированное не поддерживается (и не должно быть) с TLS:
config :riemannx , [
host: "127.0.0.1" ,
type: :tls ,
tls: [
port: 5554 ,
retry_count: 5 , # How many times to re-attempt a TLS connection
retry_interval: 1000 , # Interval to wait before the next TLS connection attempt (milliseconds).
priority: :high ,
# SSL Opts are passed to the underlying ssl erlang interface
# See available options here: http://erlang.org/doc/man/ssl.html
# (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
options: [
keyfile: "path/to/key" ,
certfile: "path/to/cert" ,
verify_peer: true
] ,
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
]
]Предполагая, что вы правильно настроили серверную сторону, это должно быть все, что вам нужно для начала.
У Riemann есть концепция запроса, который позволяет искать конкретные события, индексы должны быть специально созданы в вашей конфигурации, в противном случае сервер вернет ошибку «без индекса».
# Lets send an event that we can then query
Riemannx . send ( [ service: "riemannx" , metric: 5.0 , attributes: [ v: "2.2.0" ] ] )
# Let's fish it out
events = Riemannx . query ( 'service ~= "riemannx"' )
# [%{attributes: %{"v" => "2.2.0"}, description: nil, host: _,
# metric: nil, service: "riemannx", state: nil, tags: [],
# time: _, ttl: _}]Для получения дополнительной информации о запросах и языковых функциях рассмотрим основные концепции.
Этот раздел содержит некоторые заметки о поведении Riemannx, которые могут заинтересовать вас или ответить на вопросы о определенных вещах.
Отказ от 4.0.0 - это поведение подключения по умолчанию - размер партии по умолчанию составляет 50, а интервал - каждые 1 секунду. Партия работает так:
Все, что находится в очереди, будет отправлено каждый интервал.
Если размер очереди достигнет размера партии, он будет промыть независимо от интервала.
Партии будут отброшены, если работники не доступны для обработки партии, если :infinity установлен checkout_timer
Существует новый тип под названием :batch и клавиша настроек с именем batch_settings: , Inside batch_settings Вы можете указать тип для базового соединения ( :tcp , :udp , :combined , :tls ). Как всегда комбинировано по умолчанию.
Необязательно, можно указать количество ограниченного партии ( :limit ). В случае установки, после того, как в отсеке очередь имеет указанное количество партий, то есть limit * batch_size Events, новые события будут отброшены, пока не будет отправлено как минимум одна партия. Значение по умолчанию :infinity
Из версии 0.2.13 из Riemann можно было установить время на микросекундах - Riemannx теперь поддерживает и использует поле time_micros (если только вы не установите полю времени или времени_micros, Riemannx не будет перезаписать это). Если вы используете более старую версию Riemann, это будет использовать только поле Seconds.
ПРИМЕЧАНИЕ. Если вы установите как Time, так и Time_micros Riemann расставят приоритеты Micro Time, а Riemannx не будет перезаписать.
Это звучит причуднее, чем это, но в основном описывает функциональность, которая добавляет запись хоста к вашему событию, если вы не указали ее. Есть 3 способа указать хост:
Сделайте это перед отправкой события (добавьте ключ хоста в список ключевых слов)
Добавьте :event_host в вашу конфигурацию.
Пусть Riemannx сделает это с помощью :inet.gethostname() - мы называем это только один раз, и сохраняем результат, это не вызывает на каждое событие.
Последние 2 варианта являются наиболее выгодными, поскольку они будут держать ваш код в чистоте.
В этом клиенте есть возможность установить приоритет для ваших работников, позволяющих вам размещать более высокий или менее приоритетный при отправке вашей статистики в Riemann.
Установка разницы приоритет в значительной степени зависит от аппаратного обеспечения и того, как вы установили другие приоритеты в целом, можно найти больше информации здесь: http://erlang.org/doc/man/erlang.html#process_flag-2
Если вы попытаетесь установить приоритет: Max Riemannx поднимет время выполнения, потому что это ужасная идея. Это также поднимет время выполнения, если вы попытаетесь: Foo, потому что это также ужасная идея.
По сути, Migrating на 3.0 - это всего лишь случай изменения вашей конфигурации - все те же параметры существуют, за исключением того, что теперь вы имеете больший контроль над своими работниками на уровне типа, это особенно ценно при использовании комбинированной настройки, как вы могли, скажем, иметь меньший пул работников TCP и более крупный пул UDP вместо того, как это было раньше (2X, что бы ни дал Pool_Size, который вы дали).
Вы можете увидеть этот новый макет здесь: config
Если что -то не имеет смысла здесь, не стесняйтесь открывать проблему, чтобы мы могли расширить ReadMe, чтобы исправить нералетность.
Если вы хотите сохранить свои настройки в другом месте, вы можете создать бэкэнд для чтения настройки, например, из базы данных. Посмотрите на модуль настроек по умолчанию для необходимых обратных вызовов.
Это может быть полезно, если вы хотите хранить настройки всего компании в одном месте.
Не стесняйтесь открывать проблему, если у вас есть вопросы.
Riemannx поддерживает отправку основных метрик, вы можете создать пользовательский модуль для поддержки любой инфраструктуры (графит, приток и т. Д.). В настоящее время есть 3 обратных вызова:
udp_message_sent(size) - сообщает, когда отправляется сообщение UDP, и дает размер сообщения.tcp_message_sent(size) - сообщает, когда отправляется сообщение TCP, и дает размер сообщения.tls_message_sent(size) - сообщает, когда отправляется сообщение TLS, и дает размер сообщения. Взносы тепло получены, ознакомьтесь с разделом проектов для некоторых идей, которые я записал, и для последних о том, что продолжается.
В этом хранилище используется рабочий процесс Gitflow, означающий, что все PR должны быть направлены на развитие ветви! Полем Ниже приведены некоторые вещи, которые следует рассмотреть, прежде чем создавать PR:
Я хотел бы сохранить тестовый охват на 100%! - Я могу позволить этому скользить в срочных случаях (ошибки и т. Д.)
Чтобы избежать задержания Трэвиса без необходимости, это будет оценено, если вы сначала проверьте следующее на локальном уровне:
mix coveralls.html (цель на 100%)mix dialyzer (занимает некоторое время, и я ценю, что вы не можете проверить все версии Erlang/Elixir)Я считаю, что эта функция клиента завершается, если ваш PR полностью разрывается задом наперед или изменяет ранее существовавшее поведение/по умолчанию, я бы признателен за поддержку и ваши оправдания :).
Часть кода была заимствована у оригинального клиента Elixir-Riemann. Большая часть протобуфа исходит оттуда.
