-
Notifications
You must be signed in to change notification settings - Fork 63
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
add problem timestamps and duration #447
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this PR makes hosts / services save the start and end timestamp of the current problem. Those values can then be used as macros, ex. in notification scripts. For this, there are several new macros available: - $HOSTPROBLEMSTART$ start timestamp of problem - $HOSTPROBLEMEND$ end timestamp of problem (or zero if problem still persists) - $HOSTPROBLEMDURATIONSEC$ duration of problem - $HOSTPROBLEMDURATION$ duration as human readable text the same macros exist for services: - $SERVICEPROBLEMSTART$ - $SERVICEPROBLEMEND$ - $SERVICEPROBLEMDURATIONSEC$ - $SERVICEPROBLEMDURATION$ While there is a currently ongoing problem, the values point to this current problem and the end timestamp is zero. Once the problem is resolved, the values can still be used and won't change until a new problem starts. This makes it possible to use the problem duration in recovery notifications which otherwise would not be possible.
sni
force-pushed
the
more_problem_macros
branch
from
January 26, 2024 10:17
e83ccd5
to
c749cab
Compare
this makes problems and notifications distinguishable over different instances. Using glibs g_uuid_string_random implemantion so it does not introduce any new dependency. Since the uuid is not used for cryptographic purposes this should be fine. Existing IDs will be converted to strings.
Adding the uuid commit here, since it overlaps a bit with the problem macros. If that's an issue, i can move it into a separate PR. |
This Pull Request also changes the behavior of the following macros to be UUID v4 strings (e.g.
This ensures that the IDs can be used as unique identifiers |
nook24
approved these changes
Feb 5, 2024
this solves an issue for the initial state change from pending to ok and when updating naemon from a version not supporting problem durations.
thanks for the review |
nook24
added a commit
to it-novum/naemon.github.io
that referenced
this pull request
Feb 5, 2024
… now UUIDv4 strings instead of integer counter values naemon/naemon-core#447 Signed-off-by: nook24 <[email protected]>
nook24
added a commit
to it-novum/naemon.github.io
that referenced
this pull request
Feb 5, 2024
naemon/naemon-core#447 Signed-off-by: nook24 <[email protected]>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this PR makes hosts / services save the start and end timestamp of the current problem. Those values can then be used as macros, ex. in notification scripts. For this, there are several new macros available:
$HOSTPROBLEMSTART$
start timestamp of problem$HOSTPROBLEMEND$
end timestamp of problem (or zero if problem still persists)$HOSTPROBLEMDURATIONSEC$
duration of problem$HOSTPROBLEMDURATION$
duration as human readable textthe same macros exist for services:
$SERVICEPROBLEMSTART$
$SERVICEPROBLEMEND$
$SERVICEPROBLEMDURATIONSEC$
$SERVICEPROBLEMDURATION$
While there is a currently ongoing problem, the values point to this current problem and the end timestamp is zero. Once the problem is resolved, the values can still be used and won't change until a new problem starts.
This makes it possible to use the problem duration in recovery notifications which otherwise would not be possible.
Since this change affects the host/service structs, the neb api version has to be increased and NEB modules have to be rebuild. Once this is accepted, i will add PRs to add those columns to livestatus and the docs on the webpage.