Skip to content
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

Merged
merged 3 commits into from Jul 15, 2019

Conversation

geektophe
Copy link
Collaborator

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
}

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
    }
@coveralls
Copy link

coveralls commented Sep 4, 2017

Coverage Status

Coverage increased (+0.01%) to 27.736% when pulling e78e8d9 on geektophe:enh_maintenance_checks into 0dfa784 on naparuba:master.

@naparuba
Copy link
Contributor

naparuba commented Sep 4, 2017

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 👍

@olivierHa
Copy link
Collaborator

Nice feature !
@naparuba ok for merge on your side ?

@coveralls
Copy link

coveralls commented Nov 10, 2017

Coverage Status

Coverage increased (+0.01%) to 27.737% when pulling c0c7cb2 on geektophe:enh_maintenance_checks into c64f2e4 on naparuba:master.

@geektophe
Copy link
Collaborator Author

Any news, is it OK for merging ?

@geektophe
Copy link
Collaborator Author

Still no news ?

@geektophe
Copy link
Collaborator Author

@naparuba did you have time to have a look at this PR ?

@geektophe
Copy link
Collaborator Author

@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.

@naparuba
Copy link
Contributor

Very thanks for this patch, it's a very smart idea to export maintenance like this :)

@naparuba naparuba merged commit 546448a into shinken-solutions:master Jul 15, 2019
@geektophe geektophe deleted the enh_maintenance_checks branch July 18, 2019 12:58
mohierf pushed a commit to mohierf/shinken that referenced this pull request Dec 3, 2019
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants