The config for services in puppet-prometheus module listen on
0.0.0.0 by default. However, when config listens to private IP,
services will fail to start because "After=network.target" doesn't
ensure network interface up. It's safer to use
"After=network-online.target" here

Fix download of beanstalkd_exporter for versions newer than 1.0.0

…_daemon_systemd_template

Update network denendency in daemon systemd template

Implement unbound_exporter

* bind exporter support

* add tests

* fix robocop warnings

* fix download URLs

* bind: remove update tests as there's only one version

* fix download url *again*

* fix download extension type, it can be (and is) empty

* properly set download_url parameters

* mark the url_base as optional, enforce https (!)

* this is not an archive after all

* add support for scrape_job_labels from 8.x

* catchup with the newer bind_exporter version (0.4.0

* convert to puppet strings

* move defaults to the class

This way they show up in the REFERENCE.md documentation

* add missing documentation variables

* mark download_url as optional

* fix some linter warning

Without this change, when the install_method is set to `package` and
init_style is set to `none`, the various `prometheus::server` settings
will never do anything because we stop touching the systemd config
file.

By deploying the env_file_path on the server, we allow the "Debian
package" setup (install_method=package and init_style=none) to
propagate the daemon_flags correctly.

By default, the Debian systemd.service file has this entry:

    EnvironmentFile=/etc/default/prometheus
    ExecStart=/usr/bin/prometheus $ARGS

... which makes it use the ARGS define in the "default" config
file.

This is a subset of #303, which should hopefully pass tests and be
more manageable.

Closes: #323

Should be a noop

convert daemon.env template to EPP

For some reason, the node exporter unit test checks for the
inexistence of the bird_exporter config file. Naturally, it doesn't
find it (why would it?).

I suspect this is an artifact of a copy-paste from the bird exporter,
and what was really meant here was to check for the inexistence of the
node exporter config file.

The logic here is that if init_style is non, then we have no control
over the init files themselves *except* through the environment
file.

Typically, the way this works is there is a ARGS environment variable
that gets sucked into the systemd unit file (or the sysv init file).

The previous version of this code left the file lying around if the
env_vars values were emptied. Proper practice should make sure that
file is garbage-collected if unmanaged.

For some reason, the bird exporter thinks that file should be created
even though it doesn't use init_style=none or
install_method=package. Sure, it does have default options, but it
seems that should normally not get triggered with default parameters.

This should make sure we don't create the env files when the env is
empty.

The default scrape_uri in the prometheus apache exporter actually has
a trailing slash. This matters because somehow, here, the address
without a trailing slash fails to scrape.

The default is documented here:

https://github.com/Lusitaniae/apache_exporter/blob/83d8e4d2003eaa85c754d12c110e0a7757e78143/apache_exporter.go#L30

Unit tests adjusted to match change.

this is necessary now that #531 has been merged in

check node exporter config file instead of bird in node exporter test

fix default scrape_uri in apache_exporter

deploy env_file_path on server

pass options through env_vars if no control over init files

bird_exporter: Update 1.2.4 -> 1.2.5

When using the Debian package to deploy the exporter, like this:

    class { 'prometheus::apache_exporter':
      package_ensure    => $package_ensure,
      service_ensure    => $service_ensure,
      export_scrape_job => true,
      install_method    => 'package',
      init_style        => 'none',
      user              => 'prometheus',
      group             => 'prometheus',
      package_name      => 'prometheus-apache-exporter',
      service_name      => 'prometheus-apache-exporter',
    }

... we end up with the options in
`/etc/default/prometheus-apache-exporter`. It *looks* like it will be
fine: the systemd unit file sucks those in as an environment variable,
and then passes that along to the process. But look closely at what
actually gets generated:

    ARGS="--scrape_uri "http://localhost/server-status/?auto" "

This kind of looks okay if you squint a little, but it actually turns
out it's really, really wrong. What it ends up doing is basically
this:

        apache-exporter --scrape_uri "http://localhost/server-status/?auto "

Notice the trailing slash here. When the exporter makes the request to
Apache next, it ends up doing this query:

    GET /server-status/?auto  HTTP/1.1
    [...]

At first glance, this looks fine: just a regular HTTP request, right?
But if you look more closely, there are *two* spaces before the
HTTP/1.1 Apache doesn't like that, *at all*. It doesn't even wait for
the rest of the headings to come in, it immediately answers with:

    HTTP/1.1 400 Bad Request

... and closes the socket. That, naturally, makes the exporter quite
unhappy and totally unable to collect metrics.

By using single quotes, we work around the quoting issue and correctly
pass the right URL down to the exporter, at least in Debian.

fix quoting in apache exporter

puppet/archive: allow 5.x

Support for IPMI exporter

puppetlabs/stdlib: Allow 7.x

release 11.1.0