Enable prometheus node exporter by default #19
1 changed files with 5 additions and 2 deletions
|
@ -5,8 +5,11 @@
|
||||||
enable = true;
|
enable = true;
|
||||||
port = 9100;
|
port = 9100;
|
||||||
# Aligned with https://git.rwth-aachen.de/fsdmath/server/prometheus/-/blob/main/node_exporter/etc/default/prometheus-node-exporter
|
# Aligned with https://git.rwth-aachen.de/fsdmath/server/prometheus/-/blob/main/node_exporter/etc/default/prometheus-node-exporter
|
||||||
# Original reasons are for these lists are unknown, but along the lines
|
# It was compiled along the following steps:
|
||||||
|
|||||||
# “This looks useless for VMs, but that seems nice.”
|
# 1. Does the current Debian release supports the collector?
|
||||||
|
# 2. Is the collector depracated in the latest release?
|
||||||
|
# 3. Could you probably use the collected metrics for monitoring or are they useless because they make no sense in our context
|
||||||
|
# (e.g. power adapter inside a VM, use fibre port connection)?
|
||||||
disabledCollectors = [
|
disabledCollectors = [
|
||||||
"arp"
|
"arp"
|
||||||
"bcache"
|
"bcache"
|
||||||
|
|
Loading…
Reference in a new issue
Maybe we should rethink this list. Even if we end up with the same list, but a less
shitty justification.
Initially the list was created with the following three aspects in mind:
Because the scraped metrics are not saved on the monitored host itself but on the monitoring host (Cthugha) for a limited time span, space allocation should not be considered a problem. You could restrict the collectors only to the actually used ones, but because rolling out those configurations on all hosts (especially those running without Nix) is a pain (which would be necessary every time you want to use a currently unexported metric) and the export itself doesn't harm, I think the current set of exporters is fine.
Does cthugha needs support for them? Because if not 1.) is not the right constraint for nix machines.
Also if that is the real justification, that should be what the comment says and not that they kinda looked nice.
It depends on what you mean by "support for them":
Because
The justification in the comment could actually be better, but is not as wrong as your answer could suggest. The initial selection of collectors is somewhat arbitrary. In fact I'm not using all exported metrics for alerting, but only a (small to medium sized) subset of the available ones. Some metrics are actively used in alerting (e.g.
collector.systemd
,collector.time
andcollector.textfile
) while could be used in a nice way in future setups (e.g.collector.mdadm
,collector.cpufreq
andcollector.nfsd
). The latter example enables the export of metrics about software RAIDs (mdadm
) and NFS servers (nfsd
), which are things definitly not used at the moment in our infrastructure (at least to my knowledge), but probably could be used in future use case. Explicitly disabled are only exporters which are not useful at all, because of the VM environment, the constant resolution of arp information within our internal network (monitoring ARP tables in a constant server network doesn't make any sense to me), the absence of required hardware or because of performance problems (udp_queue).I would suggest keeping the list roughly symmetric, but adding the new collectors not available in Debian Bullseye. Shrinking the list of available metrics (in comparison to other hosts) could lead to unexpected results like alerts not firing for a specific host because the used metrics from that host were not available (absence of metrics -> empty dataset for that host -> no data to compare rule against -> no alert firing in case of problem).
With “support for them” I meant if this only applies to the host with the exporter or also to cthuga (which is a debian machine right?)
So you say it is advisable to have on all machines the same list of exporters and not enable exporters selectively?