carbon c relay
3.8.1 (28-04-2024)
carbon-c-relay -f配置文件[ options ... ]
Carbon-C-Relay接受，清潔，匹配，重寫，向前和聚集石墨指標，通過聆聽傳入的連接並將消息傳遞給其配置中定義的其他服務器。核心功能是通過靈活的規則將消息路由到所需目的地。
Carbon-C-Relay是一個簡單的程序，可以從文件中讀取其路由信息。命令行參數允許設置此文件的位置，以及用於讀取來自傳入連接的數據並將其傳遞到正確目的地的數據的調度器（工作線程）的數量。路由文件支持兩個主要結構：群集和匹配。可以將第一個定義的主機數據指標定義為，後者定義了哪些指標應發送到哪個群集。聚合規則被視為匹配。重寫是在配置中出現的點直接影響度量的動作。
對於繼電器收到的每一個指標，都要進行清潔。在任何匹配之前，匯總或重寫規則都會看到以下更改。
[0-9a-zA-Z-_:#]中，但可以在命令行上覆蓋。請注意，標籤（當前允許時）未通過這種方式處理。 這些選項控制碳-C-Relay的行為。
-v ：打印版本字符串和退出。
-d ：啟用調試模式，這將打印統計信息以說明並打印有關繼電器遇到的某些情況的額外消息，該接力賽通常會冗長而無法啟用。當與-t （測試模式）結合使用時，這還打印了存根路由和一致的錘擊環內容。
-s ：啟用提交模式。在此模式下，未生成內部統計信息。取而代之的是，在Stdout上報告了隊列壓力和指標下降。當用作提交繼電器時，此模式很有用，而“作業”只需轉發到（一組）主繼電器。在這種情況下，不需要有關提交繼電器的統計信息，並且在每個主機上使用在每個主機上時，都可能很容易導致非態度的指標洪水。
-S ：啟用類似IOSTAT的模式，其中每一秒都會報告統計的當前狀態。這意味著提交模式-s 。
-t ：測試模式。此模式根本不執行任何路由，而是從stdin讀取輸入，並在加載配置中打印將採取哪些操作。此模式對於測試正則表達語法等測試中繼路線非常有用。它還允許深入了解如何以復雜的配置應用路由，因為它也顯示了進行的重寫和聚合。重複-t時，繼電器將僅測試配置的有效性並立即退出。在此模式下，任何標準輸出都會被抑制，使其非常適合啟動標記測試（新）配置。
-f config-file ：從config-file讀取配置。配置由集群和路線組成。有關此文件的選項和語法的更多信息，請參見配置語法。
-l日誌文件：使用日誌文件來編寫消息。沒有此選項，繼電器都將其寫入Stdout和Stderr 。登錄文件時，將所有消息發送到STDOUT時，都將其前綴為MSG ，並在將它們發送到STDERR時ERR 。
-p端口：收聽端口端口上的連接。端口號用於TCP ， UDP和UNIX sockets 。在後一種情況下，套接字文件包含端口號。端口默認為2003年，該端口也由原始的carbon-cache.py使用。請注意，這僅適用於默認設置，當listen指令在配置中時，此設置將被忽略。
-w工人：使用工人的線程數量。默認工人數量等於檢測到的CPU內核的數量。在多核機上或流量較低時減少此數字是有意義的。
-b批量批量：設置一次發送到遠程服務器的指標數量以批量批量。當繼電器將指標發送到服務器時，它將從等待該服務器的指標排隊中檢索batchsize指標，然後一個接一個地發送。批次的大小對發送性能的影響最小，但它控制了隊列上的鎖定量。默認值為2500 。
-q隊列：從中繼將指標發送到的配置中的每個服務器都具有與之關聯的隊列。該隊列允許處理中斷和爆發。該隊列的大小將設置為排隊大小，這允許在溢出之前將該數量的指標存儲在隊列中，並且繼電器開始刪除指標。隊列越大，可以吸收更多的指標，但繼電器將使用更多的內存。默認隊列大小為25000 。
-L攤位：將最大攤位安裝到繼電器開始刪除服務器的指標之前。當隊列填充時，繼電器使用稱為Stalling的機制來發出此事件的客戶（寫入繼電器）的信號。特別是當客戶在很短的時間內發送大量指標（爆發）時，停滯可以幫助避免掉落指標，因為客戶只需要放慢速度，這在許多情況下是可能的（例如，用nc （1）鍵入文件時）。但是，這種行為也會阻礙，人為地拖延作家，無法輕易阻止這一點。為此，攤位可以設置為0到15 ，每個攤位可以在客戶端上花費大約1秒鐘。默認值設置為4 ，該值旨在偶爾出現的破壞情況和最大努力，以免客戶速度減慢客戶端。
-C cacertpath ：從給定路徑或文件中讀取CA CERT（與TLS/SSL連接一起使用）。如果沒有給出，則使用默認位置。執行對等的嚴格涉嫌，因此，使用自簽名證書時，請確保在默認位置包含CA CERT，或使用此選項提供證書的路徑。
-T超時：指定用於服務器連接的毫秒中的IO超時。默認值為600毫秒，但是當WAN鏈接用於目標服務器時可能需要增加。連接超時的相對較低的值允許繼電器快速建立服務器是無法實現的，因此，在隊列較高之前可以啟動的故障轉移策略。
-c chars ：定義[A-Za-z0-9]旁邊允許的指標允許的字符。該列表中未在此列表中的任何字符都用_ （下劃線）代替。允許字符的默認列表是-_：＃ 。
-m長度：限制最多長字節的度量名稱。任何包含大於此的公制名稱的行都將被丟棄。
-M長度將輸入限制為最多長字節的線。任何多餘的線將被丟棄。請注意， -m需要小於此值。
-H主機名：覆蓋主機名由用主機名調用gethostname （3）確定。主機名主要用於統計指標carbon.relays.<hostname>.<...>由繼電器發送。
-B積壓：設置TCP連接收聽積壓到積壓連接。默認值為32 ，但是在接收許多並發連接的服務器上，可能需要增加此設置，以避免拒絕客戶端的連接錯誤。
-U bufsize ：為TCP和UDP方案設置字節中的套接字發送/接收緩衝尺寸。尚不設置時，使用OS默認值。最大值也由OS確定。使用標誌so_rcvbuf和so_sndbuf使用setSockopt設置尺寸。設置此尺寸可能是大容量場景所需的，也可能適用-B 。檢查RECV-Q和從NetStat中的接收錯誤值提供了有關緩衝使用情況的良好提示。
-E ：禁用斷開怠速傳入連接的連接。默認情況下，繼電器在10分鐘後斷開閒置客戶端連接。這樣做是為了防止當故障或惡意客戶端不關閉連接時，資源堵塞。它通常會阻止文件描述符未用完。但是，對於某些方案，斷開連接的閒置連接並不可取，因此傳遞該標誌將禁用此行為。
-D ：啟動後將刪除到後台。此選項也需要設置-l和-P標誌。
-P pidfile ：將繼電器過程的PID寫入稱為pidfile的文件。當與初始經理結合使用時，這特別有用。
-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的泡菜模式。
根據RFC 3484中的首選項規則，將DNS主機名解析為單個地址。ANY_OF， any_of failover和forward簇具有明確的useall標誌，該標誌可以擴展到主機名解決到多個地址。使用此選項，任何類型的每個地址都會成為群集目標。例如，這意味著添加了IPv4和IPv6地址。
有兩組聚類類型，簡單的轉發簇和一致的散列簇。
forward和file群集
forward和file簇只需將收到的所有內容髮送給定義的成員（主機地址或文件）即可。當集群具有多個成員時，所有傳入的指標都會發送給所有成員，基本上將輸入度量流複製到所有成員上。
any_of群集
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群集
carbon_ch群集將指標發送給成員，該成員根據原始碳Python繼電器中使用的一致哈希算法負責。如果將復制設置為高於1的值，則可以使用多個成員。設置dynamic時，任何服務器的故障都不會導致該服務器刪除指標，而是將無法預見的指標發送到集群中的任何其他服務器，以使指標不丟失。當複制為1時，這最有用。
定義指標分佈的方式的懸架的計算基於服務器主機（或IP地址）和成員的可選instance 。這意味著在不同端口上使用carbon_ch兩個目標，但在同一主機上將映射到同一hashkey，這意味著沒有發生指標的分佈。該實例用於解決這種情況。端口之後將一個實例附加到會員，並用平等符號隔開，例如127.0.0.1:2006=a =例如a 。實例是原始python碳酸含量引入的概念，需要根據這些碳的配置使用。
一致的哈希是一致的，因為從集群中刪除成員不應導致所有指標的完整映射到成員，而是僅將刪除成員的指標添加到所有其餘成員中，大約每個人都獲得其公平份額。另一種方式，當添加成員時，每個成員現在應該看到其指標的子集現在已被解決給新成員。這是比正常哈希的重要優勢，在普通哈希中，每次刪除或添加成員（也通過其IP地址或主機名的更改）將導致所有指標對所有可用指標進行完整映射。
fnv1a_ch群集
fnv1a_ch群集是Carbon-C-Relay引入的carbon_ch的不兼容改進。它使用了一種不同的哈希技術（FNV1A），該技術比carbon_ch使用的MD5-Hashing快。更重要的是， fnv1a_ch群集使用主機和端口來區分成員。當多個目標活在同一主機上時，這很有用。
由於使用fnv1a_ch不再需要instance屬性，因此它用於完全覆蓋主機：端口字符串，該端口將被計算出來。這是一個重要的方面，因為hashkey定義了成員收到的指標。這樣的替代允許許多事情，包括偽裝舊的IP地址，例如機器被遷移到較新的硬件時。一個例子是10.0.0.5:2003=10.0.0.2:2003 ：2003，地址5處的機器現在接收到地址2的機器的指標。
雖然以這種方式使用實例對於在現有群集中執行遷移非常有用，但對於新設置群集，實例可以通過使用第一天的實例將機器位置從其收到的指標分離出來，從而避免了這項工作。考慮例如10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac ，其中使用隨機哈希作為實例。這將允許更改服務器的端口和/或IP地址，該端口和/或IP地址多次接收數據，而無需處理任何遺留物，假設保留了隨機哈希。請注意，由於實例名稱用作完整的哈希輸入，因此作為a ， b等的實例可能會導致哈希分佈差，因為它們的哈希的輸入很少。因此，考慮使用上述示例中使用的更長且主要是不同的實例名稱，例如隨機哈希，以更好地哈希分佈行為。
jump_fnv1a_ch群集
jump_fnv1a_ch群集也像前兩個一樣是一致的哈希集群，但根本不考慮成員的主機，端口或實例。這意味著此群集類型查看定義成員的順序，請參見下面有關此順序的更多信息。這是否對您有用取決於您的情況。與前兩種一致的哈希集群類型相反，跳躍哈希在集群中定義的成員幾乎具有完美的平衡。但是，這是以無法刪除任何成員而不是從集群中刪除最後一個成員而不會導致所有成員對所有指標進行完整映射的犧牲而來的。這基本上意味著，這種哈希可以與恆定或曾經成長的群集一起使用，而舊節點永遠不會被刪除，而是被替換。
如果您的群集發生了舊節點的去除，則跳躍哈希不適合您。跳躍哈希在有序列表中與服務器一起使用。由於此順序很重要，因此可以使用以前的群集類型中使用的實例明確。當成員給出實例時，將其用作排序密鑰。沒有此實例，該訂單將如配置文件中的給出，當某些配置管理軟件生成時，可能會更改。因此，最好用實例來修復服務器的順序，以便顯式地說明了跳躍哈希的正確節點。一個人只能為此使用數字，但是請注意，1、2和10的排序結果是1、10、2，因此最好使用P0001，P0002，P0010之類的東西。
匹配規則是將傳入指標定向到一個或多個集群的一種方式。匹配規則在文件中定義時被從上到下處理。可以在同一規則中定義多個匹配項。每個匹配規則都可以將數據發送到一個或多個集群。由於匹配規則“通過”，除非添加stop關鍵字，否則精心設計的匹配表達式可以用於針對多個群集或聚合。這種功能允許複製指標，並在仔細的訂購和用法stop關鍵字的情況下向替代群集發送某些指標。特殊的集群blackhole丟棄了發送給它的任何指標。在某些情況下，這對於除掉不需要的指標可能很有用。因為將指標丟棄是毫無意義的，如果其他匹配項會接受相同的數據，而與黑洞群集的目的地則具有隱含的stop 。 validation子句以正則表達式的形式為數據（公制後發生的內容）添加了檢查。當此表達式匹配時，匹配規則將執行，好像沒有驗證子句。但是，如果失敗，匹配規則將被中止，並且不會將指標發送到目的地，那麼這就是drop行為。使用log時，將度量記錄到stderr。應注意後者，以避免原木洪水。當存在驗證子句時，目的地不必存在，這允許應用全局驗證規則。請注意，清潔規則是在驗證之前應用的，因此數據將沒有重複的空間。 route using用於對用於輸入的鍵進行臨時修改，以備一致的哈希例程。主要目的是路由流量，以便將適當的數據發送到所需的聚合實例。
重寫規則以正則表達方式作為匹配傳入指標的輸入，並將其轉換為所需的新公制名稱。在替換中，允許反向表示匹配輸入正則表達式中定義的捕獲組。 server.(x|y|z).允許使用EG role.1.在替換中。如果需要，可以使用g{n}的表示法，而不是n ，其中backReference之後是整數，例如g{1}100 。一些警告適用於當前重寫規則的實施。首先，他們在配置文件中的位置確定何時執行重寫。重寫是在就地完成的，因為在重寫匹配原始名稱之前的匹配規則是重寫不再匹配原始名稱後的匹配規則。應該在訂購中註意，因為可以連續進行多個重寫規則，例如， a被B替換為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 。請注意，這使用重寫規則的替換點置換式替換功能。給定輸入表達式，以下匹配組可用： 1整個主機名， 2簡短主機名和3 domainname（帶有領先的點）。替換默認值是有意義的carbon.relays._2默認情況下，指標每60秒submit every <interval> seconds條款進行更改，以獲取更兼容的值集碳 - 碳酸含量，請reset counters after interval來使值非構圖，也就是說，它們將與上一個值相比報告更改。
繼電器應聆聽傳入連接的端口和協議，可以使用listen Dimistive指定。當前，所有聽眾均需要使用linemode類型。可以為IP地址給出的端口和可選接口指定可選的壓縮或加密包裝，或者通過文件指定UNIX插座。當未指定接口時，假定所有可用IP協議上的任何接口。如果不存在listen指令，則繼電器將使用TCP和UDP上的端口2003的默認偵聽器，以及UNIX插座/tmp/.s.carbon-c-relay.2003 。這通常會擴展到啟用IPv6系統上的5個偵聽器。默認值匹配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的匹配規則編寫。差異主要在性能上，必須將傳入度量與表達式匹配的次數。在此示例中， dc-new匹配規則中的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:]而相反，這取決於您已配置的正則實現。）
驗證條款可以在每個匹配規則上都存在，因此，原則上，以下條款有效：
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關鍵字一樣。同樣，當驗證通過時，處理將繼續下一個規則。當目的地群集存在時， match尊重stop關鍵字是正常的。指定時，在指定時始終停止處理。但是，如果驗證失敗，則規則不會將任何內容髮送給目標群集，則指標將被刪除或記錄，但從未發送。
繼電器能夠隨時重寫傳入指標。此過程是基於捕獲組的正則表達式完成的，這些捕獲組允許在替換字符串中替換零件。重寫規則允許從應用程序清理指標，或提供遷移路徑。在最簡單的形式中，重寫規則看起來像這樣：
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server._1.2.3.34
;
在此示例中，諸如server.DC.role.name123之類的度量將轉換為server.dc.role.name.name123 。為了重寫規則與比賽相同，其命令很重要。因此，要在較早完成的舊/新集群示例之上構建，以下將存儲原始度量名稱在舊群集中，而新的公制名稱在新群集中：
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}
;
使用g{n}而不是上面顯示的n符號的反向註冊表示法的替代語法。兩個重寫規則都是相同的。
match * send to old;
rewrite ... ;
match * send to new;
請注意，重寫後，原始度量名稱不再可用，因為重寫就位發生。
聚集可能是碳-C-Relay中最複雜的部分。碳-C-Relay支持了兩種指定骨料的方法。第一個靜態規則是由優化器處理的，該優化器試圖將數千個規則分組折疊，以提高匹配效率。第二個動態規則是具有數千個內部實例化的非常強大的緊湊定義。典型的靜態聚合看起來像：
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
;
在此示例中，從傳入的匹配指標產生了四個聚合。在此示例中，我們本可以將兩場比賽寫為一場，但是出於演示目的，我們沒有。顯然，如果這很有意義，他們可以提及不同的指標。 every 10 seconds條款指定聚合器可以期望新指標到達的間隔。此間隔用於產生聚合，因此每10秒4個新指標是從收到的數據中生成的。由於數據可能是由於某種原因或生成停滯的運輸方式，因此條款expire after指定在考慮要完成的數據存儲庫（匯總）之前應保留多長時間。在示例中，使用了35個，這意味著在35秒後產生第一個聚集體。這也意味著指標可以遲到35秒，但仍被考慮在內。產生聚合指標的確切時間是到期時間後的0和間隔之間的隨機時間（在這種情況下為10）。這樣做是為了防止大量聚合集的指標雷電群。用於聚合的timestamp可以指定為存儲桶的start ， middle或end 。原始的碳 - 凝集器。py使用start ，而Carbon-C-Relay的默認值始終end 。 compute條款表明，單個聚合規則可以產生多個聚合物，就像這種情況一樣。在內部，這是免費的，因為無論使用它們是否使用，所有可能的聚集體始終是計算的。生產的新指標已重新提交為繼電器，因此以前在配置中定義的匹配可以匹配聚合器的輸出。避免循環非常重要，可以這種方式產生。通常，將聚合分解為自己的Carbon-C-Relay實例，因此很容易將產生的指標轉發到另一個中繼實例是一個很好的做法。
上一個示例也可以寫如下：動態：
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
;
在這裡進行單匹配，導致四個聚合，每個聚合範圍不同。在此示例中，正在製作基於主機名和群集的聚合，以及更通用的all目標，在此示例中，它們具有相同的值。請注意，使用此單個聚合規則，都會產生人均，每主機和總聚合。顯然，輸入指標定義了生成哪些主機和簇。
通過使用send to子句，可以使聚合更加直觀，並且容易出錯。考慮以下示例：
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;
除了SYS.Somemetric的指標，它將所有傳入的指標發送到石墨群集，並用所有傳入的指標替代了所有傳入的指標。在骨料中沒有stop ，這會導致循環，並且沒有send to循環，不能保留其原始名稱，因為現在的輸出直接進入群集。
配置群集時，您可能需要檢查如何將指標路由和哈希路由。這就是-t標誌的目的。對於以下配置：
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
;
運行命令： echo "my.super.metric" | carbon-c-relay -f config.conf -t ，將導致：
[...]
match
* -> my.super.metric
fnv1a_ch(graphite_swarm_odd)
host03.dom:2003
fnv1a_ch(graphite_swarm_even)
host04.dom:2003
stop
現在，您知道您的指標my.super.metric將被懸浮並到達HOST03和HOST04機器上。添加-d標誌將通過向您顯示hashring來增加信息量
當Carbon -C -Relay在沒有-d或-s參數的情況下運行時，將產生統計信息。默認情況下，它們以carbon.relays.<hostname>.* 。請參閱statistics構造以覆蓋此前綴，發送間隔和產生的值。雖然許多指標的名稱與碳速率的名稱相似，但它們的值可能不同。默認情況下，大多數值是運行計數器，僅隨著時間而增加。從石墨中使用非詞素的（）函數與這些函數很有用。
以下指標是在carbon.relays.<hostname>
測量
接力賽收到的指標數量。這裡收到的意味著任何調度員都會看到和處理它們。
指標
從繼電器發送的指標數量。這是所有服務器組合的總數。當群集配置重複傳入指標時，該計數器將包括所有這些重複。換句話說，成功發送到其他系統的指標數量。請注意，已處理（接收）但仍在發送隊列（排隊）中的指標不包括在此計數器中。
指標被識別
未被認為是有效度量的輸入線的數量。這樣的行可以是空的，只有包含空格，也可以擊中最大輸入長度和/或最大度量長度的限制（請參見-m和-M選項）。
指標列出
目前，所有服務器目標的隊列中的指標總數。該指標不是累積的，因為它是隊列大小的樣本，可以（並且應該）上下移動。因此，您不應為此指標使用衍生功能。
指標dropped
由於服務器隊列溢出而必須刪除的度量總數。當服務器試圖將其指標發送到無法達到的服務器時，通常會溢出，或者在攝取排隊的指標量時太慢。這可能與網絡或資源有關，也很大程度上取決於發送到特定服務器的指標率。
衡量標準
與任何規則不匹配的指標數量，或將規則與黑洞作為目標匹配。根據您的配置，高價值可能表明某處有錯誤的配置。這些指標是由接力賽收到的，但從未發送到任何地方，因此它們消失了。
公制
繼電器必須拖延客戶端以表明下游服務器無法處理指標流的次數。只有在隊列已滿並且服務器實際上接受指標時才執行攤位，但目前太慢了。攤位通常發生在微爆炸期間，在微型爆炸中，客戶通常不知道它應該停止發送更多數據，而該數據可以在能夠的情況下發送。
連接
連接請求的數量已處理。這是一個越來越多的數字，僅計算接受多少個連接。
斷開連接
斷開客戶的數量。斷開連接是因為客戶端消失，或者是由於繼電器中的空閒超時。該指標和連接之間的差異是繼電器積極持有的連接量。在正常情況下，這個數量仍然在合理的範圍內。許多連接，但很少有斷開連接通常表明客戶端可能存在連接洩漏。此處繼電器中斷開連接的空閒連接是在這種情況下防止資源消耗。
dispatch_walltime_us
調度員花費的微秒數量來完成他們的工作。尤其是在多核系統上，此值可能會令人困惑，但是，它表明調度員在處理客戶的工作時間多長時間。它包括他們所做的一切，從讀取插座，清理輸入度量的數據到將指標添加到適當的隊列中。配置越大，在匹配項方面越複雜，調度員將在CPU上花費的時間越多。但是，這些數字也包含了時間 /不 /在CPU上的時間。這是調度員為客戶服務的純壁掛時間。
dispatch_sleeptime_us
調度員在等待工作的小微秒數量。當此值變小（甚至零）時，調度員的工作量太多，以至於不再睡覺，並且可能無法及時處理工作。此值加上上面的壁時間總結到此調度員所需的總正常運行時間。因此，如果睡眠時間達到0，則表示牆壁為這一款項的百分比會使忙碌百分比一路排出至100％。
server_walltime_us
服務器花費的微秒數來從其隊列中發送指標。該值包括連接創建，從隊列閱讀以及通過網絡發送指標。
dispatcherx
對於每個獨立的調度員，收到的指標和黑；壁鐘時間。值如上所述。
目的地
對於所有已知的目的地，掉落，排隊和發送指標的數量以及花費的時間。值如上所述。
聚合器
匹配聚合規則並被聚合者接受的指標數量。當度量與多個聚合器匹配時，此值將反映這一點。當將其視為句法無效時，未計數度量，例如找不到值。
聚合器
發送給聚合器但不適合時間的指標數。這是因為指標在過去或將來太遠。匯總語句中條款後的到期，可以控製過去的度量值多長時間。
聚合器
從聚合器發送的指標數量。這些指標是生產的，是聚集的實際結果。
請在以下網址報告：https：//github.com/grobian/carbon-c-relay/issues
Fabian Groffen <[email protected]>
所有其他實用程序都來自石墨堆棧。
該項目旨在快速替代原始碳繼電器。 Carbon-C-Relay旨在提供性能和可配置性。碳是單線螺紋，將指標發送到多個一致的錘子簇需要鏈條。該項目提供了一個多線程繼電器，可以根據模式匹配來解決每個指標的多個目標和群集。
那裡還有其他一些替代項目，這些項目是碳固定和石墨 - 列層。
與碳 - 雷（Carbon-Relay-NG）相比，該項目確實提供了碳的一致錘擊路由。這樣做的Graphite-Relay不做基於公制的匹配來指導流量，該項目也是如此。迄今為止，Carbon-C-Relay可以進行聚合，故障轉移目標等。
該程序最初是為booking.com開發的，該程序批准了該代碼是在Github上發布和發行的，並在Github上發行了該代碼，作者要對此表示感謝。從那以後，在許多貢獻者的幫助下，開發一直在進行，這些貢獻者提出了功能，報告錯誤，增加補丁等，以使Carbon-C-Relay成為今天的現狀。
