carbon c relay
3.8.1 (28-04-2024)
carbon-c-relay -f Config-File [ options ... ]
O Carbon-C-Relay aceita, limpa, corresponde, reescreve, encaminhar e agregar métricas de grafite ouvindo conexões recebidas e transmitindo as mensagens para outros servidores definidos em sua configuração. A funcionalidade principal é rotear mensagens por meio de regras flexíveis para os destinos desejados.
Carbon-C-Relay é um programa simples que lê suas informações de roteamento de um arquivo. Os argumentos da linha de comando permitem definir o local para este arquivo, bem como a quantidade de despachantes (threads do trabalhador) a serem usados para ler os dados das conexões recebidas e passando -os para o (s) destino (s) certo (s). O arquivo de rota suporta duas construções principais: clusters e correspondências. Os primeiros grupos definidos de métricas de dados de hosts podem ser enviados, o último define quais métricas devem ser enviadas para qual cluster. As regras de agregação são vistas como correspondências. Reescritas são ações que afetam diretamente a métrica no ponto em que aparecem na configuração.
Para todas as métricas recebidas pelo relé, a limpeza é realizada. As seguintes alterações são realizadas antes de qualquer partida, a regra agregada ou reescrita vê a métrica:
[0-9a-zA-Z-_:#] , mas pode ser substituída na linha de comando. Observe que as tags (quando presentes e permitidas) não são processadas dessa maneira. Essas opções controlam o comportamento do relay de carbono-c .
-v : string e saída de versão de impressão.
-d : Ativar modo de depuração, isso imprime estatísticas para stdout e imprime mensagens extras sobre algumas situações encontradas pelo relé que normalmente seriam muito detalhadas para serem ativadas. Quando combinado com -t (modo de teste), isso também imprime rotas de stub e conteúdos de anel de hash consistente.
-s : Ativar modo de submissão. Nesse modo, as estatísticas internas não são geradas. Em vez disso, a pressão da fila e as gotas de métricas são relatadas no STDOUT. Esse modo é útil quando usado como relé de envio, qual trabalho é apenas para encaminhar (um conjunto de) relés principais. As estatísticas sobre os relés de envio neste caso não são necessárias e podem facilmente causar uma inundação não desejada de métricas, por exemplo, quando usado em cada host localmente.
-S : Ative o modo semelhante a iostat, onde a cada segundo o estado atual das estatísticas são relatadas. Isso implica no modo de envio -s .
-t : modo de teste. Esse modo não faz nenhum roteamento, mas lê a entrada do stdin e imprime quais ações seriam tomadas, dada a configuração carregada. Esse modo é muito útil para testar rotas de relé para sintaxe de expressão regular etc. Também permite fornecer informações sobre como o roteamento é aplicado em configurações complexas, pois mostra reescritas e agregados ocorrendo também. Quando -t é repetido, o relé testará apenas a configuração para validade e saída imediatamente depois. Qualquer saída padrão é suprimida nesse modo, tornando-o ideal para scripts inicial para testar uma (nova) configuração.
-f Config-File : Leia a configuração do arquivo de configuração . Uma configuração consiste em clusters e rotas. Consulte a sintaxe da configuração para obter mais informações sobre as opções e sintaxe deste arquivo.
-l File de log : use arquivo de log para escrever mensagens. Sem essa opção, o relé escreve para Stdout e Stderr . Ao fazer login no arquivo, todas as mensagens são prefixadas com MSG quando foram enviadas para o stdout e ERR quando foram enviadas para o Stderr .
-p Porta : Ouça as conexões na porta da porta. O número da porta é usado para soquetes TCP , UDP e UNIX sockets . Neste último caso, o arquivo de soquete contém o número da porta. A porta é padrão para 2003 , que também é usada pelo carbon-cache.py original.py. Observe que isso se aplica apenas aos padrões, quando as diretivas de listen estão na configuração, essa configuração é ignorada.
-w Trabalhadores : Use os trabalhadores número de tópicos. O número padrão de trabalhadores é igual à quantidade de núcleos de CPU detectados. Faz sentido reduzir esse número em máquinas de muitos núcleos ou quando o tráfego é baixo.
-b BatchSize : Defina a quantidade de métricas enviadas para servidores remotos de uma só vez para o BatchSize . Quando o relé envia métricas para servidores, ele recupera métricas batchsize da fila pendente de métricas que aguardam esse servidor e as enviarão uma a uma. O tamanho do lote terá um impacto mínimo no desempenho do envio, mas controla a quantidade de contenção de bloqueio na fila. O padrão é 2500 .
-q Feueuseize : Cada servidor a partir da configuração em que o relé enviará métricas, possui uma fila associada a ele. Esta fila permite que as interrupções e explosões sejam tratadas. O tamanho desta fila será definido para fazer filas, o que permite que essa quantidade de métricas seja armazenada na fila antes de transbordar, e o relé começa a soltar métricas. Quanto maior a fila, mais métricas podem ser absorvidas, mas também mais memória será usada pelo relé. O tamanho da fila padrão é 25000 .
-L barracas : define o suporte máximo das barracas para as barracas antes que o relé comece a soltar métricas para um servidor. Quando uma fila preenche, o relé usa um mecanismo chamado paralisação para sinalizar o cliente (escrevendo no relé) deste evento. Em particular, quando o cliente envia uma grande quantidade de métricas em muito pouco tempo (explosão), a parada pode ajudar a evitar a queda de métricas, já que o cliente só precisa desacelerar um pouco, o que em muitos casos é possível (por exemplo, ao catting um arquivo com nc (1)). No entanto, esse comportamento também pode obstruir os escritores artificialmente paralisando que não podem parar tão facilmente. Para isso, as barracas podem ser definidas de 0 a 15 , onde cada barraca pode levar cerca de 1 segundo no cliente. O valor padrão é definido como 4 , o que visa o cenário ocasional de interrupção e o esforço máximo para não perder métricas com desaceleração moderada dos clientes.
-C CacertPath : Leia os certificados CA (para uso com conexões TLS/SSL) do caminho ou arquivo determinado. Quando não são dados, os locais padrão são usados. A verficação estrita do par é realizada; portanto, ao usar certificados autoassinados, inclua o CA CER no local padrão ou forneça o caminho para o certificado usando esta opção.
-T Timeout : Especifica o tempo limite de IO em milissegundos usados para conexões de servidor. O padrão é de 600 milissegundos, mas pode precisar aumentar quando os links WAN são usados para servidores de destino. Um valor relativamente baixo para o tempo limite da conexão permite que o relé estabeleça rapidamente um servidor não atribuído e, como essas estratégias de failover, antes da fila aumentar.
-c Chars : define os caracteres que estão próximos a [A-Za-z0-9] permitidos nas métricas de chars . Qualquer caractere não nesta lista é substituído pelo relé por _ (sublinhado). A lista padrão dos caracteres permitidos é -_:# .
-m comprimento : limita os nomes métricos a terem no máximo bytes de comprimento . Quaisquer linhas que contenham nomes de métricas maiores do que isso serão descartadas.
-M Comprimento limita a entrada de linhas de bytes no máximo. Qualquer excesso de linhas será descartado. Observe que -m precisa ser menor que esse valor.
-H HostName : Subster HostName Determinado por uma chamada para gethostname (3) com o nome do host . O nome do host é usado principalmente nas métricas de estatísticas carbon.relays.<hostname>.<...> enviado pelo relé.
-B backlog : define conexão TCP Ouça o backlog para conexões de backlog . O valor padrão é 32 , mas nos servidores que recebem muitas conexões simultâneas, essa configuração provavelmente precisa ser aumentada para evitar erros de conexão recusados nos clientes.
-U bufsize : define os tamanhos de buffer de envio/recebimento de soquete em bytes, para os cenários TCP e UDP. Quando não é definido, o padrão do sistema operacional é usado. O máximo também é determinado pelo sistema operacional. Os tamanhos são definidos usando o setSockOpt com os sinalizadores SO_RCVBUF e SO_SNDBUF. Definir esse tamanho pode ser necessário para cenários de grande volume, para os quais -B pode ser aplicado. Verificando o RECV-Q e os valores dos erros de recebimento do NetStat dá uma boa dica sobre o uso do buffer.
-E : desative a desconexão de conexões de entrada ociosa. Por padrão, o relé desconecta as conexões ociosas do cliente após 10 minutos. Faz isso para evitar que os recursos entupirem quando um cliente com defeito ou malicioso continua abrindo conexões sem fechá -los. Normalmente impede que a falta de descritores de arquivos. Para alguns cenários, no entanto, não é desejável que as conexões ociosas sejam desconectadas, portanto, passar essa bandeira desativará esse comportamento.
-D : Deamonise em segundo plano após a inicialização. Esta opção requer que os sinalizadores -l e -P também sejam definidos.
-P PIDFILE : Escreva o PID do processo de relé para um arquivo chamado PIDFILE . Isso é em particular útil quando daemonizado em combinação com os gerentes init.
-O Limite : o número mínimo de regras a serem encontradas antes de tentar otimizar o conjunto de regras. O padrão é 50 , para desativar o otimizador, use -1 , para sempre executar o otimizador Use 0 . O otimizador tenta agrupar as regras para evitar gastar tempo excessivo em expressões correspondentes.
O arquivo de configuração suporta a seguinte sintaxe, onde os comentários começam com um caractere # e podem aparecer em qualquer posição em uma linha e suprimir a entrada até o final dessa linha:
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>
;
Vários clusters podem ser definidos e não precisam ser referenciados por uma regra de correspondência. Todos os clusters apontam para um ou mais hosts, exceto o cluster file que grava nos arquivos no sistema de arquivos local. host pode ser um endereço IPv4 ou IPv6 ou um nome de host. Como o host é seguido por uma porta opcional : para que os endereços IPv6 não sejam interpretados incorretamente, uma porta deve ser fornecida ou o endereço IPv6 cercado por colchetes, por exemplo, [::1] . transport opcional e as cláusulas proto podem ser usadas para envolver a conexão em uma camada de compactação ou criptografia ou especificar o uso de UDP ou TCP para se conectar ao servidor remoto. Quando omitido, a conexão padrão é uma conexão TCP simples. type só pode ser linemode no momento, por exemplo, o modo de picles do Python não é suportado.
Os nomes de host do DNS são resolvidos para um único endereço, de acordo com as regras de preferência no RFC 3484. OS any_of , failover e clusters forward têm um sinalizador useall explícito que permite a expansão para nomes de hosts resolvendo para vários endereços. Usando esta opção, cada endereço de qualquer tipo se torna um destino de cluster. Isso significa, por exemplo, que os endereços IPv4 e IPv6 são adicionados.
Existem dois grupos de tipos de cluster, clusters simples de encaminhamento e agrupamentos de hash consistentes.
forward e aglomerados file
Os clusters forward e file simplesmente enviam tudo o que recebem para os membros definidos (endereços ou arquivos do host). Quando um cluster tem vários membros, todas as métricas de entrada são enviadas a todos os membros, basicamente duplicando o fluxo métrico de entrada sobre todos os membros.
any_of cluster
O cluster any_of é uma pequena variante do cluster forward , mas, em vez de enviar as métricas de entrada para todos os membros definidos, envia cada métrica de entrada para apenas um dos membros definidos. O objetivo disso é um cenário balanceado de carga, onde qualquer um dos membros pode receber qualquer métrica. Como any_of sugere, quando qualquer um dos membros se tornar inacessível, os membros restantes disponíveis receberão imediatamente o fluxo completo de métricas de entrada. Isso significa especificamente que, quando 4 membros forem usados, cada um receberá aproximadamente 25% das métricas de entrada. Quando um membro fica indisponível (por exemplo, a interrupção da rede ou uma reinicialização do serviço), os três membros restantes receberão cerca de 25% / 3 = ~ 8% mais tráfego (33%). Como alternativa, eles receberão 1/3 da entrada total. Ao projetar a capacidade do cluster, deve -se levar em consideração que, no caso mais extremo, o membro restante final receberá todo o tráfego de entrada.
Um cluster any_of pode, em particular, ser útil quando o cluster apontar para outros relés ou caches. Quando usado com outros relés, ele efetivamente os balance de carga e se adapta imediatamente à inavailabilidade dos alvos. Quando usado com caches, há um pequeno detalhe sobre como any_of funciona, que o torna muito adequado. A implementação deste roteador não é para redondos sobre nenhum membro disponível, mas, em vez disso, usa uma estratégia de hash consistente para fornecer as mesmas métricas ao mesmo destino o tempo todo. Isso ajuda a armazenar em cache e facilita a recuperação de pontos de dados não comprometidos (de um único cache), mas ainda permitem uma reinicialização dos caches. Quando um membro fica indisponível, os destinos de hash não são alterados, mas, em vez disso, o tráfego destinado ao nó indisponível é espalhado uniformemente pelos nós disponíveis.
cluster failover
O cluster failover é como o cluster any_of , mas segue a ordem em que os servidores são definidos. Isso é para implementar um cenário de failover puro entre servidores. Todas as métricas são enviadas para no máximo 1 membro, portanto, não está ocorrendo hash ou balanceamento. Por exemplo, um cluster failover com dois membros enviará apenas métricas para o segundo membro quando o primeiro membro ficar indisponível. Assim que o primeiro membro retornar, todas as métricas são enviadas para o primeiro nó novamente.
cluster carbon_ch
O cluster carbon_ch envia as métricas para o membro responsável de acordo com o algoritmo de hash consistente, conforme usado no relé original do carbono python. Vários membros são possíveis se a replicação estiver definida como um valor superior a 1. Quando dynamic estiver definida, a falha de qualquer um dos servidores não resultará em métricas que estão sendo descartadas para esse servidor, mas as métricas não entregues são enviadas para qualquer outro servidor no cluster para que as métricas não se perdem. Isso é mais útil quando a replicação é 1.
O cálculo da hashring, que define a maneira pela qual as métricas são distribuídas, é baseada no host do servidor (ou endereço IP) e na instance opcional do membro. Isso significa que o uso de carbon_ch dois alvos em portas diferentes, mas no mesmo host mapeará o mesmo hashkey, o que significa que não ocorre distribuição de métricas. A instância é usada para remediar essa situação. Uma instância é anexada ao membro após a porta e separada por um sinal igual, por exemplo, 127.0.0.1:2006=a por exemplo, a . As instâncias são um conceito introduzido pelo cache de carbono Python original e precisa ser usado de acordo com a configuração deles.
Os hashes consistentes são consistentes no sentido de que a remoção de um membro do cluster não deve resultar em um re-mapeamento completo de todas as métricas para os membros, mas, em vez disso, adicionar apenas as métricas do membro removido a todos os membros restantes, aproximadamente cada uma delas obtém sua parte justa. No contrário, quando um membro é adicionado, cada membro deve ver um subconjunto de suas métricas agora sendo endereçadas ao novo membro. Essa é uma vantagem importante sobre um hash normal, onde cada remoção ou adição de membros (também por exemplo, uma alteração em seu endereço IP ou nome de host) causaria um re-mapeamento completo de todas as métricas em todas as métricas disponíveis.
cluster fnv1a_ch
O cluster fnv1a_ch é uma melhoria incompatível para carbon_ch introduzida pelo carbono-c-relay. Ele usa uma técnica de hash diferente (FNV1a), que é mais rápida que a haste de MD5 usada por carbon_ch . Mais importante, os clusters fnv1a_ch usam host e porta para distinguir os membros. Isso é útil quando vários alvos vivem no mesmo host, separados por porta.
Como a propriedade instance não é mais necessária com fnv1a_ch dessa maneira, ela é usada para substituir completamente a sequência do host: Porta que o hashkey seria calculado. Esse é um aspecto importante, uma vez que o Hashkey define quais métricas um membro recebe. Essa substituição permite muitas coisas, incluindo endereços IP antigos, por exemplo, quando uma máquina foi migrada para o hardware mais recente. Um exemplo disso seria 10.0.0.5:2003=10.0.0.2:2003 , onde uma máquina no endereço 5 agora recebe as métricas para uma máquina que estava no endereço 2.
Embora o uso de instâncias dessa maneira possa ser muito útil para realizar migrações em clusters existentes, para recém -configurar clusters, as instâncias permitem evitar esse trabalho usando uma instância desde o primeiro dia para separar o local da máquina das métricas que recebe. Considere, por exemplo, 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac , onde um hash aleatório como a instância é usado. Isso permitiria alterar a porta e/ou o endereço IP do servidor que recebe dados quantas vezes sem lidar com qualquer legado sendo visível, assumindo que o hash aleatório seja retido. Observe que, como o nome da instância é usado como entrada de hash completa, as instâncias como a , b , etc. provavelmente resultarão em má distribuição de hash, pois seus hashes têm muito pouca entrada. Por esse motivo, considere o uso de nomes de instâncias mais longos e principalmente diferentes, como hashes aleatórios, conforme usado no exemplo acima, para um melhor comportamento de distribuição de hash.
cluster jump_fnv1a_ch
O cluster jump_fnv1a_ch também é um cluster de hash consistente como os dois anteriores, mas não leva em consideração o host, porta ou instância do membro. Isso significa que esse tipo de cluster analisa a ordem em que os membros são definidos, veja também abaixo para saber mais sobre esse pedido. Se isso é útil para você depende do seu cenário. Em contraste com os dois tipos de cluster de hash consistentes anteriores, o hash de salto tem um equilíbrio quase perfeito sobre os membros definidos no cluster. No entanto, isso ocorre à custa de não ser capaz de remover nenhum membro, exceto o último do cluster sem causar um re-mapeamento completo de todas as métricas sobre todos os membros. O que isso significa basicamente é que esse hash é bom de usar com aglomerados constantes ou sempre em crescimento, onde os nós mais antigos nunca são removidos, mas substituídos.
Se você tiver um cluster em que a remoção de nós antigos ocorre, o hash de salto não é adequado para você. Hash Jump funciona com servidores em uma lista ordenada. Como esse pedido é importante, ele pode ser explícito usando a instância usada nos tipos de cluster anteriores. Quando uma instância é fornecida com os membros, ela será usada como chave de classificação. Sem esse caso, o pedido será fornecido no arquivo de configuração, que pode ser propenso a alterações quando, por exemplo, gerado por algum software de gerenciamento de configuração. Como tal, é provavelmente uma boa prática corrigir a ordem dos servidores com instâncias, de modo que seja explícito quais são os nós certos para o hash de salto. Pode -se apenas usar números para eles, mas esteja ciente de que a classificação de 1, 2 e 10 resulta em 1, 10, 2, é melhor usar algo como P0001, P0002, P0010.
As regras de correspondência são a maneira de direcionar as métricas de entrada para um ou mais clusters. As regras de correspondência são processadas de cima para baixo, pois são definidas no arquivo. É possível definir várias correspondências na mesma regra. Cada regra de correspondência pode enviar dados para um ou mais clusters. Como as regras da correspondência "caem", a menos que a palavra -chave stop seja adicionada, a expressão de correspondência cuidadosamente criada pode ser usada para direcionar vários clusters ou agregações. Essa habilidade permite replicar métricas, bem como enviar certas métricas para clusters alternativos com pedidos cuidadosos e uso da palavra -chave stop . O cluster especial blackhole descarta todas as métricas enviadas a ele. Isso pode ser útil para eliminar métricas indesejadas em certos casos. Porque jogar métricas fora é inútil se outras correspondências aceitarem os mesmos dados, uma correspondência com o destino do Blackhole, tiver uma stop implícita. A cláusula validation adiciona uma verificação aos dados (o que vem após a métrica) na forma de uma expressão regular. Quando essa expressão corresponde, a regra de correspondência será executada como se nenhuma cláusula de validação estivesse presente. No entanto, se falhar, a regra de correspondência será abortada e nenhuma métrica será enviada para destinos, esse é o comportamento drop . Quando log é usado, a métrica é registrada no stderr. Deve -se tomar cuidado com o último para evitar inundações de toras. Quando uma cláusula de validação está presente, os destinos não precisam estar presentes, isso permite a aplicação de uma regra de validação global. Observe que as regras de limpeza são aplicadas antes que a validação seja feita, portanto, os dados não terão espaços duplicados. A route using a cláusula é usada para executar uma modificação temporária na chave usada para entrada nas rotinas de hash consistentes. O objetivo principal é rotear o tráfego para que os dados apropriados sejam enviados para as instâncias de agregação necessárias.
As regras de reescrita tomam uma expressão regular como entrada para corresponder às métricas de entrada e transformá -las no novo nome métrico desejado. Na substituição, as referências de recuperação podem corresponder aos grupos de captura definidos na expressão regular de entrada. Uma correspondência do server.(x|y|z). permite usar role.1. na substituição. Se necessário, uma notação de g{n} pode ser usada em vez de n onde a referência de back -referência é seguida por um número inteiro, como g{1}100 . Algumas advertências se aplicam à implementação atual das regras de reescrita. Primeiro, a localização deles no arquivo de configuração determina quando a reescrita é executada. A reescrita é feita no local, como essa regra de correspondência antes que a reescrita corresponda ao nome original, uma regra de correspondência depois que a reescrita não corresponde mais ao nome original. Deve -se tomar cuidado com a ordem, pois várias regras de reescrita em sucessão podem ocorrer, por exemplo a é substituído por b e b é substituído por c em uma regra de reescrita seguinte. A segunda ressalva com a implementação atual é que os nomes das métricas reescritas não são limpos, como as métricas recém -chegadas. Assim, pontos duplos e personagens perigosos em potencial podem aparecer se a corda de substituição for criada para produzi -los. É de responsabilidade do escritor garantir que as métricas estejam limpas. Se isso for um problema para o roteamento, pode-se considerar ter uma instância somente para reescrita que encaminhe todas as métricas para outra instância que fará o roteamento. Obviamente, a segunda instância limpará as métricas à medida que elas entram. A notação de referência de back -referência permite minúsculas e maiúsculas da sequência de substituição com o uso do sublinhado ( _ ) e os símbolos ( ^ ) seguintes diretamente após a barragem. Por exemplo, role._1. Como a substituição será baixa o conteúdo de 1 . O ponto ( . ) Pode ser usado de maneira semelhante ou seguido após o sublinhado ou o alvo para substituir pontos por sublinhados na substituição. Isso pode ser útil para algumas situações em que as métricas são enviadas para grafite.
As agregações definidas obtêm uma ou mais métricas de entrada expressas por uma ou mais expressões regulares, semelhantes às regras da partida. As métricas recebidas são agregadas por um período de tempo definido pelo intervalo em segundos. Como os eventos podem chegar um pouco mais tarde, o tempo de expiração em segundos define quando as agregações devem ser consideradas finais, pois nenhuma nova entrada pode ser adicionada mais. Além de uma agregação, várias agregações podem ser calculadas. Eles podem ser dos mesmos tipos de agregação ou de agregação diferentes, mas devem escrever para uma nova métrica única. Os nomes métricos podem incluir referências de volta como nas expressões de reescrita, permitindo poderosas regras de agregação única que produzem em muitas agregações. Quando nenhum send to a cláusula é fornecido, as métricas produzidas são enviadas para o relé como se fossem enviadas de fora, portanto, as regras de partida e agregação se aplicam a elas. Deve -se tomar cuidado para que os loops sejam evitados dessa maneira. Por esse motivo, o uso da cláusula send to é incentivado, a direcionar o tráfego de saída sempre que possível. Como nas regras de correspondência, é possível definir vários alvos de cluster. Além disso, como as regras de correspondência, a palavra -chave stop se aplica para controlar o fluxo de métricas no processo de correspondência.
As send statistics to construção são depreciadas e serão removidas na próxima versão. Use a construção statistics especiais.
O construto statistics pode controlar algumas coisas sobre as estatísticas (internas) produzidas pelo relé. O send to o destino pode ser usado para evitar loops de roteador enviando as estatísticas para um determinado (s) cluster (s) de destino. Por -H , as métricas são prefixadas com carbon.relays.<hostname> Este prefixo pode ser definido usando o prefix with cláusula semelhante a um destino de regra de reescrita. A correspondência de entrada neste caso é a expressão regular predefinida ^(([^.]+)(..*)?)$ No nome do host. Como tal, pode -se ver que o prefixo padrão é definido por carbon.relays..1 . Observe que isso usa o recurso de substituição de substituição-dot-with-underscore das regras de reescrita. Dada a expressão de entrada, os seguintes grupos de partidas estão disponíveis: 1 o nome inteiro do host, 2 o short host Name e 3 o domainName (com o ponto principal). Pode fazer sentido substituir o padrão por algo como carbon.relays._2 para certos cenários, sempre use o nome de host Short, que segue a expressão, não contém um ponto. Por padrão, as métricas são enviadas a cada 60 segundos, isso pode ser alterado usando a cláusula de submit every <interval> seconds para obter um conjunto mais compatível de valores para carbono cache.py, use os reset counters after interval para tornar os valores não cumulativos, ou seja, eles relatarão a mudança comparada ao valor anterior.
As portas e protocolos que o relé deve ouvir as conexões recebidas podem ser especificadas usando a diretiva listen . Atualmente, todos os ouvintes precisam ser do tipo linemode . Um embrulho opcional de compactação ou criptografia pode ser especificado para a porta e a interface opcional fornecida por endereço IP ou soquete Unix por arquivo. Quando a interface não é especificada, a interface em todos os protocolos IP disponíveis é assumida. Se nenhuma diretiva listen estiver presente, o relé usará os ouvintes padrão para a Port 2003 no TCP e UDP, além do soquete Unix /tmp/.s.carbon-c-relay.2003 . Isso normalmente se expande para 5 ouvintes em um sistema habilitado para IPv6. O padrão corresponde ao comportamento das versões antes da v3.2.
Caso a configuração se torne muito longa ou seja gerenciada melhor em arquivos separados, a diretiva include pode ser usada para ler outro arquivo. O arquivo especificado será lido no lugar e adicionado à configuração do roteador no momento da inclusão. O resultado final é uma grande configuração de rota. Múltiplas declarações include podem ser usadas em todo o arquivo de configuração. O posicionamento influenciará a ordem das regras normalmente. Cuidado com a inclusão recursiva ( include de um arquivo incluído) é suportado e, atualmente, não existem salvaguardas para um loop de inclusão. Pelo que vale, esse recurso provavelmente é melhor usado com arquivos de configuração simples (por exemplo, não tendo include neles).
O Rellay de Carbon-C evoluiu com o tempo, os recursos crescentes sob demanda, pois a ferramenta provou ser estável e ajustar bem o trabalho. Abaixo, siga alguns exemplos anotados de construções que podem ser usadas com o relé.
Clusters podem ser definidos o máximo necessário. Eles recebem dados das regras de correspondência e seu tipo define quais membros do cluster finalmente obtêm os dados métricos. O formulário de cluster mais simples é um cluster forward :
cluster send-through
forward
10.1.0.1
;
Qualquer métrica enviada para o cluster send-through seria simplesmente encaminhada ao servidor no endereço IPv4 10.1.0.1 . Se definirmos vários servidores, todos esses servidores receberiam a mesma métrica, assim:
cluster send-through
forward
10.1.0.1
10.2.0.1
;
O acima resulta em uma duplicação de métricas enviadas para as duas máquinas. Isso pode ser útil, mas na maioria das vezes não é. O tipo de cluster any_of é como forward , mas envia cada métrica de entrada para qualquer um dos membros. O mesmo exemplo com esse cluster seria:
cluster send-to-any-one
any_of 10.1.0.1:2010 10.1.0.1:2011;
Isso implementaria um cenário de múltipla, onde dois servidores são usados, a carga entre eles é espalhada, mas se qualquer um deles falhar, todas as métricas são enviadas para a restante. Isso normalmente funciona bem para relés a montante ou para equilibrar processos de cache de carbono em execução na mesma máquina. Se qualquer membro ficar indisponível, por exemplo, devido a uma reinicialização, os outros membros recebem o tráfego. Se for necessário ter falha verdadeira, onde o servidor secundário for usado apenas se o primeiro estiver inativo, o seguinte implementaria isso:
cluster try-first-then-second
failover 10.1.0.1:2010 10.1.0.1:2011;
Esses tipos são diferentes dos dois tipos consistentes de cluster de hash:
cluster graphite
carbon_ch
127.0.0.1:2006=a
127.0.0.1:2007=b
127.0.0.1:2008=c
;
Se um membro deste exemplo falhar, todas as métricas que iriam para esse membro serão mantidas na fila, aguardando o retorno do membro. Isso é útil para clusters de máquinas de cache de carbono, onde é desejável que a mesma métrica termine sempre no mesmo servidor. O tipo de cluster carbon_ch é compatível com hash consistente de relexo de carbono e pode ser usado para aglomerados existentes preenchidos por relay de carbono. Para novos clusters, no entanto, é melhor usar o tipo de cluster fnv1a_ch , pois é mais rápido e permite equilibrar o mesmo endereço, mas portas diferentes sem um número de instância, em constrangimento para carbon_ch .
Como podemos usar vários clusters, também podemos replicar sem o uso do tipo de cluster forward , de uma maneira mais inteligente:
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
;
Neste exemplo, todas as métricas recebidas são enviadas pela primeira vez para dc-old , depois dc-new1 e, finalmente, para dc-new2 . Observe que o tipo de cluster de dc-old é diferente. Cada métrica recebida será enviada para 2 membros dos três grupos, replicando assim no total de 6 destinos. Para cada cluster, os membros de destino são calculados de forma independente. A falha de aglomerados ou membros não afeta os outros, pois todos têm filas individuais. O exemplo acima também pode ser escrito usando três regras de correspondência para cada DC ou uma regra de correspondência para todos os três DCs. A diferença está principalmente no desempenho, o número de vezes que a métrica de entrada deve ser comparada a uma expressão. A regra stop na regra de correspondência dc-new não é estritamente necessária neste exemplo, porque não há mais regras de partida a seguir. No entanto, se a correspondência direcionaria um subconjunto específico, por exemplo ^sys. , e mais clusters seriam definidos, isso poderia ser necessário, como, por exemplo, no seguinte exemplo abreviado:
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;
Como pode ser visto, sem a stop na regra de correspondência do DC2-SYS, todas as métricas começando com sys. também seria enviado para DC1-MISC e DC2-MISC. Pode ser que isso seja desejado, é claro, mas neste exemplo há um cluster dedicado para as métricas sys .
Suponha que haveria alguma métrica indesejada que, infelizmente, seja gerada, vamos assumir algum software ruim/antigo. Não queremos armazenar essa métrica. O cluster blackhole é adequado para isso, quando é mais difícil de serem realmente a lista de permissões que desejavam métricas. Considere o seguinte:
match
some_legacy1$
some_legacy2$
send to blackhole
stop;
Isso jogaria fora todas as métricas que terminam com some_legacy , que de outra forma seriam difíceis de filtrar. Como o pedido é importante, ele pode ser usado em uma construção como esta:
cluster old ... ;
cluster new ... ;
match * send to old;
match unwanted send to blackhole stop;
match * send to new;
Neste exemplo, o cluster antigo receberia a métrica indesejada para o novo cluster. Portanto, a ordem em que as regras ocorrem importa para a execução.
A validação pode ser usada para garantir que os dados para métricas sejam conforme o esperado. Uma validação global para apenas os valores de número apenas (sem ponto flutuante) pode ser:
match *
validate ^[0-9]+ [0-9]+$ else drop
;
(Observe a fuga com barragem do espaço, você poderá usar s ou [:space:] , em vez disso, isso depende da sua implementação de regex configurada.)
A cláusula de validação pode existir em todas as regras de partidas; portanto, em princípio, o seguinte é válido:
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;
Observe que o comportamento é diferente nos dois exemplos anteriores. Quando nenhum send to clusters é especificado, um erro de validação faz com que a correspondência se comporte como a palavra -chave stop está presente. Da mesma forma, quando a validação passa, o processamento continua com a próxima regra. 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.
conexões
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.
