carbon c relay

Carbon-C-Relay (1)-흑연 릴레이, 애그리 게이터 및 재 작성자

개요

carbon-c-relay -f 구성 파일 [ options ... ]

설명

Carbon-C-Relay는 들어오는 연결을 듣고 구성에 정의 된 다른 서버로 메시지를 전달하여 흑연 메트릭을 수용, 클렌치, 일치, 재 작성, 포워드 및 집계에 동의합니다. 핵심 기능은 유연한 규칙을 통해 원하는 목적지로 메시지를 라우팅하는 것입니다.

Carbon-C-Relay는 파일에서 라우팅 정보를 읽는 간단한 프로그램입니다. 명령 줄 인수를 사용하면이 파일의 위치와 수신 연결에서 데이터를 읽고 올바른 대상으로 전달하는 데 사용할 디스패처 (작업자 스레드)의 양을 설정할 수 있습니다. 경로 파일은 클러스터와 일치의 두 가지 주요 구성을 지원합니다. 호스트 데이터 메트릭 그룹의 첫 번째 정의는 전송 될 수 있으며, 후자는 어떤 클러스터로 전송되어야하는지 정의합니다. 집계 규칙은 일치로 간주됩니다. 다시 쓰기는 구성에 나타나는 지점에서 메트릭에 직접 영향을 미치는 동작입니다.

릴레이에서받은 모든 메트릭에 대해 정화가 수행됩니다. 일치, 집계 또는 다시 쓰기 규칙이 메트릭을 볼 수 있기 전에 다음 변경 사항이 수행됩니다.

