-
-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prometheus daemon is not restarting when command-line arguments are changed #382
Comments
I think this is only an issue with systemd. puppet-prometheus/manifests/config.pp Lines 160 to 162 in 0c5e1a1
notify parameter of all file resources in config.ppThe idea is that some file resources can then notify prometheus::service_reload instead.
Using resource defaults like this is not recommended. 'Area of effect' can be confusing and cause unintentional results. See https://puppet.com/docs/puppet/5.5/lang_defaults.html#behavior As for systemd... puppet-prometheus/manifests/config.pp Line 163 in 0c5e1a1
|
Should I remove the
from |
In systemd, the service is currently not being restarted after configuration changes. See GH-382 The acceptance test in this commit reconfigures prometheus with the admin API enabled and then attempts to access it. See https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-admin-apis
The [unreliable](https://puppet.com/docs/puppet/5.5/lang_defaults.html#behavior) resource default ``` File{ notify => Class['prometheus::run_service'] } ``` is replaced by a `$notify` variable that is set on the relevant file resources *and* `systemd::unit_file`. Some care was needed to make sure the reload behaviour wasn't broken. ie If the configuration change is just a new scrape job that is collected, the service should only be reloaded, not restarted. Fixes #382
In systemd, the service is currently not being restarted after configuration changes. See voxpupuliGH-382 The acceptance test in this commit reconfigures prometheus with the admin API enabled and then attempts to access it. See https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-admin-apis
The [unreliable](https://puppet.com/docs/puppet/5.5/lang_defaults.html#behavior) resource default ``` File{ notify => Class['prometheus::run_service'] } ``` is replaced by a `$notify` variable that is set on the relevant file resources *and* `systemd::unit_file`. Some care was needed to make sure the reload behaviour wasn't broken. ie If the configuration change is just a new scrape job that is collected, the service should only be reloaded, not restarted. Fixes voxpupuli#382
In systemd, the service is currently not being restarted after configuration changes. See voxpupuliGH-382 The acceptance test in this commit reconfigures prometheus with the admin API enabled and then attempts to access it. See https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-admin-apis
The [unreliable](https://puppet.com/docs/puppet/5.5/lang_defaults.html#behavior) resource default ``` File{ notify => Class['prometheus::run_service'] } ``` is replaced by a `$notify` variable that is set on the relevant file resources *and* `systemd::unit_file`. Some care was needed to make sure the reload behaviour wasn't broken. ie If the configuration change is just a new scrape job that is collected, the service should only be reloaded, not restarted. Fixes voxpupuli#382
Adding or removing any command-line argument to Prometheus class does not trigger daemon restart.
In this case,
external_url
is a command-line argument to PrometheusThe text was updated successfully, but these errors were encountered: