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

add problem timestamps and duration #447

Merged
merged 3 commits into from
Feb 5, 2024
Merged

Conversation

sni
Copy link
Contributor

@sni sni commented Jan 25, 2024

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.

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.

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.
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.
@sni
Copy link
Contributor Author

sni commented Jan 26, 2024

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.

@nook24
Copy link
Member

nook24 commented Feb 5, 2024

This Pull Request also changes the behavior of the following macros to be UUID v4 strings (e.g. e79dedf8-97a5-4fe5-aaf4-68a0ca7fe396) instead of simple integer counters.

  • $HOSTPROBLEMID$
  • $HOSTNOTIFICATIONID$
  • $LASTHOSTPROBLEMID$
  • $SERVICENOTIFICATIONID$

This ensures that the IDs can be used as unique identifiers

this solves an issue for the initial state change from pending to ok and
when updating naemon from a version not supporting problem durations.
@sni sni merged commit 70666aa into naemon:master Feb 5, 2024
26 checks passed
@sni
Copy link
Contributor Author

sni commented Feb 5, 2024

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
@sni sni deleted the more_problem_macros branch February 9, 2024 15:10
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.

2 participants