.png)
Ich möchte Graphite verwenden, um Metriken von verschiedenen Servern zu sammeln. Standardmäßig hört Carbon auf allen Schnittstellen auf 2003, was für mich in Ordnung ist.
Theoretisch könnte nun jeder Messdaten dorthin senden. Gibt es eine Standardmethode, um dies zu verhindern (ähnlich wie bei der HTTP-Basisauthentifizierung) oder muss ich mich mit IP-basierten Einschränkungen der physischen Schnittstelle herumschlagen?
Antwort1
Es hängt davon ab, wie stark Sie Graphitknoten „härten“ möchten (wobei „Graphit“ eine beliebige Mischungstopologie aus Carbon-Relays, Carbon-Caches, Speicher-Backend und möglicherweise Graphit-Web/API ist).
Wenn Sie wissen, welche Hosts in Ihrem NetzwerksollenWenn Sie Metriken an Graphite senden (normalerweise Relays), können Sie die Firewall-Regeln Ihres Graphite-Hosts so ändern, dass sie entweder eine explizite Liste von Host-IPs oder einen Bereich für die entsprechenden Ports erwarten. Oder Sie könnten etwas Ähnliches im Edge-Netzwerk von der Firewall oder dem Router aus tun – da kann ich Ihnen keinen Rat geben, da Ihre Frage keinen umfassenderen Überblick darüber gibt, wie Ihre Topologie aussieht.
Ein alternativer Ansatz wäre, die AMQP-Unterstützung zu verwenden, damit Ihre Knoten ihre Metriken stattdessen als authentifizierter Benutzer an einen Broker veröffentlichen und dann Ihre Graphite-Hosts die Host-Firewall so ändern, dass nur TCP 2003 vom Broker akzeptiert wird, wenn Metriken empfangen werden. Der Vorteil hierbei ist, dass Ihre Graphite-KnotennurSie müssen wissen, von welchen Broker-Metriken es kommt, was alle Firewall-Regeln des Hosts drastisch vereinfacht. Wenn Knoten Metriken über einen leichtgewichtigen Dienst veröffentlichen, ist die Sicherheit etwas besser, da Ihre „Vertrauens“-Bedenken am Anfang des Flusses berücksichtigt werden und nicht die Möglichkeit besteht, dass Metriken – legitim oder nicht – bei Ihrem Graphite-Host (bzw. Ihren Graphite-Hosts) ankommen. RabbitMQ ist OSS und ziemlich einfach zu starten, ohne dass Sie sich zu sehr mit der Konfiguration herumschlagen müssen, wenn Sie das Management-Plugin einbinden. Der Großteil der Konfiguration besteht darin, die für den Betrieb erforderlichen Ports zu öffnen.
Dies macht jedoch einen einfachen Metrik-Publisher für die Graphite-Topologie für die Aufgabe etwas komplexer und etabliert ein Pub/Sub-Modell dafür, wie Ihre Metriken zu Graphite gelangen (hat aber einen netten Nebeneffekt, da Metriken während der Übertragung möglicherweise nicht verloren gehen). Außerdem wird ein weiterer Host hinzugefügt, der im Rahmen des Betriebs gesichert werden muss.
Um noch weiter zu gehen, könnten Sie ein Protokollüberwachungssystem implementieren, um die Datei listener.log von Carbon-Relay zu überwachen, da es für jede empfangene und verarbeitete Metrik eine Zeile schreibt. Auf hoher Ebene würden Sie dieses Protokoll auf Ausnahmen von den erwarteten Metriken überwachen. Wenn Sie beispielsweise eine Metrik server.cpu.load haben, würden Sie erwarten, dass diese verarbeitet wird, aber eine gepostete Metrik namens foo.bar.value ist ungültig. Als Reaktion auf ein solches Ereignis könnten Sie einfach das entsprechende Verzeichnis löschen, das Whisper für den ungültigen Namespace erstellt (wenn Sie Whisper zur Speicherung verwenden).
Die Härtung von Graphites Kohlenstoff-Relais und Kohlenstoff-Cache ist gut und eine kluge Sache, aber vergessen Sie nicht, dass es genauso besorgniserregend ist überWHOkönnen auf Ihre Graphite-Webanwendung oder Graphite-API zugreifen, um diese Metriken abzurufen.