File: Graphite.html

package info (click to toggle)
collectl 3.7.4-1
  • links: PTS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 1,624 kB
  • ctags: 119
  • sloc: perl: 14,928; sh: 429; makefile: 11
file content (124 lines) | stat: -rw-r--r-- 6,040 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
<html>
<head>
<link rel=stylesheet href="style.css" type="text/css">
<title>Exporting Data to Graphite</title>
</head>

<body>
<center><h1>Exporting Data to Graphite</h1></center>
<p>
<h3>Introduction</h3>
<p>
With the release of Collectl Version 3.6.1, you can now send collectl data directly to <a href=http://graphite.wikidot.com>
graphite </a>.  For existing collectl users this now provides you with yet another way to store/plot collectl data, whether on
a single system or hundreds.  For graphite users who are not yet collectl users, you now have access to literally hundreds
of performance metrics:
<p>
<ul>
<li>Since all collectl instances collect this data at the same time, system noise on
clusters running fine-grained parallel jobs is reduced, though for larger clusters.</li>
<li>You can still log all the data collectl collects locally and only send a subset
to graphite, reducing the load on both graphite and your network.</li>
<li>You can monitor as infrequently as you like and send data to graphite at a
coarser frequency of either of the average, minimum or maximum values over that interval.</li>
<li>The r= switch, something unique to the graphite plugin, can help reduce the instantaneous 
load on the graphite server itself.</li>
<li>All this at collectl's low monitoring overhead</li>
</ul>

<h3>Usage</h3>
<p>
You use this export like any other, the only required option being the address to send the data to as in
the following example:

<div class=terminal>
<pre>
collectl --export graphite,192.168.1.113
</pre></div>

However you should also note that since by design this export does not provide any terminal output, there
are only 2 real ways to make sure it is doing what you expect, the first being to inspect graphite's
whisper storage area for your particular host name and make sure the data you're collecting is in fact
showing up there:

<div class=terminal>
<pre>
ls /opt/graphite/storage/whisper/poker
cpuload  cputotals  ctxint  disktotals  nettotals
</pre></div>

or to simply run with the debug mask set to 1, which tells the graphite module to echo all the data it is
sending to graphite, noting in this case even though collectl is collecting cpu, disk and network data we're
not sending cpu data to graphite.  This is something you might do if logging more data to disk than you are
sending to graphite, which in this case we are:

<div class=terminal>
<pre>
collectl --export graphite,192.168.1.113,d=1,s=dn -rawtoo -f /var/log/collectl
poker.disktotals.reads 0 1325609789
poker.disktotals.readkbs 0 1325609789
poker.disktotals.writes 0 1325609789
poker.disktotals.writekbs 0 1325609789
poker.nettotals.kbin 0 1325609789
poker.nettotals.pktin 1 1325609789
poker.nettotals.kbout 0 1325609789
poker.nettotals.pktout 0 1325609789
</pre></div>

<b><i>tip</i></b> - if you add 8 to the debug flag, eg <i>d=9</i>, this tells the graphite module not to 
actually establish the connection with graphite's carbon listener but to only echo the data that would 
have been sent.
<p>
Once you're happy with the switch settings, be sure to update the <i>DaemonCommands</i> in /etc/collectl.conf
and restart the collectl daemon to make them take effect.
<p>
<h3>Switches unique to graphite</h3>
<b>e=escape</b>
<br>When sending data to graphite, collectl prefaces each line item with the hostname.  If that name includes
a domain name, extra <i>dots</i> add additional levels the the variable names which may not be desireable.  By including
an escape character, those <i>dots</i> will be replaced by that character.
<p>
<b>r=seconds</b>
<br>
By design, collectl calls the export module as soon as the required data has been collected and collection
is synchronized to the nearest milli-seconds across a cluster, this means all instances of collectl will send 
their data to graphite at almost exactly the same time.   This high burst of data can overwhelm graphite and
so to reduce the load when that is found to be a problem, OR if you just want to smooth out the load you can
use <i>r=seconds</i> which literally means <i>delay sending your data to ganglia by a random number of micro-seconds
<= seconds</i>.
<p>
There is an additional caveat and that is that this stall must have completed by the end of the
current data collection periods and so you're restricted to a maximum delay of the interval less 1 second.
This means if you run collectl with -i1, you can't use -r.  However, since most users run collectl with
intervals of 5 or 10 seconds, values of 4 or 9 should be more than sufficient.  And if you choose a collection
interval of 30 seconds you may still want to use a value of r closer to 5 or 10 seconds so that the data will
arrive at graphite reasonablly close together.
<p>
For help with what other valid switches are, you can actually get the graphite module itself to tell
you like this:
<div class=terminal>
<pre>
collectl --export graphite,h
</pre></div>

<h3>Communications</h3>
<p>
Collectl will attempt to establish a TCP connection to the specified address/port, noting the default port is 2003.
If that connection cannot be established, collectl will report an error but <i>not</i> exit!  This is because
graphite itself may be down and need to be restarted.

<div class=terminal>
<pre>
collectl --export graphite,192.168.1.113,d=1,s=dn
Could not create socket to 192.168.1.113:2003.  Reason: Connection refused
</pre></div>

By design when collectl assumes the graphite address is correct and will try to reconnect every monitoring
interval.  Further, to avoid generating too many errors, it will silently continue to retry and only report
the connection failure every 100 times, a constant you can modify in the graphite.ph header if you really
care.  Once graphite comes back online collectl will again start sending data to it.
<p>
<table width=100%><tr><td align=right><i>updated November 9, 2012</i></td></tr></colgroup></table>

</body>
</html>