In the last few weeks the NetEye development team and the Alyvix development team have been collaborating to achieve support for Time Periods in Alyvix. In this blog post, we’d like to share some interesting challenges that this feature has brought to the developers.
Disclaimer: as of the 28th of December, 2023 the Alyvix Time Period feature is still under development, so everything mentioned in the remainder of this blog post has not been released yet.
Challenges
Whoever isn’t new to NetEye is probably already familiar with the concept of Time Periods: in fact it’s present in Icinga 2, where a time period represents the range(s) of times during which an object should be monitored. Such time periods can be defined in Icinga Director and are complex objects that have a structure similar to the following:
object TimePeriod "Work Hours" {
ranges = {
"friday" = "09:00-17:00"
"monday" = "09:00-17:00"
"thursday" = "09:00-17:00"
"tuesday" = "09:00-17:00"
"wednesday" = "09:00-17:00"
}
}This time period specifies that an object should be monitored during working days, from 9AM to 5PM.
In the same way, the Alyvix time period feature that is under development needs a similar concept, which at first sight seems quite simple, but when it comes to the actual software needed to parse such definitions and understand if during any point in time a given Time Period is in effect of not, the logic is not straightforward (e.g. when taking into account time zones) and it’s very easy to introduce bugs when coding such logic.
So, it seemed that handling such time periods in Alyvix could be quite a challenge.
Wait, doesn’t NetEye already handle Time Periods?
While discussing how we could handle these Time Periods, we already had in mind that in NetEye 4 we encountered and solved this challenge.
Where? In the SLM Reports: in SLM a user can define a time period in the Icinga Director and then associate it with an SLA Type. When generating the report, slmd (our SLM backend written in Rust) parses the time period and computes the availability of the monitored objects during that time period. This means that slmd contains the logic to understand if any point in time falls under the time period, which is exactly what we’ll also need in Alyvix.
So at this point it became clear that it would have been best to also reuse the slmd logic in Alyvix. What advantages will this give us? The most evident is that this will require less implementation effort since the logic could be reused. But most importantly, having a single library serving this logic guarantees that all bugfixes and new features will be inherited by both projects. So, for example, if the NetEye team needs a new feature in the library, Alyvix will get the new feature for free, and viceversa.
Is it that simple?
From the theoretical point of view this was awesome, but is it all fun and games in practice, too? Of course not, but we only encountered a couple of obstacles (see below).
Making the library ready to be reused
The slmd Rust project already contained a timeperiod crate, but the crate was not public. So how could Alyvix get the library? For the sake of simplicity we decided to extract the library in a dedicated git project, so that Alyvix could get the library source code.
So not really a big effort except readapting slmd to get the crate from a git project instead of getting it locally.
Using the library in Alyvix
As we mentioned the timeperiod library is written in Rust. And no, Alyvix is not written in Rust, but in Python. After some investigation though, we understood that this was not an big issue, there are ways in Python to invoke functions in a Rust library. I won’t go into detail here on how to do this, since the explanation would be rather lengthy. Let’s leave the topic for a later dedicated article.
Current status
To sum up, the development of Time Periods for Alyvix is still ongoing, but we already saw that sharing the Time Period library between NetEye and Alyvix can bring many advantages. Contributions to the library were already brought over from the Alyvix development team, so the choice of having a shared library already seems to have proven correct.
As of 28th December 2023 the Time Period library is not yet public, but the plan is to make it public soon, so stay tuned!
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.
Damiano Chini
Author
