carbon c relay
3.8.1 (28-04-2024)
carbon-c-relay -f config-file [ options ... ]
Carbon-C Lelayは、着信接続をリッスンし、その構成で定義された他のサーバーにメッセージを中継することにより、グラファイトメトリックを受け入れ、クレンジング、マッチ、書き換え、転送し、集約します。コア機能は、柔軟なルールを介して目的の宛先にメッセージをルーティングすることです。
Carbon-C-Lelayは、ファイルからルーティング情報を読み取る簡単なプログラムです。コマンドラインの引数では、このファイルの場所を設定するだけでなく、着信接続からデータを読み取り、適切な目的地に渡すために使用するディスパッチャー（ワーカースレッド）の量を設定できます。ルートファイルは、クラスターとマッチの2つの主要な構成要素をサポートしています。ホストデータメトリックの最初の定義グループは送信できます。後者は、どのメトリックをどのクラスターに送信するかを定義します。集約ルールは一致と見なされます。書き換えは、構成に表示されるポイントでメトリックに直接影響するアクションです。
リレーで受信したすべてのメトリックについて、クレンジングが実行されます。次の変更は、一致する前に実行されます。
[0-9a-zA-Z-_:#]にないと定義されていますが、コマンドラインでオーバーライドできます。タグ（存在し、許可されている場合）はこの方法で処理されないことに注意してください。 これらのオプションは、炭素C溶接の動作を制御します。
-v ：バージョン文字列と終了を印刷します。
-d ：デバッグモードを有効にすると、これは統計をSTDOUTに印刷し、通常は冗長であるリレーで遭遇するいくつかの状況に関する追加のメッセージを印刷します。 -t （テストモード）と組み合わせると、これはスタブルートと一貫したハッシュリングの内容も印刷します。
-s ：送信モードを有効にします。このモードでは、内部統計は生成されません。代わりに、キューの圧力とメトリックドロップがstdoutで報告されます。このモードは、「ジョブは（一連の）メインリレーに転送するためだけの提出リレーとして使用する場合に役立ちます。この場合の提出リレーに関する統計は不要であり、すべてのホストでローカルで使用される場合、例えば、メトリックの非決定的な洪水を簡単に引き起こす可能性があります。
-S ：統計の現在の状態が報告される1秒ごとにiostatのようなモードを有効にします。これは、送信モード-sを意味します。
-t ：テストモード。このモードはまったくルーティングを行いませんが、代わりにstdinからの入力を読み取り、ロードされた構成を考慮してどのようなアクションが実行されるかを印刷します。このモードは、正規表現の構文などのリレールートのテストに非常に役立ちます。また、複雑な構成でルーティングがどのように適用されるかについての洞察を与えることもできます。 -tが繰り返されると、リレーは妥当性の構成のみをテストし、その後すぐに終了します。標準出力はこのモードで抑制されているため、スタートスクリプトが（新しい）構成をテストするのに最適です。
-f config-file ： config-fileから構成を読み取ります。構成は、クラスターとルートで構成されています。このファイルのオプションと構文の詳細については、構成構文を参照してください。
-l log-file ：メッセージを書くためにログファイルを使用します。このオプションがなければ、リレーはstdoutとstderrの両方に書き込みます。ファイルにログすると、すべてのメッセージがSTDOUTに送信されたときにMSGが付いており、 STDERに送信されたときにERR付いています。
-pポート：ポートポートの接続を聞いてください。ポート番号は、 TCP 、 UDP 、 UNIX socketsの両方に使用されます。後者の場合、ソケットファイルにはポート番号が含まれています。ポートは2003年にデフォルトであり、元のcarbon-cache.pyでも使用されています。これはデフォルトにのみ適用されることに注意してください。 listenディレクティブが設定にある場合、この設定は無視されます。
-wワーカー：労働者数のスレッドを使用します。労働者のデフォルト数は、検出されたCPUコアの量に等しくなります。多くのコアマシンで、またはトラフィックが低いときにこの数を減らすことは理にかなっています。
-b batchsize ：リモートサーバーに送信されたメトリックの量を一度に設定してバッチサイズに設定します。リレーがメトリックをサーバーに送信すると、そのサーバーを待っているメトリックの保留中のキューからbatchsizeメトリックを取得し、それらを1つずつ送信します。バッチのサイズは、送信パフォーマンスに最小限の影響を与えますが、キューのロックコンテンションの量を制御します。デフォルトは2500です。
-q Queuesize ：リレーがメトリックを送信する構成からの各サーバーには、それに関連付けられたキューがあります。このキューにより、混乱とバーストを処理できます。このキューのサイズはキュースズに設定され、その量のメトリックをオーバーフローする前にキューに保存することができ、リレーはメトリックの削除を開始します。キューが大きいほど、より多くのメトリックを吸収できますが、リレーではより多くのメモリが使用されます。デフォルトのキューサイズは25000です。
-Lストール：リレーがサーバーのメトリックを削除し始める前に、最大の屋台をストールに設定します。キューがいっぱいになると、リレーは、このイベントのクライアント（リレーに書き込み）を信号するためにストールと呼ばれるメカニズムを使用します。特に、クライアントが非常に短い時間（バースト）で大量のメトリックを送信するとき、ストールはメトリックのドロップを避けるのに役立ちます。クライアントは少し遅くする必要があるため、多くの場合、 nc （1）でファイルを猫にするとき）。ただし、この動作は、簡単に止めることができない作家を人為的に失速させることもできます。このため、屋台は0〜15に設定でき、各ストールはクライアントに約1秒かかることがあります。デフォルト値は4に設定されています。これは、クライアントの中程度の遅延でメトリックを失わないための時折の混乱シナリオと最大の取り組みを目的としています。
-C cacertpath ：指定されたパスまたはファイルからCA証明書（TLS/SSL接続で使用するため）を読み取ります。指定されていない場合、デフォルトの場所が使用されます。ピアの厳格な因かvisitionが実行されるため、自己署名証明書を使用する場合は、デフォルトの場所にCA証明書を含めるか、このオプションを使用して証明書へのパスを提供してください。
-Tタイムアウト：サーバー接続に使用されるミリ秒単位でIOタイムアウトを指定します。デフォルトは600ミリ秒ですが、ターゲットサーバーにWANリンクを使用すると増加する必要がある場合があります。接続タイムアウトの値が比較的低いため、リレーはサーバーをすばやく確立できます。そのため、キューが高くなる前にキックするためのフェールオーバー戦略として。
-c chars ：メトリックで許可されている[A-Za-z0-9]の隣にある文字を定義します。このリストにないキャラクターは、 _ （アンダースコア）にリレーに置き換えられます。許可された文字のデフォルトリストは-_：＃です。
-m長さ：メートルの名前を、ほとんどの長さの長さで制限します。これよりも大きいメトリック名を含む行は廃棄されます。
-M長さは、ほとんどの長さのバイトの線に入力を制限します。余分なラインは廃棄されます。 -mこの値よりも小さくする必要があることに注意してください。
-H hostname ： gethostname （3）への呼び出しによって決定されたホスト名をオーバーライドします。ホスト名は、主に統計メトリックcarbon.relays.<hostname>.<...>
-Bバックログ：TCP接続を設定して、バックログをバックログ接続にリッスンします。デフォルト値は32ですが、多くの同時接続を受信するサーバーでは、クライアントの接続拒否エラーを回避するために、この設定を増やす必要がある可能性があります。
-U Bufsize ：TCPシナリオとUDPシナリオの両方に対して、ソケット送信/受信バッファサイズをバイトでセットします。設定すると、OSデフォルトが使用されます。最大値はOSによっても決定されます。サイズは、フラグSO_RCVBUFおよびSO_SNDBUFを使用してSetSockoptを使用して設定されます。このサイズの設定は、大量のシナリオに必要になる場合があります。これには、 -Bが適用される場合があります。 NetStatからRECV-Qと受信エラー値を確認すると、バッファーの使用に関する良いヒントが得られます。
-E ：アイドル接続の切断を無効にします。デフォルトでは、リレーは10分後にアイドルクライアント接続を切断します。これは、障害のあるまたは悪意のあるクライアントが接続を閉じずに接続を開き続けている場合に、リソースが詰まるのを防ぐために行います。通常、ファイル記述子の不足を防ぎます。ただし、一部のシナリオでは、アイドル接続を切断することは望ましくないため、このフラグを渡すとこの動作が無効になります。
-D ：起動後に背景にdeAmonise。このオプションには、 -lおよび-Pフラグも設定する必要があります。
-P pidfile ：リレープロセスのpidをpidfileというファイルに書き込みます。これは、特にINITマネージャーと組み合わせてデーモン化する場合に役立ちます。
-Oしきい値：ルールセットを最適化しようとする前に見つけるルールの最小数。デフォルトは50です。オプティマイザーを無効にし、 -1を使用して、常にOptimiser使用0実行します。 Optimiserは、表現のマッチングに過度の時間を費やすことを避けるために、ルールをグループ化しようとします。
構成ファイルは次の構文をサポートします。ここでは、コメントは#文字から始まり、任意の位置に任意の位置に表示され、その行の最後まで入力を抑制できます。
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クラスターを除き、1つ以上のホストを指しています。 host 、IPv4またはIPv6アドレス、またはホスト名です。ホストの後にオプションが続くため:ポート、IPv6アドレスを誤って解釈しないために、ポートを指定する必要があるか、括弧で囲まれたIPv6アドレスなど、 [::1] 。オプションのtransportおよびproto条項を使用して、接続を圧縮または暗号化層にラップしたり、UDPまたはTCPの使用を指定してリモートサーバーに接続できます。接続が省略された場合、デフォルトはプレーンTCP接続になります。 type 、現時点でのみlinemodeあることができます。たとえば、Pythonのピクルスモードはサポートされていません。
DNSホスト名は、RFC 3484の優先ルールに従って単一のアドレスに解決されます。ANY_OF、 failover 、 forwardクラスターany_of 、複数のアドレスに解決するホスト名の拡張を可能にする明示的なuseallフラグがあります。このオプションを使用して、任意のタイプの各アドレスがクラスター宛先になります。これは、たとえば、IPv4アドレスとIPv6アドレスの両方が追加されることを意味します。
クラスタータイプの2つのグループ、シンプルな転送クラスターと一貫したハッシュクラスターがあります。
forwardおよびfileクラスター
forwardクラスターとfileクラスターは、受信したすべてを定義されたメンバー（ホストアドレスまたはファイル）に送信するだけです。クラスターに複数のメンバーがいる場合、すべての受信メトリックがすべてのメンバーに送信され、基本的にすべてのメンバーの入力メトリックストリームを複製します。
any_ofクラスター
any_ofクラスターはforwardクラスターの小さなバリアントですが、入力メトリックをすべての定義されたメンバーに送信する代わりに、各入っているメトリックを定義されたメンバーの1人のみに送信します。これの目的は、メンバーのいずれかがメトリックを受け取ることができるロードバランスのシナリオです。 any_ofが示唆するように、メンバーのいずれかが到達不能になると、残りの利用可能なメンバーはすぐにメトリックの完全な入力ストリームを受け取ります。これは、4人のメンバーが使用されると、それぞれが入力メトリックの約25％を受け取ることを意味します。 1人のメンバーが利用できなくなった場合（たとえば、ネットワーク中断、またはサービスの再起動）、残りの3人のメンバーはそれぞれ約25％ / 3 = 〜8％多くのトラフィック（33％）を受け取ります。または、合計入力の1/3を受け取ります。クラスター容量を設計するとき、最も極端な場合には、最終的なメンバーがすべての入力トラフィックを受け取ることを考慮する必要があります。
特に、クラスターが他のリレーやキャッシュを指している場合、 any_ofクラスターは役立ちます。他のリレーとともに使用すると、効果的に負荷バランスがあり、すぐにターゲットの能力を持たないように適応します。キャッシュで使用すると、 any_ofどのように機能するかについては、非常に適切な詳細があります。このルーターの実装は、利用可能なメンバーに対するロビンを丸くすることではなく、一貫したハッシュ戦略を使用して、同じメトリックを常に同じ宛先に提供します。これにより、キャッシュに役立ち、（単一のキャッシュから）コミットされていないデータポイントを簡単に取得できますが、それでもキャッシュの巻き戻しが可能になります。メンバーが利用できなくなると、ハッシュの宛先は変更されませんが、使用できないノードに向けたトラフィックが利用可能なノードに均等に広がっています。
failoverクラスター
failoverクラスターはany_ofクラスターのようなものですが、サーバーが定義されている順序に固執します。これは、サーバー間で純粋なフェールオーバーシナリオを実装するためです。すべてのメトリックは最大1人のメンバーに送信されるため、ハッシュまたはバランスは行われていません。たとえば、2人のメンバーを持つfailoverクラスターは、最初のメンバーが利用できなくなった場合にのみメトリックを2番目のメンバーに送信します。最初のメンバーが戻るとすぐに、すべてのメトリックが再び最初のノードに送信されます。
carbon_chクラスター
carbon_chクラスターは、元のカーボンPythonリレーで使用されている一貫したハッシュアルゴリズムに従って責任のあるメンバーにメトリックを送信します。複数のメンバーが1より高い値に設定されている場合、複数のメンバーが可能です。 dynamic設定すると、サーバーのいずれかの障害がそのサーバーのメトリックが削除されませんが、代わりにメトリックが失われないように、展開できないメトリックがクラスター内の他のサーバーに送信されます。これは、複製が1の場合に最も便利です。
メトリックが分散される方法を定義するハッシュリングの計算は、サーバーホスト（またはIPアドレス）とメンバーのオプションinstanceに基づいています。これは、異なるポートでcarbon_ch 2つのターゲットを使用するが、同じホストで同じハッシュキーにマッピングされることを意味します。つまり、メトリックの分布は行われません。インスタンスは、その状況を改善するために使用されます。インスタンスはポートの後にメンバーに追加され、例：たとえばaなど、等しいサイン127.0.0.1:2006=a ）で区切られます。インスタンスは、元のPythonカーボンキャッシュによって導入された概念であり、それらの構成に従って使用する必要があります。
一貫したハッシュは、クラスターからメンバーを削除することにより、すべてのメトリックがメンバーに完全に再マッピングされることはないという意味で一貫していますが、代わりに削除されたメンバーから残りのすべてのメンバーにメトリックを追加するだけで、ほぼそれぞれ公正な共有を取得します。もう1つの方法は、メンバーが追加されると、各メンバーがそのメトリックのサブセットが新しいメンバーに宛てられているのを見る必要があります。これは、通常のハッシュよりも重要な利点であり、メンバーの各削除または追加（たとえば、IPアドレスまたはホスト名の変更を介して）は、利用可能なすべてのメトリックにわたってすべてのメトリックの完全な再マッピングを引き起こします。
fnv1a_chクラスター
fnv1a_chクラスターは、Carbon-C Lelayによって導入されたcarbon_chの互換性のない改善です。 carbon_chが使用するMD5ハッシングよりも速い別のハッシュテクニック（FNV1A）を使用します。さらに重要なことは、 fnv1a_chクラスターはホストとポートの両方を使用してメンバーを区別します。これは、ポートで区切られた同じホストに複数のターゲットがライブする場合に役立ちます。
instanceプロパティはこの方法でfnv1a_chでは必要ないため、ホスト：ポートストリングを完全にオーバーライドするために使用されます。これは重要な側面です。ハッシュキーは、メンバーが受信するメトリックを定義するためです。このようなオーバーライドは、機械が新しいハードウェアに移行されたときの古いIPアドレスを装着するなど、多くのものを可能にします。この例は、アドレス5のマシンがアドレス2にあるマシンのメトリックを受信するように、 10.0.0.5:2003=10.0.0.2:2003 :2003です。
この方法でインスタンスを使用することは、既存のクラスターでの移行を実行するのに非常に役立ちますが、新たにクラスターをセットアップするために、インスタンスが初日からインスタンスを使用して、受信するメトリックからマシンの場所を取り外してこの作業を回避できます。たとえば、 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac =4D79D13554FA1301476C1F9FE968B0ACここで、インスタンスとしてランダムなハッシュが使用されています。これにより、ランダムハッシュが保持されていると仮定して、レガシーが表示されていることに対処することなく、何度もデータを受信するサーバーのポートおよび/またはIPアドレスを変更できます。インスタンス名は完全なハッシュ入力として使用されるため、 a 、 bなどのインスタンスは、ハッシュの入力がほとんどないため、ハッシュ分布が不十分になる可能性が高いことに注意してください。そのため、上記の例で使用されるランダムハッシュなど、より長いハッシュ分布挙動など、より長くてほとんど異なるインスタンス名を使用することを検討してください。
jump_fnv1a_chクラスター
jump_fnv1a_chクラスターは、前の2つのように一貫したハッシュクラスターでもありますが、メンバーホスト、ポート、またはインスタンスをまったく考慮していません。つまり、このクラスタータイプは、メンバーが定義されている順序を調べます。この順序の詳細については、以下も参照してください。これがあなたに役立つかどうかはあなたのシナリオに依存します。前の2つの一貫したハッシュクラスタータイプとは対照的に、ジャンプハッシュは、クラスターで定義されているメンバーに対してほぼ完全なバランスをとっています。ただし、これは、すべてのメンバーにわたってすべてのメトリックを完全に再マッピングすることなく、クラスターからメンバー以外のメンバーを削除できないことを犠牲にします。これが基本的に意味するのは、このハッシュは、古いノードが削除されることはなく、代わりに交換される一定または成長しているクラスターで使用しても問題ありません。
古いノードの削除が行われるクラスターがある場合、ジャンプハッシュはあなたには適していません。 Jump Hashは、順序付けられたリストでサーバーで動作します。この順序は重要であるため、以前のクラスタータイプで使用されているインスタンスを使用して明示的にすることができます。メンバーにインスタンスが与えられると、ソートキーとして使用されます。このインスタンスがないと、順序は構成ファイルに記載されているとおりです。これは、いくつかの構成管理ソフトウェアによって生成された場合に変更される傾向があります。そのため、ジャンプハッシュの正しいノードが何であるかを明示するように、インスタンスでサーバーの順序を修正することはおそらく良い習慣です。これらには数字を使用するだけですが、1、2、10の並べ替えが1、10、2になることに注意してください。そのため、代わりにP0001、P0002、P0010のようなものを使用する方が良いです。
一致ルールは、着信メトリックを1つ以上のクラスターに向ける方法です。一致ルールは、ファイルで定義されているため、上から下部まで処理されます。同じルールで複数の一致を定義することが可能です。各マッチルールは、1つ以上のクラスターにデータを送信できます。一致するルールは、 stopキーワードが追加されていない限り「転倒」するため、慎重に作成された一致式を使用して、複数のクラスターまたは集約をターゲットにします。この機能により、メトリックを複製することができ、 stopキーワードの慎重な注文と使用状況で特定のメトリックを代替クラスターに送信できます。特別なクラスターのblackhole 、それに送られたメトリックを破棄します。これは、特定の場合に不要なメトリックを除去するのに役立ちます。他の一致が同じデータを受け入れる場合、メトリックを捨てることは無意味であるため、ブラックホールクラスターの目的地としての一致は暗黙のstop持っています。 validation条項は、正規表現の形でデータ（メトリックの後に来るもの）にチェックを追加します。この式が一致すると、試合ルールは、検証条項が存在しないかのように実行されます。ただし、失敗した場合、一致ルールは中止され、メトリックは目的地に送信されません。これはdrop動作です。 logを使用すると、メトリックはstderrに記録されます。丸太の洪水を避けるために、後者には注意を払う必要があります。検証句が存在する場合、目的地が存在する必要はありません。これにより、グローバル検証ルールを適用できます。検証が完了する前にクレンジングルールが適用されるため、データには空間が複製されないことに注意してください。句route using 、一貫したハッシュルーチンへの入力に使用されるキーに一時的な変更を実行するために使用されます。主な目的は、適切なデータが必要な集約インスタンスに送信されるようにトラフィックをルーティングすることです。
ルールを書き直し、着信メトリックを一致させるために入力として正規表現を取り、それらを目的の新しいメトリック名に変換します。置換では、入力正規表現で定義されたキャプチャグループと一致することが許可されています。 server.(x|y|z). egのrole.1.代替で。必要に応じて、 g{1}100などの整数が続くnの代わりにg{n}の表記を使用できます。いくつかの警告は、書き換えルールの現在の実装に適用されます。まず、構成ファイルの位置は、書き換えがいつ実行されるかを決定します。書き換えは、書き直しが元の名前と一致する前のそのような一致ルールが、書き直しが元の名前と一致しないため、そのような一致ルールが施されているため、その場所に行われます。連続bて複数の書き換えルールa行われる可能性b cため、注文には注意が必要です。現在の実装の2番目の警告は、新たに着信するメトリックのように、書き換えられたメトリック名が清掃されていないことです。したがって、置換文字列が作成されて作成されている場合、ダブルドットと潜在的な危険な文字が表示される可能性があります。メトリックがきれいであることを確認することは、作家の責任です。これがルーティングの問題である場合、すべてのメトリックをルーティングを実行する別のインスタンスに転送する書き換えのみのインスタンスを持つことを考慮することができます。明らかに、2番目のインスタンスは、メトリックが入るとメトリックをクレンジングします。バックレファレンス表記は、バックスラッシュの直後に続くアンダースコア（ _ ）およびカレット（ ^ ）シンボルを使用して、交換用文字列を下ろして大文字にすることができます。たとえば、 role._1.置換が1の内容を小文字にするため。ドット（ . ）は、同様の方法で使用するか、アンダースコアまたはカレットの後に使用して、ドットを置換のアンダースコアに置き換えることができます。これは、メトリックがグラファイトに送信される状況では便利です。
定義された集約は、一致ルールと同様に、1つ以上の通常の見方によって表される1つまたは複数の入力メトリックを取ります。着信メトリックは、間隔で定義された一定期間にわたって集約されます。イベントが少し後に到着する可能性があるため、新しいエントリを追加することは許可されていないため、秒単位の有効期限は、集約を最終的に考慮する必要があることを定義します。集約に加えて、複数の集約を計算できます。それらは同じまたは異なる集約タイプである可能性がありますが、一意の新しいメトリックに書き込む必要があります。メトリック名には、書き換え式のようなバック参照を含めることができ、多くの集計で生成される強力な単一集約ルールを可能にします。句send toされない場合、作成されたメトリックが外部から提出されたかのようにリレーに送信されるため、それらには一致ルールと集約規則が適用されます。この方法でループが回避されるように注意する必要があります。このため、可能な限り出力トラフィックを指示するために、 send toの使用が奨励されます。マッチルールの場合と同様に、複数のクラスターターゲットを定義することができます。また、一致ルールと同様に、一致プロセスでのメトリックのフローを制御するためにstopキーワードが適用されます。
構築するsend statistics toは非推奨であり、次のリリースで削除されます。代わりに特別なstatisticsコンストラクトを使用してください。
statistics構造は、リレーによって生成される（内部）統計に関するいくつかのことを制御できます。ターゲットsend to 、特定の宛先クラスターに統計を送信することにより、ルーターループを回避するために使用できます。デフォルトでは、メトリックにはcarbon.relays.<hostname> 。ここで、ホスト名は起動時に決定され、 -H引数を使用してオーバーライドできます。このプレフィックスは、ルールターゲットの書き換えと同様の句prefix withを使用して設定できます。この場合の入力一致は、ホスト名の事前に設定された正規表現^(([^.]+)(..*)?)$です。そのため、デフォルトのプレフィックスがcarbon.relays..1で設定されていることがわかります。これは、書き換えルールからの代替ドット付きのドット付き交換機能を使用することに注意してください。入力式を考える2 、次の一致グループが利用3 1 。特定のシナリオの場合は、デフォルトをcarbon.relays._2デフォルトでは、メトリックは60秒ごとに提出されます。これは、 submit every <interval> seconds reset counters after interval >秒節ごとに送信された句を使用して変更することができます。
ポートとプロトコルリレーは、 listenディレクティブを使用して着信接続をリッスンする必要があります。現在、すべてのリスナーはlinemodeタイプである必要があります。オプションの圧縮または暗号化ラッピングは、IPアドレスで与えられたポートおよびオプションインターフェイス、またはファイルごとにUNIXソケットに指定できます。インターフェイスが指定されていない場合、利用可能なすべてのIPプロトコルの任意のインターフェイスが想定されます。 listenディレクティブが存在しない場合、リレーはTCPとUDPのポート2003のデフォルトリスナー、さらにUNIX Socket /tmp/.s.carbon-c-relay.2003を使用します。これは通常、IPv6対応システムで5人のリスナーに拡張されます。デフォルトは、v3.2より前のバージョンの動作と一致します。
構成が非常に長くなった場合、または個別のファイルでより適切に管理されている場合、 includeディレクティブを使用して別のファイルを読み取ることができます。指定されたファイルは整備されており、包含時にルーター構成に追加されます。最終結果は、1つの大きなルート構成です。複数のincludeステートメントは、構成ファイル全体で使用できます。ポジショニングは、通常どおりルールの順序に影響を与えます。再帰的な包含（含まれるファイルからinclude ）がサポートされていることに注意してください。現在、インクルージョンループの保護措置は存在しません。価値のあるものについては、この機能は、単純な構成ファイル（例えば、それらにincludeていない）で使用するのが最適です。
Carbon-C Lelayは時間の経過とともに進化し、ツールが安定しており、仕事に適していることが判明したため、需要の高い機能を拡大しました。以下に、リレーで使用できるコンストラクトの注釈付き例に従ってください。
クラスターは、必要に応じて定義できます。彼らは一致ルールからデータを受け取り、そのタイプはクラスターのメンバーが最終的にメトリックデータを取得するかを定義します。最も単純なクラスターフォームは、 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;
これにより、2つのサーバーが使用されるマルチパスシナリオが実装されます。それらの間の負荷は広がりますが、それらのいずれかが失敗した場合、すべてのメトリックが残りのメトリックに送信されます。これは通常、アップストリームリレー、または同じマシンで実行されている炭素キャッシュプロセスのバランスをとるのにうまく機能します。たとえば、ローリングの再開のためにメンバーが利用できなくなった場合、他のメンバーはトラフィックを受け取ります。最初のサーバーがダウンしている場合にのみ使用される真のフェールオーバーが必要な場合は、次のことを実装します。
cluster try-first-then-second
failover 10.1.0.1:2010 10.1.0.1:2011;
これらのタイプは、2つの一貫したハッシュクラスタータイプとは異なります。
cluster graphite
carbon_ch
127.0.0.1:2006=a
127.0.0.1:2007=b
127.0.0.1:2008=c
;
この例のメンバーが失敗した場合、そのメンバーに送られるすべてのメトリックはキューに保持され、メンバーが戻るのを待っています。これは、同じメトリックが常に同じサーバー上にあることが望ましいカーボンキャッシュマシンのクラスターに役立ちます。 carbon_chクラスタータイプは、Carbon Lelayの一貫したハッシュと互換性があり、炭素関連の既存のクラスターに使用できます。ただし、新しいクラスターの場合、 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のクラスタータイプは異なることに注意してください。各着信メトリックは、3つのクラスターすべての2人のメンバーに送信され、合計6つの宛先に複製されます。クラスターごとに、宛先メンバーは個別に計算されます。クラスターやメンバーの故障は、すべてが個別のキューを持っているため、他のクラスターには影響しません。上記の例は、各DCの3つの一致ルール、または3つのDCすべてに1つの一致ルールを使用して記述することもできます。違いは主にパフォーマンスにあり、着信メトリックを式と一致させる必要がある回数があります。この例では、 dc-new Matchルールのstopルールは厳密に必要ではありません。ただし、一致が特定のサブセットをターゲットにする場合、例えば^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;
ご覧のとおり、DC2-SYSのマッチルールでstopことなく、すべてのメトリックが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;
この例では、古いクラスターは、新しいクラスターに望ましくないメトリックを受け取ります。したがって、ルールが発生する順序は、実行にとって重要です。
検証を使用して、メトリックのデータが予想どおりであることを確認できます。単なる数値（浮動小数点なし）値のグローバル検証は次のとおりです。
match *
validate ^[0-9]+ [0-9]+$ else drop
;
（スペースのsスラッシュを使用した脱出に注意してください。代わりに、これは[:space:]されたRegex実装に依存する場合があります。）
検証条項はすべてのマッチルールに存在する可能性があるため、原則として、以下は有効です。
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;
前の2つの例では、動作は異なることに注意してください。クラスターsend toが指定されていない場合、検証エラーにより、一致がstopキーワードが存在するように動作します。同様に、検証が通過すると、次のルールで処理が続きます。 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.
接続
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
Fabian Groffen <[email protected]>
All other utilities from the graphite stack.
This project aims to be a fast replacement of the original Carbon relay. carbon-c-relay aims to deliver performance and configurability. Carbon is single threaded, and sending metrics to multiple consistent-hash clusters requires chaining of relays. This project provides a multithreaded relay which can address multiple targets and clusters for each and every metric based on pattern matches.
There are a couple more replacement projects out there, which are carbon-relay-ng and graphite-relay.
Compared to carbon-relay-ng, this project does provide carbon's consistent-hash routing. graphite-relay, which does this, however doesn't do metric-based matches to direct the traffic, which this project does as well. To date, carbon-c-relay can do aggregations, failover targets and more.
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.