• 이중 도트 제거 (일관된 해시 라우팅을 올바르게 작동하는 데 필요)
• 후행/선도적 인 도트 제거
• 공백 정규화 (이것은 주로 다른 대상으로의 릴레이 출력에 영향을 미칩니다. 메트릭, 값 및 타임 스탬프는 단일 공간으로 만 분리됩니다)
• 밑줄 (_)을 사용한 불규칙한 숯 교체는 현재 불규칙한 것이 [0-9a-zA-Z-_:#] 에 있지 않은 것으로 정의되지만 명령 줄에서 상정 될 수 있습니다. 태그 (존재하고 허용 된 경우)는 이런 식으로 처리되지 않습니다.

옵션

이러한 옵션은 Carbon-C-Relay 의 동작을 제어합니다.

• -v : 인쇄 버전 문자열 및 종료.

• -d : 디버그 모드를 활성화하면이 통계는 STDOUT에 인쇄하고 일반적으로 활성화하기에는 너무 장황한 릴레이에서 발생하는 일부 상황에 대한 추가 메시지를 인쇄합니다. -t (테스트 모드)와 결합하면 스터브 경로 및 일관된 호쉬 링 내용물도 인쇄합니다.

• -s : 제출 모드를 활성화합니다. 이 모드에서는 내부 통계가 생성되지 않습니다. 대신, 대기열 압력 및 메트릭 방울이 STDOut에서보고됩니다. 이 모드는 제출 릴레이로 사용될 때 유용합니다. 이 경우 제출 릴레이에 대한 통계는 필요하지 않으며, 각 호스트에 현지에서 사용될 때 의지가없는 메트릭 홍수를 쉽게 유발할 수 있습니다.

• -S : 현재 통계 상태가보고되는 ISTAT와 같은 모드를 활성화합니다. 이것은 제출 모드 -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 : 원격 서버로 전송 된 메트릭의 양을 한 번에 배치 크기 로 설정하십시오. 릴레이가 서버로 메트릭을 보내면 해당 서버를 기다리는 대기하는 메트릭 대기열에서 batchsize 메트릭을 검색하고 그 중 하나를 하나씩 보냅니다. 배치의 크기는 성능을 보내는 데 최소한의 영향을 미치지 만 대기열의 잠금 장치 양을 제어합니다. 기본값은 2500 입니다.

• -q Queuesize : 릴레이가 메트릭을 보내는 구성의 각 서버에는 이와 관련된 대기열이 있습니다. 이 대기열은 혼란과 버스트를 처리 할 수 ​​있습니다. 이 대기열의 크기는 대기열 로 설정되어 오버플로하기 전에 해당 양의 메트릭을 줄이고 릴레이가 메트릭을 떨어 뜨리기 시작합니다. 대기열이 클수록 더 많은 메트릭을 흡수 할 수 있지만 릴레이에는 더 많은 메모리가 사용됩니다. 기본 대기열 크기는 25000 입니다.

• -L 마구간 : 릴레이가 서버의 메트릭을 떨어 뜨리기 전에 마구간의 최대 마운트를 스톨 으로 설정합니다. 대기열이 채워지면 릴레이는 스톨 링 (Stalling)이라는 메커니즘을 사용 하여이 이벤트의 클라이언트 (릴레이에 쓰기) 신호를 보냅니다. 특히 클라이언트가 매우 짧은 시간 (버스트) 안에 많은 양의 메트릭을 보낼 때 마구간은 메트릭을 떨어 뜨리는 것을 피하는 데 도움이 될 수 있습니다. 클라이언트는 약간의 속도를 늦추어야하기 때문에 많은 경우가 가능합니다 (예 : nc 로 파일을 넣을 때). 그러나이 행동은 또한 그것을 쉽게 멈출 수없는 작가들을 방해하고 인위적으로 실속 할 수 있습니다. 이를 위해 스톨은 0 에서 15 로 설정할 수 있으며, 각 스톨은 클라이언트에서 약 1 초가 걸릴 수 있습니다. 기본값은 4 로 설정되며, 이는 가끔 혼란 시나리오와 클라이언트의 중간 정도 속도가 느려지면서 메트릭을 느슨하게하지 않기위한 최대의 노력을 목표로합니다.

• -C CacertPath : 주어진 경로 또는 파일에서 CA CERT (TLS/SSL 연결과 함께 사용)를 읽으십시오. 주어지지 않으면 기본 위치가 사용됩니다. 피어의 엄격한 verfication이 수행되므로 자체 서명 된 인증서를 사용할 때는 기본 위치에 CA CERT를 포함 시키 거나이 옵션을 사용하여 CERT 경로를 제공하십시오.

• -T 타임 아웃 : 서버 연결에 사용되는 밀리 초로 IO 타임 아웃을 지정합니다. 기본값은 600 밀리 초이지만 대상 서버에 WAN 링크가 사용될 때 증가해야 할 수도 있습니다. 연결 시간 초과의 상대적으로 낮은 값은 릴레이가 서버를 신속하게 설정할 수 없으며, 이러한 장애 조치 전략은 큐가 높아지기 전에 시작할 수 있습니다.

• -c chars : chars 에 대한 메트릭으로 허용 된 [A-Za-z0-9] 옆에있는 문자를 정의합니다. 이 목록에없는 모든 문자는 릴레이로 _ (밑줄)로 대체됩니다. 허용 문자의 기본 목록은 -_ :# 입니다.

• -m 길이 : 메트릭 이름을 대부분의 길이 의 길이로 제한합니다. 이것보다 큰 메트릭 이름을 포함하는 모든 줄은 폐기됩니다.

• -M 길이는 입력을 대부분의 길이 바이트 라인으로 제한합니다. 과도한 선은 폐기됩니다. -m 은이 값보다 작아야합니다.

• -H hostname : hostname을 사용하여 gethostname (3)에 대한 호출로 결정된 호스트 이름을 재정의합니다. 호스트 이름은 주로 통계 메트릭 carbon.relays.<hostname>.<...> 릴레이에서 보냈습니다.

• -B 백 로그 : TCP 연결 설정 백 로그 연결로 백 로그를 듣습니다. 기본값은 32 이지만 동시 연결을 많이받는 서버에서는 클라이언트의 연결 거부 오류를 피하기 위해이 설정을 늘려야 할 것입니다.

• -U bufsize : TCP 및 UDP 시나리오 모두에 대해 소켓 보내기/수신 버퍼 크기를 바이트로 설정합니다. UNSET시 OS 기본값이 사용됩니다. 최대 값은 OS에 의해 결정됩니다. 크기는 Flags SO_RCVBUF 및 SO_SNDBUF와 함께 SetSockopt를 사용하여 설정됩니다. 대량 시나리오에는이 크기를 설정해야 할 수 있으며 -B 도 적용될 수 있습니다. RECV-Q 와 Netstat 에서 수신 오류 값을 확인하면 버퍼 사용에 대한 힌트가 좋습니다.

• -E : 유휴 연결 연결을 비활성화합니다. 기본적으로 릴레이는 10 분 후 유휴 클라이언트 연결을 분리합니다. 결함이 있거나 악의적 인 클라이언트가 연결을 닫지 않고 계속 열면 리소스가 막히지 않도록합니다. 일반적으로 파일 설명자가 부족하지 않습니다. 그러나 일부 시나리오의 경우 유휴 연결을 분리하는 것이 바람직하지 않으므로이 플래그를 통과하면이 동작이 비활성화됩니다.

• -D : 시작 후 배경으로 Deamonise. 이 옵션에는 -l 및 -P 플래그도 설정해야합니다.

• -P PIDFILE : 릴레이 프로세스의 PID를 PidFile 이라는 파일에 씁니다. 이는 이니셜 관리자와 함께 데모 화 될 때 특히 유용합니다.

• -O 임계 값 : 규칙 세트를 최적화하기 전에 찾을 최소 규칙 수입니다. 기본값은 50 이며, 최적화기를 비활성화하려면 -1 사용하여 항상 최적화기 사용 0 실행합니다. Optimiser는 일치하는 표현에 과도한 시간을 소비하지 않기 위해 그룹 규칙을 시도합니다.

구성 구문

구성 파일은 다음 구문을 지원합니다. 여기서 주석은 # 문자로 시작하여 줄의 어느 위치에도 나타날 수 있으며 해당 행의 끝까지 입력을 억제 할 수 있습니다.

 cluster <name>
    < <forward | any_of | failover> [useall] |
      <carbon_ch | fnv1a_ch | jump_fnv1a_ch> [replication <count>] [dynamic] >
        <host[:port][=instance] [proto <udp | tcp>]
                                [type linemode]
                                [transport <plain | gzip | lz4 | snappy>
                                           [ssl | mtls <pemcert> <pemkey>]]> ...
    ;

cluster <name>
    file [ip]
        </path/to/file> ...
    ;

match
        <* | expression ...>
    [validate <expression> else <log | drop>]
    send to <cluster ... | blackhole>
    [stop]
    ;

rewrite <expression>
    into <replacement>
    ;

aggregate
        <expression> ...
    every <interval> seconds
    expire after <expiration> seconds
    [timestamp at <start | middle | end> of bucket]
    compute <sum | count | max | min | average |
             median | percentile<%> | variance | stddev> write to
        <metric>
    [compute ...]
    [send to <cluster ...>]
    [stop]
    ;

send statistics to <cluster ...>
    [stop]
    ;
statistics
    [submit every <interval> seconds]
    [reset counters after interval]
    [prefix with <prefix>]
    [send to <cluster ...>]
    [stop]
    ;

listen
    type linemode [transport <plain | gzip | lz4 | snappy>
                      [<ssl | mtls> <pemcert>
                          [protomin <tlsproto>] [protomax <tlsproto>]
                          [ciphers <ssl-ciphers>] [ciphersuites <tls-suite>]
                      ]
                  ]
        <<interface[:port] | port> proto <udp | tcp>> ...
        </ptah/to/file proto unix> ...
    ;
    # tlsproto: <ssl3 | tls1.0 | tls1.1 | tls1.2 | tls1.3>
    # ssl-ciphers: see ciphers(1)
    # tls-suite: see SSL_CTX_set_ciphersuites(3)

include </path/to/file/or/glob>
    ;

클러스터

다중 클러스터를 정의 할 수 있으며 일치 규칙에 따라 참조 할 필요가 없습니다. 모든 클러스터는 로컬 파일 시스템의 파일에 쓰는 file 클러스터를 제외하고 하나 이상의 호스트를 가리 킵니다. host IPv4 또는 IPv6 주소 또는 호스트 이름 일 수 있습니다. 호스트는 선택 사항과 포트 : 포트, IPv6 주소 [::1] 잘못 해석되지 않아야한다. 포트가 제공되어야한다. 선택적 transport 및 proto 조항을 사용하여 연결을 압축 또는 암호화 레이어로 마무리하거나 원격 서버에 연결하기 위해 UDP 또는 TCP를 사용하도록 지정할 수 있습니다. 생략되면 연결 기본값이 일반 TCP 연결에 대한 기본값. type 현재 linemode 일 수 있습니다. 예를 들어 Python의 피클 모드는 지원되지 않습니다.

RFC 3484의 기본 설정 규칙에 따라 DNS 호스트 이름은 단일 주소로 해결됩니다. 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 클러스터는 원래 Carbon Python Relay에 사용 된 일관된 해시 알고리즘에 따라 책임이있는 멤버에게 메트릭을 보냅니다. 복제가 1보다 높은 값으로 설정되면 여러 멤버가 가능합니다. dynamic 설정되면 서버의 실패는 해당 서버의 메트릭이 삭제되지 않지만 대신 미분식 메트릭은 메트릭이 손실되지 않기 위해 클러스터의 다른 서버로 전송됩니다. 복제가 1 일 때 가장 유용합니다.

  메트릭이 분배되는 방식을 정의하는 해시링의 계산은 서버 호스트 (또는 IP 주소)와 멤버의 선택 instance 기반으로합니다. 이것은 carbon_ch 다른 포트에서 두 대상을 사용하지만 동일한 호스트에서 동일한 해시키에 매핑되므로 메트릭의 분포가 발생하지 않습니다. 인스턴스는 해당 상황을 해결하는 데 사용됩니다. 인스턴스는 포트 후 멤버에게 추가되며 예를 들어 127.0.0.1:2006=a (예 : a 와 같은 부호로 분리됩니다. 인스턴스는 원래의 파이썬 카본 캐시에 의해 도입 된 개념이며, 그 구성에 따라 사용해야합니다.

  일관된 해시는 클러스터에서 멤버를 제거하면 모든 메트릭을 회원에게 완전히 다시 매핑하지 말고 제거 된 멤버의 메트릭 만 추가하여 남은 모든 구성원에게만 일관성이 있습니다. 다른 방법으로, 회원이 추가되면 각 멤버는 메트릭의 하위 집합이 새 멤버에게 전달되는 것을보아야합니다. 이는 정상적인 해시보다 중요한 이점이며, 각 멤버의 제거 또는 추가 (예 : IP 주소 또는 호스트 이름 변경을 통해)는 사용 가능한 모든 메트릭에 대한 모든 메트릭을 완전히 다시 매핑 할 수 있습니다.

• fnv1a_ch 클러스터

  fnv1a_ch 클러스터는 carbon_ch 와 탄소 C-C-Relay에 의해 도입 된 호환되지 않는 개선입니다. carbon_ch 가 사용하는 MD5 하링보다 빠른 다른 해시 기술 (FNV1A)을 사용합니다. 더 중요한 것은 fnv1a_ch 클러스터가 호스트와 포트를 사용하여 멤버를 구별하는 것입니다. 이것은 여러 대상이 포트로 분리 된 동일한 호스트에서 실시간 경우 유용합니다.

  fnv1a_ch 에서 instance 특성이 더 이상 필요하지 않기 때문에, 해시키가 계산되는 포트 문자열을 완전히 무시하는 데 사용됩니다. 해시키는 회원이받는 메트릭을 정의하기 때문에 이것은 중요한 측면입니다. 이러한 오버라이드는 기계가 최신 하드웨어로 마이그레이션 될 때 예를 들어 오래된 IP 주소를 가장하는 등 많은 것들을 허용합니다. 이에 대한 예는 10.0.0.5:2003=10.0.0.2:2003 입니다. 여기서 주소 5의 기계는 이제 주소 2에있는 기계의 메트릭을 수신합니다.

  인스턴스를 사용하면이 방법을 사용하면 기존 클러스터에서 마이그레이션을 수행하는 데 매우 유용 할 수 있습니다. 새로 설정 클러스터를 설정하려면 인스턴스를 사용하여 인스턴스를 사용하여 수신하는 메트릭에서 기계 위치를 분리 하여이 작업을 피할 수 있습니다. 예를 들어 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac 고려하십시오. 이를 통해 임의의 해시가 유지되었다고 가정 할 때, 레거시가 보이는 것을 처리하지 않고 여러 번 데이터를 수신하는 서버의 포트 및/또는 IP 주소를 변경할 수 있습니다. 인스턴스 이름은 전체 해시 입력으로 사용되므로 인스턴스는 a , b 등으로 해시가 입력이 거의 없기 때문에 해시 분포가 불량 될 수 있습니다. 이러한 이유로, 더 나은 해시 분포 동작을 위해 상기 예제에 사용되는 임의의 해시와 같은 더 길고 대부분 다른 인스턴스 이름을 사용하는 것을 고려하십시오.

• jump_fnv1a_ch 클러스터

  jump_fnv1a_ch 클러스터는 또한 이전 두와 같은 일관된 해시 클러스터이지만 멤버 호스트, 포트 또는 인스턴스를 전혀 고려하지는 않습니다. 이는이 클러스터 유형이 멤버가 정의되는 순서를 살펴 봅니다.이 순서에 대한 자세한 내용은 아래를 참조하십시오. 이것이 당신에게 유용한 지 여부는 시나리오에 따라 다릅니다. 이전의 일관된 해시 클러스터 유형과 달리 점프 해시는 클러스터에 정의 된 멤버들에 대한 거의 완벽한 균형을 갖추고 있습니다. 그러나 이는 모든 멤버에 대한 모든 메트릭을 완전히 다시 매핑하지 않고도 멤버를 제거 할 수 없지만 클러스터에서 마지막을 제거 할 수있는 비용으로 발생합니다. 이것이 기본적으로 의미하는 바는이 해시가 오래된 노드가 제거되지 않고 대신 교체되는 일정한 클러스터와 함께 사용하는 것이 좋습니다.

  오래된 노드를 제거하는 클러스터가있는 경우 점프 해시가 적합하지 않습니다. Jump Hash는 주문 목록에서 서버와 함께 작동합니다. 이 순서는 중요하므로 이전 클러스터 유형에 사용 된 인스턴스를 사용하여 명시 적으로 만들 수 있습니다. 멤버와 인스턴스가 제공되면 정렬 키로 사용됩니다. 이 인스턴스가 없으면 순서는 구성 파일에 주어진 것과 같습니다. 예를 들어 일부 구성 관리 소프트웨어에서 생성 할 때 변경되기 쉬울 수 있습니다. 따라서, 점프 해시에 대한 올바른 노드가 무엇인지 명시 적으로 인스턴스를 사용하여 서버의 순서를 수정하는 것이 좋을 것입니다. 이것들에 대해서는 숫자를 사용할 수 있지만 1, 2 및 10의 분류는 1, 10, 2를 1, 10, 2로 표시하는 것이 좋습니다. 대신 P0001, P0002, P0010과 같은 것을 사용하는 것이 좋습니다.

성냥

일치 규칙은 들어오는 메트릭을 하나 이상의 클러스터로 지시하는 방법입니다. 일치 규칙은 파일에 정의되어 있으므로 위에서 아래로 처리됩니다. 동일한 규칙에서 여러 경기를 정의 할 수 있습니다. 각 일치 규칙은 하나 이상의 클러스터로 데이터를 보낼 수 있습니다. stop 키워드가 추가되지 않는 한 일치 규칙이 "넘어지기"하므로 신중하게 제작 된 매치 표현식을 사용하여 여러 클러스터 또는 집계를 타겟팅 할 수 있습니다. 이 기능을 사용하면 메트릭을 복제하고 stop 키워드를 신중하게 주문하고 사용하여 특정 메트릭을 대체 클러스터로 보낼 수 있습니다. 특수 클러스터 blackhole 전송 된 메트릭을 버립니다. 이것은 어떤 경우에는 원치 않는 지표를 제거하는 데 유용 할 수 있습니다. 다른 일치가 동일한 데이터를 수락하는 경우 메트릭을 버리는 것이 무의미하기 때문에, 대상과의 일치는 암시 적 stop 가 있습니다. validation 검사 절은 정규 표현식 형태로 데이터 (메트릭 이후에 나오는)에 점검을 추가합니다. 이 표현식이 일치하면 매치 규칙이 유효성 검사 조항이없는 것처럼 실행됩니다. 그러나 실패하면 경기 규칙이 중단되고 지표가 목적지로 전송되지 않으면 drop 동작입니다. log 사용하면 메트릭이 stderr에 기록됩니다. 통나무 홍수를 피하기 위해 후자와 함께주의를 기울여야합니다. 유효성 검사 조항이 있으면 목적지를 참석할 필요가 없으므로 글로벌 검증 규칙을 적용 할 수 있습니다. 정리 규칙은 유효성 검사가 수행되기 전에 적용되므로 데이터에는 중복 공간이 없습니다. 절을 route using 일관된 해싱 루틴에 입력하는 데 사용되는 키에 대한 임시 수정을 수행하는 데 사용됩니다. 주요 목적은 트래픽을 라우팅하여 필요한 집계 인스턴스로 적절한 데이터를 전송하는 것입니다.

다시 작성하십시오

재 작성 규칙은 들어오는 메트릭과 일치하는 입력으로 정기적 인 표현식을 취하고 원하는 새 메트릭 이름으로 변환합니다. 교체에서, 배경 reference는 입력 정규 표현식에 정의 된 캡처 그룹을 일치시킬 수 있습니다. server.(x|y|z). 예를 들어 role.1. 대체에서. 필요한 경우 g{n} 표기법은 n 대신 g{1}100 과 같은 정수가 뒤 따르는 n 대신에 사용할 수 있습니다. 현재 재 작성 규칙의 구현에는 몇 가지 경고가 적용됩니다. 먼저, 구성 파일의 위치에서는 다시 쓰기가 수행되는시기를 결정합니다. 다시 쓰기는 다시 쓰기가 원래 이름과 일치하지 않는 일치 규칙과 일치하기 전에 매치 규칙이 원래 이름과 일치하지 않기 때문에 재 작성이 수행됩니다. 연속적으로 여러 번 다시 쓰기 규칙이 이루어질 수 있으므로 a b 로 대체되고 b c 대체됩니다. 현재 구현의 두 번째 경고는 새로 들어오는 메트릭과 같이 다시 쓰여진 메트릭 이름이 정리되지 않는다는 것입니다. 따라서 교체 문자열이 제작되도록 제작되면 이중 점과 잠재적 위험한 문자가 나타날 수 있습니다. 메트릭이 깨끗한 지 확인하는 것은 작가의 책임입니다. 이것이 라우팅에 문제가되는 경우, 모든 메트릭을 라우팅을 수행 할 다른 인스턴스로 전달하는 다시 쓰기 전용 인스턴스를 갖는 것을 고려할 수 있습니다. 분명히 두 번째 인스턴스는 메트릭이 들어올 때 메트릭을 정리할 것입니다. Backreference 표기법은 백 슬래시 직후에 밑줄 ( _ ) 및 Carret ( ^ ) 기호를 사용하여 대체 문자열을 소문자와 대문자를 허용합니다. 예를 들어, role._1. 대체는 1 의 내용을 2로 소속시킬 것입니다. 도트 ( . )는 유사한 방식으로 사용하거나 밑줄 또는 관리 후에 도트를 대체의 밑줄로 대체 할 수 있습니다. 이는 메트릭이 흑연으로 전송되는 일부 상황에서는 편리 할 수 ​​있습니다.

집계

정의 된 집계는 일치 규칙과 유사한 하나 이상의 규칙적인 수용으로 표현 된 하나 이상의 입력 메트릭을 취합니다. 들어오는 메트릭은 일정 기간에 걸쳐 몇 초 만에 정의됩니다. 이벤트가 조금 나중에 도착할 수 있으므로, 초기 시간의 만료 시간은 새로운 항목을 더 이상 추가 할 수 없으므로 집계가 최종 고려되어야하는시기를 정의합니다. 응집 외에도 다중 집계가 계산 될 수 있습니다. 그것들은 동일하거나 다른 집계 유형 일 수 있지만 독특한 새로운 메트릭에 쓸 수 있어야합니다. 메트릭 이름에는 다시 쓰기 표현식에서와 같이 후면 참조가 포함되어있어 많은 집계에서 생성하는 강력한 단일 집계 규칙이 가능합니다. 절차 send to 않은 경우, 생성 된 메트릭이 외부에서 제출 된 것처럼 릴레이로 전송되므로 일치 및 집계 규칙은 그에 적용됩니다. 이런 식으로 루프를 피할 수있는주의를 기울여야합니다. 이러한 이유로, 가능한 한 출력 트래픽을 지시하기 위해 송신 send to 를 권장합니다. 매치 규칙과 마찬가지로 여러 클러스터 대상을 정의 할 수 있습니다. 또한 일치 규칙과 마찬가지로 stop 키워드는 일치 프로세스에서 메트릭의 흐름을 제어하는 ​​데 적용됩니다.

통계

Construct send statistics to 더 이상 사용되지 않으며 다음 릴리스에서 제거됩니다. 대신 특수 statistics 구성을 사용하십시오.

statistics 구성은 릴레이에서 생성 한 (내부) 통계에 대한 몇 가지 사항을 제어 할 수 있습니다. 대상 send to 것은 통계를 특정 대상 클러스터로 전송하여 라우터 루프를 피하는 데 사용될 수 있습니다. 기본적으로 메트릭은 carbon.relays.<hostname> 으로 접두사로 표시되며, 여기서 HostName은 시작시 결정되고 -H 인수를 사용하여 재정의 할 수 있습니다. 이 접두사는 재 작성 규칙 대상과 유사한 조항이 prefix with 사용하여 설정할 수 있습니다. 이 경우 입력 일치는 호스트 이름에서 사전 설정된 정규식 ^(([^.]+)(..*)?)$ 입니다. 따라서 기본 접두사가 carbon.relays..1 에 의해 설정되어 있음을 알 수 있습니다. 이것은 다시 쓰기 규칙에서 replace-dot-with-underscore 교체 기능을 사용합니다. 입력 표현식이 주어지면 다음 경기 그룹이 사용할 수 있습니다. 1 전체 호스트 이름, 2 짧은 호스트 이름 및 3 도메인 이름 (주요 점). 특정 시나리오의 경우 carbon.relays._2 로 기본값을 대체하는 것이 합리적 일 수 있습니다. 특정 시나리오의 경우 항상 하위 기반의 짧은 호스트 이름을 사용하여 표현식을 따르는 데트가 포함되지 않습니다. 기본적으로, 60 초마다 메트릭이 제출되며, 이는 submit every <interval> seconds 을 ​​사용하여 변경 될 수 있으며, Carbon-Cache.py에보다 호환되는 값 세트를 얻으려면 reset counters after interval 사용하여 값이 아닌 값을 만들어 이전 값에 비해 변경을보고합니다.

청취자

릴레이가 listen 지시문을 사용하여 들어오는 연결을 청취 해야하는 포트 및 프로토콜을 지정할 수 있습니다. 현재 모든 청취자는 linemode 유형이어야합니다. 포트 및 IP 주소로 제공되는 포트 및 옵션 인터페이스 또는 파일 별 UNIX 소켓에 선택적 압축 또는 암호화 랩핑을 지정할 수 있습니다. 인터페이스가 지정되지 않은 경우 사용 가능한 모든 IP 프로토콜의 인터페이스가 가정됩니다. listen 지시문이 없으면 릴레이는 TCP 및 UDP에서 PORT 2003의 기본 리스너와 UNIX 소켓 /tmp/.s.carbon-c-relay.2003 을 사용합니다. 이는 일반적으로 IPv6 활성화 시스템의 5 개의 리스너로 확장됩니다. 기본값은 v3.2 이전의 버전의 동작과 일치합니다.

포함

구성이 매우 길어 지거나 별도의 파일에서 더 잘 관리되는 경우 include 지시문을 사용하여 다른 파일을 읽을 수 있습니다. 주어진 파일은 제자리에 읽히고 포함시 라우터 구성에 추가됩니다. 최종 결과는 하나의 큰 경로 구성입니다. 구성 파일 전체에서 다중 include 문을 사용할 수 있습니다. 포지셔닝은 정상적인 규칙 순서에 영향을 미칩니다. 재귀 적 포함 (포함 된 파일 include )이 지원되며 현재 포함 루프에 대한 보호 조치가 없습니다. 가치가있는 것에 대해,이 기능은 간단한 구성 파일 (예 : include 되지 않음)과 함께 사용되는 것이 가장 좋습니다.

예

카본 -C- 릴레이는 시간이 지남에 따라 진화하여 도구가 안정적이고 작업에 잘 맞는 것으로 입증되면서 수요가있는 기능이 증가했습니다. 아래는 릴레이와 함께 사용할 수있는 구성 요소의 주석이 달린 예제를 따르십시오.

클러스터는 필요한만큼 정의 할 수 있습니다. 일치 규칙에서 데이터를 수신하고 유형은 클러스터의 구성원이 마침내 메트릭 데이터를 얻는 것을 정의합니다. 가장 간단한 클러스터 양식은 forward 클러스터입니다.

 cluster send-through
    forward
        10.1.0.1
    ;

send-through Cluster로 전송 된 모든 메트릭은 단순히 IPv4 주소 10.1.0.1 의 서버로 전달됩니다. 여러 서버를 정의하면 모든 서버는 동일한 메트릭을 얻을 수 있습니다.

 cluster send-through
    forward
        10.1.0.1
        10.2.0.1
    ;

위의 결과는 메트릭이 두 기계에 전송됩니다. 이것은 유용 할 수 있지만 대부분은 그렇지 않습니다. any_of 클러스터 유형은 forward 나오지 만 각 수신 메트릭을 멤버에게 보냅니다. 그러한 클러스터와 동일한 예는 다음과 같습니다.

 cluster send-to-any-one
    any_of 10.1.0.1:2010 10.1.0.1:2011;

이것은 두 개의 서버가 사용되는 다중 경로 시나리오를 구현하고, 그 사이의 하중이 퍼지지 만, 그 중 하나라도 실패하면 모든 메트릭이 나머지 메트릭으로 전송됩니다. 이것은 일반적으로 업스트림 릴레이 또는 동일한 기계에서 실행되는 탄소 캐시 프로세스의 균형을 유지하는 데 적합합니다. 예를 들어 롤링 재시작으로 인해 모든 구성원을 사용할 수 없게되면 다른 구성원은 트래픽을받습니다. 2 차 서버가 처음으로 다운 된 경우에만 사용되는 진정한 실패를 가질 필요가있는 경우 다음은 다음을 구현합니다.

 cluster try-first-then-second
    failover 10.1.0.1:2010 10.1.0.1:2011;

이러한 유형은 두 가지 일관된 해시 클러스터 유형과 다릅니다.

 cluster graphite
    carbon_ch
        127.0.0.1:2006=a
        127.0.0.1:2007=b
        127.0.0.1:2008=c
    ;

이 예제의 멤버가 실패하면 해당 멤버로 이동하는 모든 메트릭이 대기열에 보관되어 회원이 돌아 오기를 기다립니다. 이것은 동일한 메트릭이 항상 동일한 서버에서 끝나는 것이 바람직한 탄소 캐시 기계의 클러스터에 유용합니다. carbon_ch 클러스터 유형은 Carbon-Relay 일관성 해시와 호환되며 탄소-릴레이로 채워진 기존 클러스터에 사용할 수 있습니다. 그러나 새 클러스터의 경우 fnv1a_ch 클러스터 유형을 사용하는 것이 좋습니다. 더 빠르기 때문에 carbon_ch 에 대한 구조에서 인스턴스 번호가없는 동일한 주소이지만 다른 포트에 대해 균형을 맞출 수 있습니다.

여러 클러스터를 사용할 수 있으므로 forward 클러스터 유형을 사용하지 않고도보다 지능적인 방식으로 복제 할 수도 있습니다.

 cluster dc-old
    carbon_ch replication 2
        10.1.0.1
        10.1.0.2
        10.1.0.3
    ;
cluster dc-new1
    fnv1a_ch replication 2
        10.2.0.1
        10.2.0.2
        10.2.0.3
    ;
cluster dc-new2
    fnv1a_ch replication 2
        10.3.0.1
        10.3.0.2
        10.3.0.3
    ;

match *
    send to dc-old
    ;
match *
    send to
        dc-new1
        dc-new2
    stop
    ;

이 예에서는 모든 들어오는 메트릭이 먼저 dc-old 로, dc-new1 로, 마지막으로 dc-new2 로 전송됩니다. 클러스터 유형의 dc-old 은 다릅니다. 각 들어오는 메트릭은 3 개의 클러스터 중 2 명에게 전송되므로 총 6 개의 목적지에서 복제됩니다. 각 클러스터에 대해 대상 멤버는 독립적으로 계산됩니다. 클러스터 나 멤버의 실패는 모두 개별 대기열을 가지고 있기 때문에 다른 사람들에게 영향을 미치지 않습니다. 위의 예는 각 DC의 세 가지 일치 규칙 또는 3 개의 DC 모두에 대해 1 개의 일치 규칙을 사용하여 작성할 수도 있습니다. 차이는 주로 성능에 있으며, 들어오는 메트릭의 표현과 일치 해야하는 횟수입니다. 이 예제에서는 더 이상 일치 규칙이 없기 때문에 dc-new Match 규칙의 stop 규칙은 엄격히 필요하지 않습니다. 그러나 일치가 특정 서브 세트 (예 ^sys. 예를 들어 다음의 약식 예에서와 같이 더 많은 클러스터가 정의되면 다음과 같이 필요할 수 있습니다.

 cluster dc1-sys ... ;
cluster dc2-sys ... ;

cluster dc1-misc ... ;
cluster dc2-misc ... ;

match ^sys. send to dc1-sys;
match ^sys. send to dc2-sys stop;

match * send to dc1-misc;
match * send to dc2-misc stop;

알 수 있듯이 DC2-SYS의 매치 규칙에서 stop 없이 sys. DC1-MISC 및 DC2-MISC로도 전송됩니다. 물론 이것은 필요할 수 있지만이 예에서는 sys 메트릭에 대한 전용 클러스터가 있습니다.

불행히도 생성되는 원치 않는 메트릭이 있다고 가정 해 봅시다. 나쁜/오래된 소프트웨어를 가정 해 봅시다. 우리는이 메트릭을 저장하고 싶지 않습니다. blackhole 클러스터는 실제로 원하는 모든 메트릭을 실제로 화이트리스트에 올리기가 더 어려울 때 적합합니다. 다음을 고려하십시오.

 match
        some_legacy1$
        some_legacy2$
    send to blackhole
    stop;

이것은 some_legacy 로 끝나는 모든 메트릭을 버릴 것입니다. 그렇지 않으면 걸러 내기가 어렵습니다. 주문이 중요하기 때문에 다음과 같은 구성에서 사용할 수 있습니다.

 cluster old ... ;
cluster new ... ;

match * send to old;

match unwanted send to blackhole stop;

match * send to new;

이 예에서 이전 클러스터는 새 클러스터에 원치 않는 메트릭을받습니다. 따라서 규칙이 발생하는 순서는 실행에 중요합니다.

검증을 사용하여 메트릭 데이터가 예상대로 보장 할 수 있습니다. 숫자 (부동 소수점 없음) 값에 대한 전역 검증은 다음과 같습니다.

 match *
    validate ^[0-9]+ [0-9]+$ else drop
    ;

(공간의 백 슬래시 있는 탈출에 유의하십시오. s 또는 [:space:] 대신, 구성된 Regex 구현에 따라 다를 수 있습니다.)

유효성 검사 절은 모든 일치 규칙에 존재할 수 있으므로 원칙적으로 다음은 유효합니다.

 match ^foo
    validate ^[0-9]+ [0-9]+$ else drop
    send to integer-cluster
    ;
match ^foo
    validate ^[0-9.e+-]+ [0-9.e+-]+$ else drop
    send to float-cluster
    stop;

이전 두 예제에서는 동작이 다릅니다. 클러스터 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.

BUGS

Please report them at: https://github.com/grobian/carbon-c-relay/issues

작가

Fabian Groffen <[email protected]>

SEE ALSO

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.