riemannx
v4.2.0
プールボーイの信頼性とエリクサーの素晴らしいパワーに基づいて構築された、完全に紹介されたライマンクライアント！
RiemannxはElixirに組み込まれたRiemannクライアントであり、現在、ElixirでUDPおよびTLS（およびTCP）をサポートする唯一のクライアントです。また、いずれかのトランスポートで動作するバッチモードもあります。
TCPとUDPの両方を最大限に活用する実験的な組み合わせオプションがあります。統合モードでは、UDPが好まれるアプローチですが、メッセージサイズが最大UDPサイズを超える場合、TCPが使用されます。
いつものように、Riemannxを使用する前に必要な前提条件があります。これらのほとんどは明らかです（Elixir、Erlang）が、どのバージョンがテストおよびサポートされているかに関するいくつかの情報が含まれています。
現在、すべてのErlangバージョン〜18がサポートされています。これには20、20.1がまだテストされていませんが、私はそこに大きな問題はないと予測しています。
Travisによるテスト：
18.019.320.0私は1.3.4以降から互換性を確保しようとしましたが、必要に応じて引き続きそうします。テストされた組み合わせ：
18.0 Elixir： 1.3.4 / 1.4.5 / 1.5.119.3 Elixir： 1.3.4 / 1.4.5 / 1.5.120.0 Elixir： 1.4.5 / 1.5.1よくあることですが、Riemannの詳細については、http://riemann.ioにアクセスしてください。
クライアントは、 0.2.11でのみ戦闘テストを受けています。クライアントのバージョン4.0.0から、 0.2.13より古いRiemannのバージョンを使用し、時間フィールドを自分で設定していない場合、 use_micro falseに設定する必要があります。 0.3.0で動作するはずですが、以前はテストされていません（統合テストに取り組みたい人は誰でも大いに感謝します）。
インストールは、他のElixirライブラリと同じように行われ、ミックスファイルに追加すると、残りは履歴です。
def deps do
[ { :riemannx , "~> 4.0" } ]
endmix.exsファイルのアプリケーションリストにriemannxを追加してください。これにより、アプリから開始され、リリースに含まれることが保証されます（リリースマネージャーを使用する場合）：
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は2つのsend方法をサポートします。1つは非同期の同期をサポートします。
同期送信を使用すると、送信中に発生する可能性のあるエラーを処理できます。以下は、このエラーがどのように見えるかと成功した送信時に何が起こるかを示す例です。
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!注：労働者がそれを送ることができない場合、死亡して再起動して、「正しい」状態に戻る機会を与えます。非同期送信では、これはパターンマッチングによって行われます：sendコマンドでOK、synchronous sendの場合、返品値がエラーである場合、結果を返す前にワーカーを殺します。
TLSサポートを使用すると、Riemannサーバーとの安全なTCP接続を使用して、これをセットアップする方法の詳細については、こちらをご覧ください。
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秒ごとです。バッチングはそうです：
キューにあるものは何でも、すべての間隔が送信されます。
キューのサイズが設定されたバッチサイズに達すると、間隔に関係なくフラッシュされます。
checkout_timerが:infinityのように設定されていない限り、バッチがバッチを処理することができない場合、バッチはドロップされます
:batch ：、 batch_settings: batch_settingsの内部には、基礎となる接続のタイプを指定できます（ :tcp 、 :udp 、 :combined 、 :tls ）。いつものように組み合わされているのはデフォルトです。
オプションで、バッチ制限番号を指定できます（ :limit ）。設定されている場合、バッチキューに指定されたバッチの量がある場合、つまりlimit * batch_size 、少なくとも1つのバッチが送信されるまで新しいイベントが削除されます。デフォルト値は:infinityです
Riemannのバージョン0.2.13から、マイクロ秒で時間を設定することができました-Riemannxはtime_microsフィールドをサポートおよび使用するようになりました（時間またはtime_microsフィールドを自分で設定していない限り、Riemannxはそれを上書きしません）。 Riemannの古いバージョンを使用している場合、秒フィールドのみを使用します。
注：時間とtimeの両方を設定した場合、Riemannはマイクロタイムを優先し、Riemannxはどちらも上書きしません。
それはそれよりもファンシーに聞こえますが、基本的には、指定していない場合、イベントにホストエントリを追加する機能を説明しています。ホストを指定するには3つの方法があります。
イベントを送信する前にそれを行います（キーワードリストのホストキーを追加）
configに:event_hostキーを追加します。
riemannxを使用して:inet.gethostname() - それを一度だけ呼び出して結果を保存します。すべてのイベントで呼び出されません。
最後の2つのオプションは、コードを清潔に保つため、最も有利です。
このクライアントでは、労働者に優先事項を設定する機会があり、Riemannに統計を送信することを優先事項またはそれ以下にすることができます。
優先順位の設定の違いは、ハードウェアと他の優先順位を一般的に設定する方法に大きく依存します。http://erlang.org/doc/man/erlang.html#process_flag2に詳細をご覧ください。
優先順位を設定しようとする場合：Max Riemannxは、それがひどいアイデアであるため、RuntimeErrorを上げます。また、試してみると、RuntimeErrorを上げます。
3.0に移行することは、基本的に構成レイアウトを変更するだけの場合にすぎません。これを除いて、同じオプションがすべて存在します。これは、タイプレベルで労働者をよりコントロールできるようになりました。たとえば、TCPワーカーの小さなプールとより大きなUDPワーカープールを使用する場合は、（2xどんなプールであったとしても2x）。
この新しいレイアウトはここで見ることができます：config
何も意味がない場合は、問題を自由に開いてください。そうすれば、不明瞭さを修正するためにREADMEを拡張できます。
他の場所に設定を保存する場合は、たとえばデータベースから設定を読み取るバックエンドを作成できます。必要なコールバックのデフォルト設定モジュールを見てください。
これは、会社全体の設定を1か所に保存する場合に役立ちます。
質問がある場合は、お気軽に問題を開いてください。
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クライアントから借用されています。プロトブフのほとんどはそこから来ています。
