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关键字一样。同样，当验证通过时，处理将继续下一个规则。 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.
