Prometheus2 does no longer support the command-line flag to specify
an alertmanager. Instead it now supports both service discovery and
configuration of alertmanagers in the alerting config section.
Simply mapping the previous option to an entry in the new alertmanagers
section is not enough to allow for complete configurations of an
alertmanager.
Therefore the option alertmanagerURL is no longer used and instead
a full alertmanager configuration is expected.
Since version 3.0 all allowed IPs and subnets are exposed by the
exporter. With `-s` set on the CLI, instead of a comma-separated list,
each allowed IP and subnet will be in a single field with the schema
`allowed_ip_<index>`.
This is a simple exporter which exports the information
provided by `wg show all dump` to prometheus.
Co-authored-by: Franz Pletz <fpletz@fnordicwalking.de>
This makes sure that when a user hasn't set a Prometheus option it
won't show up in the prometheus.yml configuration file. This results
in smaller and easier to understand configuration files.
We previously filtered out the `_module` attribute in a NixOS
configuration by filtering it using the option's `apply` function.
This meant that every option that had a submodule type needed to have
this apply function. Adding this function is easy to forget thus this
mechanism is error prone.
We now recursively filter out the `_module` attributes at the place we
construct the Prometheus configuration file. Since we now do the filtering
centrally we don't have to do it per option making it less prone to errors.
This results in a smaller prometheus.yml config file.
It also allows us to use the same options for both prometheus-1 and
prometheus-2 since the new options for prometheus-2 default to null
and will be filtered out if they are not set.
This results in a simpler service unit which doesn't first have to
start a shell:
> cat /nix/store/s95nsr8zbkblklanqpkiap49mkwbaq45-unit-alertmanager.service/alertmanager.service
...
ExecStart=/nix/store/4g784lwcy7kp69hg0z2hfwkhjp2914lr-alertmanager-0.16.2-bin/bin/alertmanager \
--config.file /nix/store/p2c7fyi2jkkwq04z2flk84q4wyj2ggry-checked-config \
--web.listen-address [::1]:9093 \
--log.level warn
...
As the configuration for the exporters and alertmanager is unchanged
between the two major versions this patch tries to minimize
duplication while at the same time as there's no upgrade path from 1.x
to 2.x, it allows running the two services in parallel. See also #56037
https://github.com/golang/go/issues/9334 describes how net.Listen (as used by Alertmanager):
* listens on 127.0.0.1 if the listenAddress is "localhost"
* listens on all interfaces if the listenAddress is ""
Instead of setting User/Group only when DynamicUser is disabled, the
previous version of the code set it only when it was enabled. This
caused services with DynamicUser enabled to actually run as nobody, and
services without DynamicUser enabled to run as root.
Regression from fbb7e0c82f.
This commit adds an assertion that checks that either `configFile` or
`configuration` is configured for alertmanager. The alertmanager config
can not be an empty attributeset. The check executed with `amtool` fails
before the service even has the chance to start. We should probably not
allow a broken alertmanager configuration anyway.
This also introduces a test for alertmanager configuration that piggy
backs on the existing prometheus tests.
With `promtool` we can check the validity of a configuration before
deploying it. This avoids situations where you would end up with a
broken monitoring system without noticing it - since the monitoring
broke down. :-)
Use nixos-fw chain instead of INPUT so that the rules don't keep
stacking everytime the firewall is reloaded.
This also adds a comment to each rule about the associated exporter.
- prometheus exporters are now configured with
`services.prometheus.exporters.<name>`
- the exporters are now defined by attribute sets
from which the options for each exporter are generated
- most of the exporter definitions are used unchanged,
except for some changes that should't have any impact
on the functionality.
Alertmanager 0.13.0 doesn't support single dash long options, so '-config.file'
for example is parsed as '-c', which leads to the service not starting.
The behaviour have changed again. Listed collectors are now enabled in
addition to the default one.
Also run as DynmicUser instead of user nobody as the exporter doesn't need
any state.
* prometheus-collectd-exporter service: init module
Supports JSON and binary (optional) protocol
of collectd.
* nixos/prometheus-collectd-exporter: submodule is not needed for collectdBinary
The reason being less mental overhead when reading upstream
documentation. Examples can be pasted right into the configuration
instead of translating to Nix attrset first.
The current default value of listenAddress = null blows up:
$ nixos-rebuild build
error: cannot coerce null to a string, at
.../nixpkgs/nixos/modules/services/monitoring/prometheus/alertmanager.nix:97:16
With listenAddress = "" we use the same default as upstream and there is
no blow up :-)
...by providing a default value of "no labels" (an empty attrset).
Without this change we get
$ nixos-rebuild test -I nixpkgs=.
building Nix...
building the system configuration...
error: The option `services.prometheus.scrapeConfigs.[definition 1-entry 1].static_configs.[definition 1-entry 1].labels' is used but not defined.
which is unneeded, because labels _are_ optional.
The structured options are incomplete compared to upstream and I think
it will be a maintenance burden to try to keep up. Instead, provide an
option for the raw config file contents (prometheus.yml).
