carbon c relay Download - carbon c relay Quellcode Download

Carbon-C-Relay (1)-Graphit-Relais, Aggregator und Rewriter

ZUSAMMENFASSUNG

carbon-c-relay -f Konfigurationsfile [ options ... ]

BESCHREIBUNG

Carbon-C-Relay akzeptiert, reinigt, übereinstimmt, übereinstimmt, umkämpft, weiterleitet und aggregiert Graphitmetriken, indem sie nach eingehenden Verbindungen anhören und die Nachrichten an andere in seiner Konfiguration definierte Server weitergeben. Die Kernfunktionen besteht darin, Nachrichten über flexible Regeln an die gewünschten Ziele weiterzuleiten.

Carbon-C-Relay ist ein einfaches Programm, das seine Routing-Informationen aus einer Datei liest. Mit den Befehlszeilenargumenten können der Speicherort für diese Datei sowie die Anzahl der Disponenten (Worker -Threads) festgelegt werden, um die Daten aus eingehenden Verbindungen zu lesen und an das rechte Ziel zu übergeben. Die Routendatei unterstützt zwei Hauptkonstrukte: Cluster und Übereinstimmungen. Die ersten definierten Gruppen von Hosts -Datenmetriken können gesendet werden. Letztere definieren, welche Metriken an welchen Cluster gesendet werden sollten. Aggregationsregeln werden als Übereinstimmungen angesehen. Umschreiben sind Aktionen, die die Metrik an dem Punkt, an dem sie in der Konfiguration erscheinen, direkt beeinflussen.

Für jede vom Relais erhaltene Metrik wird die Reinigung durchgeführt. Die folgenden Änderungen werden vor einer Übereinstimmung, der Aggregation oder der Umschreiben von Regel durch die Metrik vorgenommen:

