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
Enh: Maintenance checks #1929
Enh: Maintenance checks #1929
Conversation
This patch introduces maintenance checks, and extends the commands scheduling with *check variants*: it allows to have commands executed by pollers, but for other purpose than state check. The *maintenance check* is an extension of the *maintenance period*, where maintenance state is got from a command return code (as a of state check) rather than a fixed predefined timeperiod. This allows to dynamically get and host or service maintenance state from an arbitrary command. This command can for instance query the state in an external database or API. Example: define service { use generic-service host_name lb service_description Web frontend check_command check_http_frontend maintenance_checks_enabled 1 maintenance_check_command check_release maintenance_check_interval 1 maintenance_retry_interval 1 maintenance_check_period 24x7 ... } define command { command_name check_release command_line $PLUGINSDIR$/check_release_api }
Seems legit and useful. I'll have a look at the code to see which part it can add complexity, but even with a little complexity+ should be ok, as maintaince as commands can be a really useful feature 👍 |
Nice feature ! |
…hecks Conflicts: test/.gitignore
Any news, is it OK for merging ? |
Still no news ? |
@naparuba did you have time to have a look at this PR ? |
@naparuba @olivierHa This patch works with success on my production platform for months, now. I have a bug fix PR to push, and some lines interleave with this one. I'd really like to know If I have to publish it against the current master, or if this PR could be merged before. Ideally, I'd prefer to avoid having to re-merge changes too often... Thanks in advance. |
Very thanks for this patch, it's a very smart idea to export maintenance like this :) |
* Enh: Maintenance checks This patch introduces maintenance checks, and extends the commands scheduling with *check variants*: it allows to have commands executed by pollers, but for other purpose than state check. The *maintenance check* is an extension of the *maintenance period*, where maintenance state is got from a command return code (as a of state check) rather than a fixed predefined timeperiod. This allows to dynamically get and host or service maintenance state from an arbitrary command. This command can for instance query the state in an external database or API. Example: define service { use generic-service host_name lb service_description Web frontend check_command check_http_frontend maintenance_checks_enabled 1 maintenance_check_command check_release maintenance_check_interval 1 maintenance_retry_interval 1 maintenance_check_period 24x7 ... } define command { command_name check_release command_line $PLUGINSDIR$/check_release_api } * PEP8 compliance
This patch introduces maintenance checks, and extends the commands scheduling with check variants: it allows to have commands executed by pollers, but for other purpose than state check.
The maintenance check is an extension of the maintenance period, where maintenance state is got from a command return code (as a of state check) rather than a fixed predefined timeperiod. This allows to dynamically get and host or service maintenance state from an arbitrary command. This
command can for instance query the state in an external database or API.
Example: