2012-10-17 10 views
5

Ho cercato tutto questo ma non ho trovato nessuno che parli di come configurare e configurare StatsD e Graphite per comunicare su server separati. Al momento ho tutto in esecuzione su uno, ma ho tentato senza successo di separarli.Come configurare StatsD e Graphite per l'esecuzione su server diversi

Ecco come ho configurato il StatsD exampleConfig.js

exampleconfig 
{ 
    graphitePort: 2003 
, graphiteHost: "(graphite server IP)" 
, port: 8125 
} 

L'unica altra cosa che posso pensare di impostare sull'altro box è il example-client.py.

currently it says this: 
CARBON_SERVER = '127.0.0.1' 
CARBON_PORT = 2003 

Penso che sia necessario che l'host locale comunichi con un sussurro o una grafite sullo stesso server. Ho il mio setup del firewall per ascoltare 2003, e Usando un dump del pacchetto il server ottiene l'UDP da statsd. Semplicemente non sembra essere consumato dal carbonio e dalla grafite.

Cosa mi manca?
Inoltre, cosa è consigliato per ridimensionare la configurazione della grafite statsd? Ho statsd da solo adesso e grafite + carbon + whisper su un altro server. Le statistiche hanno il maggior potere di esecuzione o è la scatola di grafite? Mi sto chiedendo questo perché presto invierò milioni di bit di dati ai server per i test.

risposta

3

Modifica example-client.py

Se si desidera eseguire il example-client.py su un server diverso che esegue l'istanza di grafite/carbonio. Quindi sarà necessario modificare CARBON_SERVER con l'indirizzo IP del server grafite/carbone. Test


rete

Si potrebbe voler anche fare un paio di test rapidi per assicurarsi che i processi sono in ascolto sulle porte correzione che la aspettano e la rete sottostante consentirà a questa comunicazione.

Sul server che esegue grafite/carbonio si dovrebbe essere in grado di verificare se il server accetta le connessioni da più di un semplice localhost tramite la lsof comando

$ lsof -Pi:2003 
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 
carbon-ca 1596 graphite 7u IPv4 9517  0t0 TCP *:2003 (LISTEN) 

Si può vedere da quanto sopra che ho avere un processo di cache di carbone in esecuzione e in ascolto su tutte le interfacce su TCP 2003.

Un test molto semplice dalla macchina remota sarebbe quello di fare una connessione telnet al server di grafite/carbone sulla porta che sta ascoltando (default: 2003) e vedere se funziona.

Esempio di un socket di ascolto *

$ telnet graphite-server 2003 
Trying graphite-server... 
Connected to graphite-server. 
Escape character is '^]'. 
^] 
telnet> quit 
Connection closed. 

Esempio di un socket chiuso *

$ telnet graphite-server 2003 
Trying graphite-server... 
telnet: Unable to connect to remote host: Connection refused 
1

Così ho finalmente scoperto il problema.Stavo partendo dal presupposto che le statistiche non solo ricevessero UDP ma anche trasmettessero l'UDP al carbonio. Dopo aver realizzato che statsd invia TCP, sono stato in grado di adattare il mio firewall e ora funziona alla grande. Ho lasciato CARBON_SERVER come host locale.

Grazie!

Quali sono i modi migliori per scalare grafite/carbonio? Dovrei separare il carbonio dalla grafite? È possibile? Il carbonio affatica il processore più della grafite?

+0

Come probabilmente avete scoperto ormai, l'interfaccia grafica web non è nulla di cui preoccuparsi. Poiché il carbonio produce enormi quantità di piccole scritture su disco, gli IOps saranno il collo di bottiglia prima che CPU o RAM entrino nell'equazione. – Sergio

+0

Ho appena avuto lo stesso problema con un firewall che consente UDP tra StatsD e Graphite sulla porta 2003. Non è affatto ovvio che StatsD dialoghi con Graphite via TCP. Grazie! – bbrown