'tc': {
title: 'Quality of Service',
icon: '<i class="fa fa-globe" aria-hidden="true"></i>',
- info: 'Netdata collects and visualizes
tc class utilization using its <a href="https://github.com/firehol/netdata/blob/master/plugins.d/tc-qos-helper.sh" target="_blank">tc-helper plugin</a>. If you also use <a href="http://firehol.org/#fireqos" target="_blank">FireQOS</a> for setting up QoS, netdata automatically collects interface and class names. If your QoS configuration includes overheads calculation, the values shown here will include these overheads (the total bandwidth for the same interface as reported in the Network Interfaces section, will be lower than the total bandwidth reported here). QoS data collection may have a slight time difference compared to the interface (QoS data collection uses a BASH script, so a shift in data collection of a few milliseconds should be justified).'
+ info: 'Netdata collects and visualizes
<code>tc</code> class utilization using its <a href="https://github.com/firehol/netdata/blob/master/plugins.d/tc-qos-helper.sh" target="_blank">tc-helper plugin</a>. If you also use <a href="http://firehol.org/#fireqos" target="_blank">FireQOS</a> for setting up QoS, netdata automatically collects interface and class names. If your QoS configuration includes overheads calculation, the values shown here will include these overheads (the total bandwidth for the same interface as reported in the Network Interfaces section, will be lower than the total bandwidth reported here). QoS data collection may have a slight time difference compared to the interface (QoS data collection uses a BASH script, so a shift in data collection of a few milliseconds should be justified).'
},
'net': {
info: 'Readings of the configured system sensors.'
},
+ 'ipmi': {
+ title: 'IPMI',
+ icon: '<i class="fa fa-leaf" aria-hidden="true"></i>',
+ info: 'The Intelligent Platform Management Interface (IPMI) is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system\'s CPU, firmware (BIOS or UEFI) and operating system.'
+ },
+
'nfsd': {
title: 'NFS Server',
icon: '<i class="fa fa-folder-open" aria-hidden="true"></i>',
'web_log': {
title: undefined,
icon: '<i class="fa fa-file-text-o" aria-hidden="true"></i>',
- info: 'Information extracted from the web server log file. netdata <code>python.d/web_log</code> plugin incrementally parses web server log files to provide a real-time break down of key web server performance metrics. A special log file format is also supported (for <code>nginx</code> and <code>apache</code>) that allows netdata to extract timing information for the web server responses and bandwidth for both requests and responses. The <code>web_log</code> plugin can also be configured to provide a break down of requests per URL pattern (check <a href="https://github.com/firehol/netdata/blob/master/conf.d/python.d/web_log.conf" target="_blank"><code>/etc/netdata/python.d/web_log.conf</code></a>). netdata provides also several alarms based on the information on these charts, such as <b>too many bad requests</b>, <b>too many redirects</b>, <b>too many internal errros</b>, <b>unreasonably slow responses</b>, <b>too many requests</b> and <b>too few requests</b>.'
+ info: 'Information extracted from a web server log file. <code>web_log</code> plugin incrementally parses the web server log file to provide, in real-time, a break down of key web server performance metrics. An extended log file format may optionally be used (for <code>nginx</code> and <code>apache</code>) offering timing information and bandwidth for both requests and responses. <code>web_log</code> plugin may also be configured to provide a break down of requests per URL pattern (check <a href="https://github.com/firehol/netdata/blob/master/conf.d/python.d/web_log.conf" target="_blank"><code>/etc/netdata/python.d/web_log.conf</code></a>).'
},
'named': {
// information about the submenus
netdataDashboard.submenu = {
'web_log.bandwidth': {
- info: 'Bandwidth of requests (<code>received</code>) and responses (<code>sent</code>). <code>received</code> requires a
special file format (without it, the web server log does not have this information). This chart may present unusual spikes, since the whole bandwidth will be accounted at the time the log line is saved by the web server, even if the time needed to serve it spans across a longer duration. We suggest to use QoS (e.g. <a href="http://firehol.org/#fireqos" target="_blank">FireQOS</a>) for accurate accounting of the web server bandwidth.'
+ info: 'Bandwidth of requests (<code>received</code>) and responses (<code>sent</code>). <code>received</code> requires a
n extended log format (without it, the web server log does not have this information). This chart may present unusual spikes, since the bandwidth is accounted at the time the log line is saved by the web server, even if the time needed to serve it spans across a longer duration. We suggest to use QoS (e.g. <a href="http://firehol.org/#fireqos" target="_blank">FireQOS</a>) for accurate accounting of the web server bandwidth.'
},
'web_log.urls': {
- info: 'Number of requests for each
URL <code>category</code> (URL pattern) defined in <a href="https://github.com/firehol/netdata/blob/master/conf.d/python.d/web_log.conf" target="_blank"><code>/etc/netdata/python.d/web_log.conf</code></a>. This chart counts all requests matching the URL patterns defined, independently of the web server response codes (i.e. both successful and unsuccessful).'
+ info: 'Number of requests for each
<code>URL pattern</code> defined in <a href="https://github.com/firehol/netdata/blob/master/conf.d/python.d/web_log.conf" target="_blank"><code>/etc/netdata/python.d/web_log.conf</code></a>. This chart counts all requests matching the URL patterns defined, independently of the web server response codes (i.e. both successful and unsuccessful).'
},
'web_log.clients': {
},
'web_log.timings': {
- info: 'Web server response timings - the time the web server needed to prepare and respond to requests. This requires a special log format and its meaning is web server specific. For most web servers this accounts the time from the reception of a complete request, to the dispatch of the last byte of the response. So, it includes the network delays of responses, but it does not include the network delays of requests.'
+ info: 'Web server response timings - the time the web server needed to prepare and respond to requests. This requires an extended log format and its meaning is web server specific. For most web servers this accounts the time from the reception of a complete request, to the dispatch of the last byte of the response. So, it includes the network delays of responses, but it does not include the network delays of requests.'
},
'mem.ksm': {
height: 0.5
},
- 'web_log.response_codes': {
- info: 'Break down of web server responses by response code type. <code>1xx</code> are informational responses, <code>2xx</code> are successful responses, <code>3xx</code> are redirects, <code>4xx</code> are bad requests, <code>5xx</code> are internal server errors, <code>other</code> are non-standard responses, <code>unmatched</code> counts the lines in the log file that are not matched by the plugin (please <a href="https://github.com/firehol/netdata/issues/new?title=web_log%20reports%20unmatched%20lines&body=web_log%20plugin%20reports%20unmatched%20lines.%0A%0AThis%20is%20my%20log:%0A%0A%60%60%60txt%0A%0Aplease%20paste%20your%20web%20server%20log%20here%0A%0A%60%60%60" target="_blank">open a github issue</a> to help us fix it, if you have any unmatched lines).',
-
+ 'web_log.response_statuses': {
+ info: 'Web server responses by type. <code>success</code> includes <b>1xx</b>, <b>2xx</b> and <b>304</b>, <code>error</code> includes <b>5xx</b>, <code>redirect</code> includes <b>3xx</b> except <b>304</b>, <code>bad</code> includes <b>4xx</b>, <code>other</code> are all the other responses.',
mainheads: [
function(os, id) {
void(os);
return '<div data-netdata="' + id + '"'
- + ' data-dimensions="2xx"'
+ + ' data-dimensions="success"'
+ ' data-chart-library="gauge"'
+ ' data-title="Successful"'
- + ' data-units="requests"'
+ + ' data-units="requests/s"'
+ ' data-gauge-adjust="width"'
+ ' data-width="12%"'
+ ' data-before="0"'
+ ' data-points="CHART_DURATION"'
+ ' data-common-max="' + id + '"'
+ ' data-colors="' + NETDATA.colors[0] + '"'
+ + ' data-decimal-digits="0"'
+ ' role="application"></div>';
},
function(os, id) {
void(os);
return '<div data-netdata="' + id + '"'
- + ' data-dimensions="3xx"'
+ + ' data-dimensions="redirect"'
+ ' data-chart-library="gauge"'
+ ' data-title="Redirects"'
- + ' data-units="requests"'
+ + ' data-units="requests/s"'
+ ' data-gauge-adjust="width"'
+ ' data-width="12%"'
+ ' data-before="0"'
+ ' data-points="CHART_DURATION"'
+ ' data-common-max="' + id + '"'
+ ' data-colors="' + NETDATA.colors[2] + '"'
+ + ' data-decimal-digits="0"'
+ ' role="application"></div>';
},
function(os, id) {
void(os);
return '<div data-netdata="' + id + '"'
- + ' data-dimensions="4xx"'
+ + ' data-dimensions="bad"'
+ ' data-chart-library="gauge"'
+ ' data-title="Bad Requests"'
- + ' data-units="requests"'
+ + ' data-units="requests/s"'
+ ' data-gauge-adjust="width"'
+ ' data-width="12%"'
+ ' data-before="0"'
+ ' data-points="CHART_DURATION"'
+ ' data-common-max="' + id + '"'
+ ' data-colors="' + NETDATA.colors[3] + '"'
+ + ' data-decimal-digits="0"'
+ ' role="application"></div>';
},
function(os, id) {
void(os);
return '<div data-netdata="' + id + '"'
- + ' data-dimensions="5xx"'
+ + ' data-dimensions="error"'
+ ' data-chart-library="gauge"'
+ ' data-title="Server Errors"'
- + ' data-units="requests"'
+ + ' data-units="requests/s"'
+ ' data-gauge-adjust="width"'
+ ' data-width="12%"'
+ ' data-before="0"'
+ ' data-points="CHART_DURATION"'
+ ' data-common-max="' + id + '"'
+ ' data-colors="' + NETDATA.colors[1] + '"'
+ + ' data-decimal-digits="0"'
+ ' role="application"></div>';
}
]
},
+ 'web_log.response_codes': {
+ info: 'Web server responses by code family. According to the standards <code>1xx</code> are informational responses, <code>2xx</code> are successful responses, <code>3xx</code> are redirects (although they include <b>304</b> which is used as "<b>not modified</b>"), <code>4xx</code> are bad requests, <code>5xx</code> are internal server errors, <code>other</code> are non-standard responses, <code>unmatched</code> counts the lines in the log file that are not matched by the plugin (<a href="https://github.com/firehol/netdata/issues/new?title=web_log%20reports%20unmatched%20lines&body=web_log%20plugin%20reports%20unmatched%20lines.%0A%0AThis%20is%20my%20log:%0A%0A%60%60%60txt%0A%0Aplease%20paste%20your%20web%20server%20log%20here%0A%0A%60%60%60" target="_blank">let us know</a> if you have any unmatched).'
+ },
+
'web_log.response_time': {
mainheads: [
function(os, id) {
return '<div data-netdata="' + id + '"'
+ ' data-dimensions="avg"'
+ ' data-chart-library="gauge"'
- + ' data-title="Average Response"'
+ + ' data-title="Average Response Time"'
+ ' data-units="milliseconds"'
+ ' data-gauge-adjust="width"'
+ ' data-width="12%"'
+ ' data-after="-CHART_DURATION"'
+ ' data-points="CHART_DURATION"'
+ ' data-colors="' + NETDATA.colors[4] + '"'
+ + ' data-decimal-digits="2"'
+ ' role="application"></div>';
}
]
},
'web_log.detailed_response_codes': {
- info: 'Number of responses for each response code.'
+ info: 'Number of responses for each response code individually.'
},
'web_log.requests_per_ipproto': {
},
'web_log.clients': {
- info: 'Unique client IPs accessing the web server, within each data collection iteration. So, if data collection is <b>per second</b>, this chart shows <b>unique client IPs per second</b>.'
+ info: 'Unique client IPs accessing the web server, within each data collection iteration. If data collection is <b>per second</b>, this chart shows <b>unique client IPs per second</b>.'
},
'web_log.clients_all': {
projects / netdata.git / blobdiff