Double DOT -Eliminierung (notwendig für die korrekt funktionierende konsistente Hash -Routing)
Nachlauf/führende Punktausscheidung
Whitespace -Normalisierung (dies beeinflusst die Ausgabe des Relais auf andere Ziele hauptsächlich: Metrik, Wert und Zeitstempel werden immer durch einen einzelnen Raum getrennt)
Der unregelmäßige Zeichensatz durch Unterstriche (_) ist derzeit unregelmäßig als nicht in [0-9a-zA-Z-_:#] definiert, kann jedoch in der Befehlszeile überschrieben werden. Beachten Sie, dass Tags (wenn vorhanden und erlaubt) nicht auf diese Weise verarbeitet werden.

Optionen

Diese Optionen steuern das Verhalten von Carbon-C-Relay .

-v : Versionszeichenfolge und Beenden.
-d : Aktivieren Sie den Debug -Modus, in dem Statistiken auf STDOut und zusätzliche Nachrichten über einige Situationen ausdrückt, die vom Relais auftreten, die normalerweise zu weitlich sind, um aktiviert zu werden. In Kombination mit -t (Testmodus) druckt dies auch Stubrouten und konsistente Hähne -Ringinhalte.
-s : Aktivieren Sie den Einreichungsmodus. In diesem Modus werden keine internen Statistiken generiert. Stattdessen werden Warteschlangendruck und Metriken bei Stdout gemeldet. Dieser Modus ist nützlich, wenn es als Übermittlungsrelais verwendet wird, der nur an (eine Reihe von) Hauptrelais weiterleitet. Statistiken über die Einreichungsrelais in diesem Fall sind nicht benötigt und können leicht zu einer nicht absorbierten Flut von Metriken führen, z. B. bei jedem Host vor Ort.
-S : Aktivieren Sie den Iostat-ähnlichen Modus, in dem jede Sekunde der aktuelle Status der Statistik gemeldet wird. Dies impliziert den Einreichungsmodus -s .
-t : Testmodus. In diesem Modus wird kein Routing durchgeführt, sondern liest stattdessen Eingaben von STDIN und druckt, welche Aktionen angesichts der geladenen Konfiguration ergriffen werden. Dieser Modus ist sehr nützlich, um Relaisrouten für die reguläre Expressionsyntax usw. zu testen. Er ermöglicht auch Einblicke, wie das Routing in komplexen Konfigurationen angewendet wird, da er auch Umschreiben und Aggregate zeigt. Wenn -t wiederholt wird, testet das Relais die Konfiguration nur auf die Gültigkeit und beendet sich unmittelbar danach aus. In diesem Modus wird jeder Standardausgang unterdrückt, sodass es ideal für Start-Skripte zum Testen einer (neuen) Konfiguration.
-f config-file : Konfiguration von config-file lesen. Eine Konfiguration besteht aus Clustern und Routen. Weitere Informationen zu den Optionen und der Syntax dieser Datei finden Sie unter Konfigurationssyntax.
-l log-file : Verwenden Sie die Protokoll-Datei zum Schreiben von Nachrichten. Ohne diese Option schreibt das Relais sowohl an stdout als auch an stderr . Bei der Anmeldung bei der Datei werden alle Nachrichten bei MSG vorangestellt, wenn sie an stdout gesendet wurden, und ERR wenn sie an Stderr gesendet wurden.
-p -Port : Hören Sie Verbindungen am Port -Port an . Die Portnummer wird sowohl für TCP , UDP als auch für UNIX sockets verwendet. Im letzteren Fall enthält die Socket -Datei die Portnummer. Der Port stand 2003 standardmäßig, das auch von der ursprünglichen carbon-cache.py verwendet wird. Beachten Sie, dass dies nur für die Standardeinstellungen gilt. Wenn listen Anweisungen in der Konfiguration in der Konfiguration sind, wird diese Einstellung ignoriert.
-w Arbeiter : Verwenden Sie die Anzahl der Fäden . Die Standardzahl der Arbeitnehmer entspricht der Menge der erkannten CPU -Kerne. Es ist sinnvoll, diese Zahl auf vielen Kernmaschinen zu reduzieren oder wenn der Verkehr niedrig ist.
-b BatchSize : Stellen Sie die Menge an Metriken fest, die gleichzeitig an Remote -Server gesendet werden, um BatchSize zu erhalten. Wenn das Relais Metriken an Server sendet, wird batchsize -Metriken aus der ausstehenden Warteschlange von Metriken abgerufen, die auf diesen Server warten und diese einzeln senden. Die Größe der Charge hat einen minimalen Einfluss auf die Sendungsleistung, kontrolliert jedoch die Menge an Schloss in der Warteschlange. Der Standard ist 2500 .
-q Queuesize : Jeder Server aus der Konfiguration, in dem das Relais Metriken sendet, ist mit einer Warteschlange zugeordnet. In dieser Warteschlange können Störungen und Bursts behandelt werden. Die Größe dieser Warteschlange wird in Warteschlangen eingestellt, wodurch diese Menge an Metriken in der Warteschlange gespeichert werden kann, bevor sie überläuft, und das Relais beginnt mit der Ablagerung von Metriken. Je größer die Warteschlange ist, desto mehr Metriken können absorbiert werden, aber auch mehr Speicher wird vom Relais verwendet. Die Standard -Warteschlangengröße beträgt 25000 .
-L Stände : Legt die maximale Stände auf Stände auf Stände fest, bevor das Relais für einen Server Metriken fallen lässt. Wenn sich eine Warteschlange füllt, verwendet das Relais einen Mechanismus, der bezeichnet wird, um dem Client (Schreiben in das Relais) dieses Ereignisses zu signalisieren. Insbesondere wenn der Kunde eine große Anzahl von Metriken in sehr kurzer Zeit (Burst) sendet, kann das Stalling dazu beitragen, Metriken abzugeben, da der Client nur ein wenig verlangsamen muss, was in vielen Fällen möglich ist (z. B. beim Katzenieren einer Datei mit nc (1)). Dieses Verhalten kann jedoch auch die Autoren künstlich behindern, die das nicht einfach aufhalten können. Dazu können die Stände von 0 auf 15 eingestellt werden, wobei jeder Stand ca. 1 Sekunde auf den Client dauern kann. Der Standardwert ist auf 4 festgelegt, was auf das gelegentliche Störungsszenario und maximale Anstrengungen abzielt, um keine Metriken mit mäßiger Verlangsamung der Kunden zu verlieren.
-C CacertPath : Lesen Sie CA -Zertifikate (zur Verwendung mit TLS/SSL -Verbindungen) aus dem angegebenen Pfad oder der Datei. Wenn nicht angegeben, werden die Standardstandorte verwendet. Wenn Sie die Peer-Peer-Peer-Verfasste durchführen, wird bei der Verwendung selbstsignierter Zertifikate das CA-Zertifikat in den Standardstandort aufgenommen oder mit dieser Option den Pfad zum Zertifikat angeben.
-T Timeout : Gibt die IO -Zeitüberschreitung in Millisekunden an, die für Serververbindungen verwendet werden. Der Standardwert beträgt 600 Millisekunden, muss jedoch zunehmen, wenn WAN -Links für Zielserver verwendet werden. Ein relativ geringem Wert für die Verbindungszeitüberschreitung ermöglicht es dem Relais, einen Server schnell einzurichten, und als solche Failover -Strategien, bevor die Warteschlange hoch läuft.
-c chars : Definiert die Charaktere, die neben [A-Za-z0-9] in Metriken zu Chars zulässig sind. Jedes Zeichen, das nicht in dieser Liste ist, wird durch das Relais durch _ (Unterstrich) ersetzt. Die Standardliste der zulässigen Zeichen ist -_:# .
-m Länge : Begrenzt die metrischen Namen, die höchstens Länge von Bytes lang sind. Alle Zeilen, die metrische Namen enthalten, werden verurteilt.
-M Länge begrenzt den Eingang auf Linien von höchstens Länge Bytes. Alle überschüssigen Linien werden verworfen. Beachten Sie, dass -m kleiner sein muss als dieser Wert.
-H Hostname : Überschreiber -Hostname, bestimmt durch einen Anruf bei gethostname (3) mit Hostname . Der Hostname wird hauptsächlich in den Statistikmetriken verwendet carbon.relays.<hostname>.<...>
-B Rückstand : Legt die TCP -Verbindung ein, die Backlog -Backlog -Verbindungen anhören. Der Standardwert beträgt 32, aber auf Servern, die viele gleichzeitige Verbindungen erhalten, muss diese Einstellung wahrscheinlich erhöht werden, um zu vermeiden, dass Verbindungsfehler bei den Clients abgelehnt werden.
-U bufsize : Legt die Socket -Send-/Empfangen -Puffergrößen in Bytes für TCP- und UDP -Szenarien fest. Wenn nicht festgelegt wird, wird das Betriebssystemverwaltungssatz verwendet. Das Maximum wird auch durch das Betriebssystem bestimmt. Die Größen werden mit Setsockopt mit den Flags So_rcvbuf und So_sndbuf eingestellt. Die Einstellung dieser Größe kann für Szenarien mit großer Lautstärke erforderlich sein, für die auch -B gelten kann. Das Überprüfen des Recv-Q und der Empfangsfehlerwerte von Netstat gibt einen guten Hinweis auf die Verwendung von Puffer.
-E : Deaktivieren Sie die Trennung von Leerlaufanschlüssen. Standardmäßig trennt das Relais die Leerlauf -Client -Verbindungen nach 10 Minuten. Dies ist zu verhindern, dass Ressourcen verstopfen, wenn ein fehlerhafter oder bösartiger Kunde Verbindungen öffnet, ohne sie zu schließen. In der Regel wird das Ausführen der Dateideskriptoren verhindert. Für einige Szenarien ist es jedoch nicht wünschenswert, dass Leerlaufverbindungen getrennt werden, weshalb das Übergeben dieses Flags dieses Verhalten deaktiviert wird.
-D : Deamonise in den Hintergrund nach dem Start. Diese Option müssen ebenfalls -l und -P -Flags festgelegt werden.
-P PIDFILE : Schreiben Sie die PID des Relay -Prozesses in eine Datei namens PIDFile . Dies ist insbesondere dann nützlich, wenn es in Kombination mit Init -Managern daemonisiert wird.
-O Schwellenwert : Die Mindestanzahl von Regeln, die Sie finden sollten, bevor Sie versuchen, den Regeln zu optimieren. Die Standardeinstellung ist 50 , um den Optimierer zu deaktivieren, verwenden -1 , um die Optimierern immer auszuführen 0 . Der Optimierer versucht, Regeln zu gruppieren, um zu vermeiden, dass übermäßige Zeit für übereinstimmende Ausdrücke verbringen.

Konfigurationssyntax

Die Konfigurationsdatei unterstützt die folgende Syntax, wobei die Kommentare mit einem # Zeichen beginnen und an einer beliebigen Position in einer Zeile angezeigt werden und die Eingaben bis zum Ende dieser Zeile unterdrücken können:

 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>
    ;

Cluster

Mehrere Cluster können definiert werden und müssen nicht durch eine Übereinstimmungsregel verwiesen werden. Alle Cluster verweisen auf einen oder mehrere Hosts, mit Ausnahme des file , der in Dateien im lokalen Dateisystem schreibt. host kann eine IPv4- oder IPv6 -Adresse oder ein Hostname sein. Da Host von einem optionalen : und Port folgt, muss IPv6 -Adressen, die nicht falsch interpretiert werden, entweder ein Port angegeben werden oder die von Klammern umgebene IPv6 -Adresse, z. [::1] . Optionale transport und proto können verwendet werden, um die Verbindung in eine Komprimierung oder Verschlüsselungsschicht zu wickeln oder die Verwendung von UDP oder TCP zur Verbindung zum Remote -Server anzugeben. Wenn die Verbindung weggelassen wird, standardt es zu einer einfachen TCP -Verbindung. type kann im Moment nur linemode sein, z. B. Pythons Gurkenmodus wird nicht unterstützt.

DNS -Hostnamen werden gemäß den Präferenzregeln in RFC 3484 in eine einzige Adresse gelöst. Die any_of , failover und forward -Cluster haben eine explizite useall -Flag, die eine Erweiterung für Hostnames -Lösung auf mehrere Adressen ermöglicht. Mit dieser Option wird jede Adresse eines beliebigen Typs zu einem Clusterziel. Dies bedeutet zum Beispiel, dass sowohl IPv4- als auch IPv6 -Adressen hinzugefügt werden.

Es gibt zwei Gruppen von Clustertypen, einfache Weiterleitungscluster und konsequente Hashing -Cluster.

forward und file
Die forward und file senden einfach alles, was sie empfangen, an die definierten Mitglieder (Host -Adressen oder Dateien). Wenn ein Cluster mehrere Mitglieder hat, werden alle eingehenden Metriken an alle Mitglieder gesendet, wodurch der Eingangsmetrikstrom über alle Mitglieder im Grunde genommen dupliziert wird.
any_of Cluster
Der any_of -Cluster ist eine kleine Variante des forward , aber anstatt die Eingangsmetriken an alle definierten Mitglieder zu senden, sendet er jede eingehende Metrik nur an eines der definierten Mitglieder. Der Zweck davon ist ein Szenario, in dem eines der Mitglieder eine Metrik erhalten kann. Wie any_of vorschlägt, erhalten die verbleibenden verfügbaren Mitglieder, wenn eines der Mitglieder nicht erreichbar ist, sofort den vollständigen Eingangsstrom von Metriken. Dies bedeutet speziell, dass bei Verwendung von 4 Mitgliedern jeweils ungefähr 25% der Eingangsmetriken erhalten. Wenn ein Mitglied nicht verfügbar ist (z. B. Unterbrechung des Netzwerks oder ein Neustart des Dienstes), erhalten die verbleibenden 3 Mitglieder jeweils etwa 25% / 3 = ~ 8% mehr Verkehr (33%). Alternativ erhalten sie 1/3 die Gesamteingabe. Bei der Gestaltung der Clusterkapazität sollte man berücksichtigen, dass das endgültige verbleibende Mitglied im extremsten Fall den gesamten Eingangsverkehr erhält.
Ein any_of -Cluster kann insbesondere nützlich sein, wenn der Cluster auf andere Relais oder Caches verweist. Wenn es mit anderen Relais verwendet wird, wird es effektiv geladen und passt sich sofort an die Unvereinbarkeit von Zielen an. Wenn es mit Caches verwendet wird, gibt es ein kleines Detail zu der Funktionsweise any_of , was es sehr geeignet macht. Die Implementierung dieses Routers besteht nicht darin, über die verfügbaren Mitglieder zu runden, sondern verwendet eine konsistente Hashing-Strategie, um die gleichen Metriken ständig an dasselbe Ziel zu liefern. Dies hilft Caches und erleichtert das Abrufen von nicht übereinstimmenden DataPoints (aus einem einzigen Cache), ermöglicht jedoch einen rollenden Neustart der Caches. Wenn ein Mitglied nicht verfügbar ist, werden die Hash -Ziele nicht geändert, sondern der Verkehr, der für den nicht verfügbaren Knoten bestimmt ist, gleichmäßig über verfügbare Knoten verteilt.
failover -Cluster
Der failover -Cluster ist wie der any_of -Cluster, hält sich jedoch an der Reihenfolge, in der Server definiert sind. Dies soll ein reines Failover -Szenario zwischen Servern implementieren. Alle Metriken werden an höchstens 1 Mitglied gesendet, sodass kein Hashing oder Ausgleich stattfindet. Beispielsweise sendet ein failover -Cluster mit zwei Mitgliedern nur Metriken an das zweite Mitglied, wenn das erste Mitglied nicht verfügbar ist. Sobald das erste Mitglied zurückkehrt, werden alle Metriken erneut an den ersten Knoten gesendet.
carbon_ch Cluster
Der carbon_ch -Cluster sendet die Metriken an das Mitglied, das gemäß dem konsistenten Hash -Algorithmus verantwortlich ist, wie im ursprünglichen Carbon -Python -Relais verwendet. Mehrere Mitglieder sind möglich, wenn die Replikation auf einen Wert höher als 1 eingestellt ist. Wenn dynamic festgelegt ist, führt der Fehler eines der Server nicht dazu, dass Metriken für diesen Server fallen gelassen werden, sondern dass die nicht zustellbaren Metriken an einen anderen Server im Cluster gesendet werden, damit die Metriken nicht verloren werden können. Dies ist am nützlichsten, wenn die Replikation 1 ist.
Die Berechnung des Hashrings, der die Art und Weise definiert, wie Metriken verteilt werden, basiert auf dem Server -Host (oder der IP -Adresse) und der optionalen instance des Mitglieds. Dies bedeutet, dass die Verwendung carbon_ch zwei Ziele an verschiedenen Ports jedoch auf demselben Host demselben Hashkey zugeordnet wird, was bedeutet, dass keine Verteilung der Metriken stattfindet. Die Instanz wird verwendet, um diese Situation zu beheben. Eine Instanz wird nach dem Port an das Mitglied beigefügt und durch ein Gleichen Zeichen getrennt, z. B. 127.0.0.1:2006=a zum Beispiel a . Instanzen sind ein Konzept, das durch ursprüngliche Python-Carbon-Cache eingeführt wird und gemäß der Konfiguration dieser verwendet werden muss.
Konsistente Hashes sind in dem Sinne konsistent, dass die Entfernung eines Mitglieds aus dem Cluster nicht zu einer vollständigen Wiederherstellung aller Metriken zu den Mitgliedern führen sollte, sondern dass alle verbleibenden Mitglieder nur die Metriken vom entfernten Mitglied zu einem angemessenen Anteil hinzufügen. Wenn ein Mitglied hinzugefügt wird, sollte jedes Mitglied eine Teilmenge seiner Metriken sehen, die jetzt an das neue Mitglied gerichtet werden. Dies ist ein wichtiger Vorteil gegenüber einem normalen Hash, bei dem jede Entfernung oder Zugabe von Mitgliedern (auch über eine Änderung ihrer IP-Adresse oder Hostname) eine vollständige Wiederherstellung aller Metriken gegenüber allen verfügbaren Metriken verursachen würde.
fnv1a_ch cluster
Der fnv1a_ch Cluster ist eine inkompatible Verbesserung zu carbon_ch , die von Carbon-C-Relay eingeführt wird. Es verwendet eine andere Hash-Technik (FNV1A), die schneller als die von carbon_ch verwendete MD5-Hashing ist. Noch wichtiger ist, dass fnv1a_ch -Cluster sowohl Host als auch Port verwenden, um die Mitglieder zu unterscheiden. Dies ist nützlich, wenn mehrere Ziele auf demselben Host leben, das gerade per Port getrennt ist.
Da die instance auf diese Weise mit fnv1a_ch nicht mehr erforderlich ist, wird sie verwendet, um den Host: Port -Zeichenfolge vollständig zu überschreiben, dass der Hashkey berechnet wird. Dies ist ein wichtiger Aspekt, da der Hashkey definiert, welche Metriken ein Mitglied erhält. Eine solche Überschreibung ermöglicht viele Dinge, einschließlich des Maskierens alter IP -Adressen z. B. wenn eine Maschine in neuere Hardware migriert wurde. Ein Beispiel hierfür wäre 10.0.0.5:2003=10.0.0.2:2003 , wobei eine Maschine an der Adresse 5 nun die Metriken für eine Maschine erhält, die an der Adresse 2 war.
Während die Verwendung von Instanzen auf diese Weise sehr nützlich sein kann, um Migrationen in vorhandenen Clustern durchzuführen, können Instanzen diese Arbeiten vermeiden, indem sie eine Instanz vom ersten Tag an den Maschinenstandort von den von ihm erhältlichen Metriken abnehmen. Betrachten Sie zum Beispiel 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac , wobei ein zufälliger Hash als Beispiel verwendet wird. Dies würde es ermöglichen, den Port und/oder die IP -Adresse des Servers zu ändern, der Daten so oft empfängt, ohne dass ein Vermächtnis sichtbar ist, vorausgesetzt, der zufällige Hash wird beibehalten. Beachten Sie, dass der Instanzname, da der Instanzname als vollständige Hash -Eingabe verwendet wird, Instanzen als a , b usw. wahrscheinlich zu einer schlechten Hash -Verteilung führen, da ihre Hashes nur sehr wenig Eingaben haben. Aus diesem Grund sollten Sie längere und meist unterschiedliche Instanznamen wie zufällige Hashes verwenden, die im obigen Beispiel für ein besseres Hash -Verteilungsverhalten verwendet werden.
jump_fnv1a_ch Cluster
Der Cluster jump_fnv1a_ch ist auch ein konsistenter Hash -Cluster wie die beiden vorherigen, aber er berücksichtigt den Mitgliedshost, den Port oder die Instanz überhaupt nicht. Dies bedeutet, dass dieser Cluster -Typ die Reihenfolge untersucht, in der Mitglieder definiert sind. Weitere Informationen finden Sie auch weiter unten. Ob dies für Sie nützlich ist, hängt von Ihrem Szenario ab. Im Gegensatz zu den beiden vorherigen konsistenten Hash -Cluster -Typen hat der Sprung -Hash einen fast perfekten Ausgleich über die im Cluster definierten Mitglieder. Dies geht jedoch zu Lasten, um kein Mitglied, sondern das letzte aus dem Cluster zu entfernen, ohne alle Mitglieder eine vollständige Wiederherstellung aller Metriken zu verursachen. Dies bedeutet im Grunde, dass dieser Hash in Ordnung ist, um mit ständigen oder ständig wachsenden Clustern zu verwenden, in denen ältere Knoten niemals entfernt, sondern stattdessen ersetzt werden.
Wenn Sie einen Cluster haben, bei dem die Entfernung alter Knoten stattfindet, ist der Sprung -Hasch nicht für Sie geeignet. Jump Hash arbeitet mit Servern in einer bestellten Liste. Da diese Reihenfolge wichtig ist, kann sie unter Verwendung der Instanz, wie sie in früheren Clustertypen verwendet werden, explizit gemacht werden. Wenn eine Instanz mit den Mitgliedern gegeben wird, wird sie als Sortierschlüssel verwendet. Ohne diese Instanz wird die Reihenfolge wie in der Konfigurationsdatei angegeben, die möglicherweise zu Änderungen anfällig ist, wenn z. B. von einer Konfigurationsverwaltungssoftware generiert wird. Daher ist es wahrscheinlich eine gute Praxis, die Reihenfolge der Server mit Instanzen so zu beheben, dass die richtigen Knoten für den Sprung -Hash ausdrücklich sind. Man kann nur Zahlen für diese verwenden, aber wissen Sie, dass die Sortierung von 1, 2 und 10 in 1, 10, 2 führt.

Übereinstimmungen

Übereinstimmungsregeln sind der Weg, um eingehende Metriken auf einen oder mehrere Cluster zu lenken. Übereinstimmungsregeln werden von oben nach unten verarbeitet, da sie in der Datei definiert sind. Es ist möglich, mehrere Übereinstimmungen in derselben Regel zu definieren. Jede Match -Regel kann Daten an einen oder mehrere Cluster senden. Da die Übereinstimmungsregeln "durchfallen", es sei denn, das stop -Keyword wird hinzugefügt, kann sorgfältig gefertigte Übereinstimmungsausdruck verwendet werden, um mehrere Cluster oder Aggregationen abzuzielen. Diese Fähigkeit ermöglicht es, Metriken zu replizieren und bestimmte Metriken an alternative Cluster mit sorgfältiger Bestellung und Verwendung des stop -Keywords zu senden. Der Special Cluster blackhole verwirft alle Metriken, die darauf gesendet werden. Dies kann in bestimmten Fällen nützlich sein, um unerwünschte Metriken auszurotten. Da das Abwerfen von Metriken sinnlos ist, wenn andere Übereinstimmungen dieselben Daten akzeptieren würden, hat eine Übereinstimmung mit als Ziel, die Blackhole -Cluster, einen impliziten stop . Die validation fügt den Daten (was nach der Metrik) in Form eines regulären Ausdrucks eine Überprüfung hinzugefügt hat. Wenn dieser Ausdruck übereinstimmt, wird die Match -Regel so ausgeführt, als wäre keine Validierungsklausel vorhanden. Wenn es jedoch fehlschlägt, wird die Match -Regel abgebrochen und es werden keine Metriken an Ziele gesendet, dies ist das drop . Wenn log verwendet wird, wird die Metrik an Stderr angemeldet. Mit letzterem sollte darauf geachtet werden, dass laute Überschwemmungen vermieden werden. Wenn eine Validierungsklausel vorhanden ist, müssen Ziele nicht vorhanden sein. Dies ermöglicht die Anwendung einer globalen Validierungsregel. Beachten Sie, dass die Reinigungsregeln vor Abschluss der Validierung angewendet werden. Daher haben die Daten keine doppelten Räume. Die route using wird verwendet, um eine temporäre Änderung an dem Schlüssel durchzuführen, der für die Eingabe der konsistenten Hashing -Routinen verwendet wird. Der Hauptzweck besteht darin, den Verkehr so zu leiten, dass geeignete Daten an die erforderlichen Aggregationsinstanzen gesendet werden.

Umschreiben

Umschreiben Regeln nehmen einen regelmäßigen Ausdruck als Eingabe an, um die eingehenden Metriken zu entsprechen, und verwandeln sie in den gewünschten neuen metrischen Namen. Beim Ersatz dürfen Backreferenzen im regulären Ausdruck der Eingabe erfasst werden. Eine Übereinstimmung von server.(x|y|z). Ermöglicht die Verwendung von EG role.1. in der Substitution. Bei Bedarf kann eine Notation von g{n} anstelle von n verwendet werden, wobei die Rückführung von einer Ganzzahl wie g{1}100 folgt. Einige Einschränkungen gelten für die aktuelle Implementierung von Umschreiben von Regeln. Zunächst bestimmt ihr Speicherort in der Konfigurationsdatei, wann das Umschreiben durchgeführt wird. Das Umschreiben erfolgt als eine solche Match-Regel, bevor das Umschreiben mit dem ursprünglichen Namen übereinstimmt. Eine Übereinstimmungsregel, nachdem das Umschreiben nicht mehr mit dem ursprünglichen Namen übereinstimmt. Mit der Bestellung sollte darauf geachtet werden, dass mehrere Umschreibungsregeln in Folge stattfinden können, z. a wird durch b ersetzt und b in einer nachfolgenden Umschreibungsregel durch c ersetzt. Die zweite Einschränkung bei der aktuellen Implementierung besteht darin, dass die neu geschriebenen metrischen Namen nicht gereinigt werden, wie es neu eingehende Metriken sind. Somit können doppelte Punkte und potenzielle gefährliche Zeichen erscheinen, wenn die Ersatzschnur gefertigt wird, um sie zu produzieren. Es liegt in der Verantwortung des Schriftstellers, sicherzustellen, dass die Metriken sauber sind. Wenn dies ein Problem für das Routing ist, kann man in Betracht ziehen, eine Neuschreibe-Instanz zu haben, die alle Metriken an eine andere Instanz weiterleitet, die das Routing ausführt. Offensichtlich reinigt die zweite Instanz die Metriken, wenn sie hereinkommt. Die Hinterreferenznotation ermöglicht die Unterkasse und Großbuchstaben mit der Verwendung des Unterstrichs ( _ ) und Carret ( ^ ), die direkt nach dem Backflash folgen. Zum Beispiel role._1. Da Substitution den Inhalt von 1 unterbrochen wird. Der Punkt ( . ) Kann auf ähnliche Weise verwendet oder nach dem Unterstrich oder der Pflege gefolgt werden, um Punkte durch Unterstriche in der Substitution zu ersetzen. Dies kann für einige Situationen nützlich sein, in denen Metriken an Graphit gesendet werden.

Aggregationen

Die definierten Aggregationen nehmen eine oder mehrere Eingangsmetriken an, die von einer oder mehreren regulären Exträsionen ausgedrückt werden, ähnlich wie die Übereinstimmungsregeln. Eingehende Metriken werden über einen Zeitraum, der durch das Intervall in Sekunden definiert wird, aggregiert. Da Ereignisse möglicherweise etwas später eintreffen, definiert die Ablaufzeit in Sekunden, wann die Aggregationen als endgültig angesehen werden sollten, da keine neuen Einträge mehr hinzugefügt werden dürfen. Zusätzlich zur Aggregation können mehrere Aggregationen berechnet werden. Sie können die gleichen oder unterschiedlichen Aggregationstypen haben, sollten aber in eine einzigartige neue Metrik schreiben. Die metrischen Namen können Rückenreferenzen wie im Umschreiben von Ausdrücken enthalten, die leistungsstarke Regeln für einzelne Aggregation ermöglichen, die in vielen Aggregationen ergeben. Wenn kein send to Klausel angegeben wird, werden produzierte Metriken an das Relais gesendet, als ob sie von außen eingereicht wurden, daher gelten die Übereinstimmungs- und Aggregationsregeln für diese. Es sollte darauf geachtet werden, dass Schleifen auf diese Weise vermieden werden. Aus diesem Grund wird die Verwendung der send to Klausel ermutigt, den Ausgangsverkehr nach Möglichkeit zu lenken. Wie bei Match -Regeln ist es möglich, mehrere Clusterziele zu definieren. Ebenso wie Match -Regeln gilt das stop -Keyword für die Steuerung des Metrikenflusss im Übereinstimmungsprozess.

STATISTIKEN

Die send statistics to sind veraltet und werden in der nächsten Veröffentlichung entfernt. Verwenden Sie stattdessen das spezielle statistics .

Das statistics kann einige Dinge über die (internen) Statistiken steuern, die vom Relais erzeugt werden. Mit dem send to Ziel kann Router -Schleifen vermieden werden, indem die Statistiken an einen bestimmten Zielcluster gesendet werden. Standardmäßig werden -H Metriken mit carbon.relays.<hostname> Dieses Präfix kann mit dem prefix with Klausel mit einem Umschreiber -Regelziel eingestellt werden. Die Eingabeübereinstimmung in diesem Fall ist der voreingestellte reguläre Ausdruck ^(([^.]+)(..*)?)$ Im Hostnamen. Als solches kann man sehen, dass das Standardpräfix durch carbon.relays..1 . Beachten Sie, dass dies die Ersatz-Dot-with-aborscore-Ersatzfunktion von Umschreibregeln verwendet. Angesichts des Eingangsausdrucks sind die folgenden Übereinstimmungsgruppen verfügbar: 1 Der gesamte Hostname, 2 Der kurze Hostname und 3 Der Domainname (mit führender Punkt). Es kann sinnvoll sein, die Standardeinstellung durch so etwas wie carbon.relays._2 Standardmäßig werden die Metriken alle 60 Sekunden eingereicht. Dies kann unter Verwendung der Klausel reset counters after interval submit every <interval> seconds geändert werden, um einen kompatibleren Satz von Werten in Carbon-Cache zu erhalten.

ZUHÖRER

Die Ports und Protokolle, die das Relais auf eingehende Verbindungen anhören sollte, können mithilfe der listen angegeben werden. Derzeit müssen alle Zuhörer einen linemode -Typ sein. Für den Port und die optionale Schnittstelle, die durch die IP -Adresse oder die UNIX -Socket nach Datei angegeben ist, kann eine optionale Komprimierung oder Verschlüsselungsverpackung angegeben werden. Wenn die Schnittstelle nicht angegeben ist, wird die Schnittstelle für alle verfügbaren IP -Protokolle angenommen. Wenn keine listen vorhanden ist, verwendet das Relais die Standardhörer für Port 2003 unter TCP und UDP sowie den UNIX-Socket /tmp/.s.carbon-c-relay.2003 . Dies erweitert sich in der Regel auf 5 Hörer auf einem IPv6 -fähigen System. Die Standardeinstellung entspricht dem Verhalten von Versionen vor V3.2.

Inklusive

Falls die Konfiguration sehr lang wird oder in separaten Dateien besser verwaltet wird, kann die Anweisung include werden, um eine andere Datei zu lesen. Die angegebene Datei wird zum Zeitpunkt der Inklusion zur Routerkonfiguration hinzugefügt und hinzugefügt. Das Endergebnis ist eine große Routenkonfiguration. In der gesamten Konfigurationsdatei können mehrere include verwendet werden. Die Positionierung wird die Reihenfolge der Regeln als normal beeinflussen. Achten Sie darauf, dass eine rekursive Einbeziehung (aus einer eingeschlossenen Datei include ) unterstützt wird und derzeit keine Schutzmaßnahmen für eine Einschlussschleife vorhanden sind. Für das, was es wert ist, wird diese Funktion wahrscheinlich am besten mit einfachen Konfigurationsdateien verwendet (z. B. wenn sie nicht in diese include sind).

Beispiele

Carbon-C-Relay entwickelte sich im Laufe der Zeit und wachsende Merkmale bei Bedarf, da sich das Tool als stabil erwies und gut an der Arbeit passte. Folgen Sie unten einige kommentierte Beispiele für Konstrukte, die mit dem Relais verwendet werden können.

Cluster können so viel wie nötig definiert werden. Sie erhalten Daten aus den Übereinstimmungsregeln, und ihr Typ definiert, welche Mitglieder des Clusters schließlich die metrischen Daten erhalten. Die einfachste Clusterform ist ein forward :

 cluster send-through
    forward
        10.1.0.1
    ;

Jede an den send-through -Cluster gesendete Metrik wird einfach an den Server unter IPv4-Adresse 10.1.0.1 weitergeleitet. Wenn wir mehrere Server definieren, würden alle diese Server die gleiche Metrik erhalten, also:

 cluster send-through
    forward
        10.1.0.1
        10.2.0.1
    ;

Die obigen führt zu einer Duplikation von Metriken, die an beide Maschinen gesendet werden. Dies kann nützlich sein, aber die meiste Zeit ist es nicht. Der any_of -Clustertyp ist wie forward , sendet jedoch jede eingehende Metrik an eines der Mitglieder. Das gleiche Beispiel mit einem solchen Cluster wäre:

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

Dies würde ein Multipath -Szenario implementieren, in dem zwei Server verwendet werden. Die Last zwischen ihnen ist verteilt, aber sollte einer von ihnen versagen, alle Metriken werden an die verbleibenden gesendet. Dies eignet sich in der Regel gut für vorgelagerte Relais oder für das Ausgleich von Carbon-Cache-Prozessen, die auf derselben Maschine ausgeführt werden. Sollte ein Mitglied nicht verfügbar sein, zum Beispiel aufgrund eines rollenden Neustarts erhalten die anderen Mitglieder den Verkehr. Wenn es notwendig ist, echte Fehler zu haben, wobei der Sekundärserver nur dann verwendet wird, wenn der erste nicht mehr ist, würde Folgendes implementieren:

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

Diese Typen unterscheiden sich von den beiden konsistenten Hash -Cluster -Typen:

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

Wenn ein Mitglied in diesem Beispiel fehlschlägt, werden alle Metriken, die an dieses Mitglied gehen würden, in der Warteschlange gehalten und darauf warten, dass das Mitglied zurückkehrt. Dies ist nützlich für Cluster von Carbon-Cache-Maschinen, bei denen es wünschenswert ist, dass die gleiche Metrik immer auf demselben Server landet. Der carbon_ch Clustertyp ist mit konsistenten Carbon-Relay-Hash kompatibel und kann für vorhandene Cluster verwendet werden, die durch Carbon-Relay besiedelt sind. Für neue Cluster ist es jedoch besser, den Clustertyp fnv1a_ch zu verwenden, denn er ist schneller und ermöglicht es, über die gleiche Adresse, aber unterschiedliche Ports ohne Instanznummer auszugleichen, in carbon_ch .

Da wir mehrere Cluster verwenden können, können wir auch ohne intelligentere Weise replizieren, ohne den forward zu verwenden:

 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
    ;

In diesem Beispiel werden alle eingehenden Metriken zuerst an dc-old , dann dc-new1 und schließlich an dc-new2 gesendet. Beachten Sie, dass der Clustertyp des dc-old unterschiedlich ist. Jede eingehende Metrik wird an 2 Mitglieder aller drei Cluster gesendet, wodurch in insgesamt 6 Ziele nachgebildet wird. Für jeden Cluster werden die Zielmitglieder unabhängig berechnet. Das Versagen von Clustern oder Mitgliedern wirkt sich nicht auf die anderen aus, da alle individuelle Warteschlangen haben. Das obige Beispiel könnte auch mit drei Übereinstimmungsregeln für jeden DC oder einer Übereinstimmungsregel für alle drei DCs geschrieben werden. Der Unterschied liegt hauptsächlich in der Leistung, sobald die eingehende Metrik gegen einen Ausdruck abgeglichen werden muss. Die stop in der dc-new -Match-Regel ist in diesem Beispiel nicht unbedingt erforderlich, da es keine folgenden Übereinstimmungsregeln mehr gibt. Wenn die Übereinstimmung jedoch auf eine bestimmte Teilmenge abzielt, z ^sys. und weitere Cluster würden definiert, dies könnte notwendig sein, wie zum Beispiel im folgenden Abkürzungsbeispiel:

 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;

Wie zu sehen ist, ohne den stop in der DC2-SYS-Match-Regel, alle Metriken, beginnend mit sys. würde auch an DC1-MISC und DC2-MISC senden. Es kann natürlich sein, dass dies natürlich gewünscht wird, aber in diesem Beispiel gibt es einen speziellen Cluster für die sys -Metriken.

Angenommen, es würde eine unerwünschte Metrik geben, die leider generiert wird, nehmen wir eine schlechte/alte Software an. Wir wollen diese Metrik nicht speichern. Der blackhole -Cluster ist dafür geeignet, wenn es schwieriger ist, die Whitelist alle Metriken zu wollen. Betrachten Sie Folgendes:

 match
        some_legacy1$
        some_legacy2$
    send to blackhole
    stop;

Dies würde alle Kennzahlen wegwerfen, die mit some_legacy enden, das wäre ansonsten schwer herauszufiltern. Da die Bestellung wichtig ist, kann sie in einem solchen Konstrukt verwendet werden:

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

match * send to old;

match unwanted send to blackhole stop;

match * send to new;

In diesem Beispiel würde der alte Cluster die Metrik erhalten, die für den neuen Cluster unerwünscht ist. Die Reihenfolge, in der die Regeln auftreten, ist also für die Ausführung von Bedeutung.

Die Validierung kann verwendet werden, um sicherzustellen, dass die Daten für Metriken erwartungsgemäß sind. Eine globale Validierung für nur Zahl (kein schwimmender Punkt) Werte könnte sein:

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

(Beachten Sie die Flucht mit Backslash des Raums. Möglicherweise können Sie s oder [:space:] Stattdessen von Ihrer konfigurierten REGEX -Implementierung abhängt.)

Die Validierungsklausel kann in jeder Match -Regel vorhanden sein. Im Prinzip ist Folgendes gültig:

 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;

Beachten Sie, dass das Verhalten in den beiden vorherigen Beispielen unterschiedlich ist. Wenn kein send to Cluster angegeben wird, verhalten ein Validierungsfehler das Übereinstimmung wie das stop -Keyword vorhanden ist. Ebenso wird die Verarbeitung mit der nächsten Regel fortgesetzt. 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

STATISTIKEN

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.
Verbindungen
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

AUTOR

Fabian Groffen <[email protected]>

ACKNOWLEDGEMENTS

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.

Expandieren