mirror of
https://github.com/prometheus/node_exporter.git
synced 2024-12-05 00:11:06 +01:00
c6914477f5
We actually have to count or sum, respectively, _all_ the selected metrics for the cluster-wide view. Which means it's easiest to use the `scalar` approach after all (but only in the cluster dashboard). This still propagates all the labels. I have extended the comment for the `nodeExporterSelector` to note that the cluster dashboard only makes sense if all the selected node exporter actually belong to the same cluster. Since this is jsonnet, users can easily disable the cluster dashboard. Or even create multiple instances of the dashboards with different `nodeExporterSelector`s for different clusters. Signed-off-by: beorn7 <beorn@grafana.com>
41 lines
1.8 KiB
Plaintext
41 lines
1.8 KiB
Plaintext
{
|
|
_config+:: {
|
|
// Selectors are inserted between {} in Prometheus queries.
|
|
|
|
// Select the metrics coming from the node exporter. Note that all
|
|
// the selected metrics are shown stacked on top of each other in
|
|
// the 'USE Method / Cluster' dashboard. Consider disabling that
|
|
// dashboard if mixing up all those metrics in the same dashboard
|
|
// doesn't make sense (e.g. because they are coming from different
|
|
// clusters).
|
|
nodeExporterSelector: 'job="node"',
|
|
|
|
// Select the fstype for filesystem-related queries. If left
|
|
// empty, all filesystems are selected. If you have unusual
|
|
// filesystem you don't want to include in dashboards and
|
|
// alerting, you can exclude them here, e.g. 'fstype!="tmpfs"'.
|
|
fsSelector: 'fstype!=""',
|
|
|
|
// Select the device for disk-related queries. If left empty, all
|
|
// devices are selected. If you have unusual devices you don't
|
|
// want to include in dashboards and alerting, you can exclude
|
|
// them here, e.g. 'device!="tmpfs"'.
|
|
diskDeviceSelector: 'device!=""',
|
|
|
|
// Some of the alerts are meant to fire if a critical failure of a
|
|
// node is imminent (e.g. the disk is about to run full). In a
|
|
// true “cloud native” setup, failures of a single node should be
|
|
// tolerated. Hence, even imminent failure of a single node is no
|
|
// reason to create a paging alert. However, in practice there are
|
|
// still many situations where operators like to get paged in time
|
|
// before a node runs out of disk space. nodeCriticalSeverity can
|
|
// be set to the desired severity for this kind of alerts. This
|
|
// can even be templated to depend on labels of the node, e.g. you
|
|
// could make this critical for traditional database masters but
|
|
// just a warning for K8s nodes.
|
|
nodeCriticalSeverity: 'critical',
|
|
|
|
grafana_prefix: '',
|
|
},
|
|
}
|