AdvisorAdvisor9 minutes ago, mnagel said:I 100% agree this is needed -- we have to hack around this all the time with escalation chains that have one or more empty stages, and still that does not prevent alerts from registering in the system. But this is just one case that would be trivial to solve with DS inheritance, something I have been pushing for well over four years now. The issue with creating new DSes is they are then freestanding clones, meaning each must now be maintained independently (and this is commonly pushed by support as a solution, sadly). If we could just get inheritance done (not just for DSes, but that would be the highest impact) it would be easy to make a copy that does what you want with changes only to parameters you desire while still getting the benefit of updates on the parent module and minimal maintenance requirements. It would be important that child module applies-to expressions are automatically excluded from the parent chain, too.
A related change for alerts that would not be solved by inheritance but I had also benefited from in our previous tool is threshold calculation over time. For example, I don't care if CPU is high on a Windows server for a few minutes, but I do care if it is high for an hour. I also need to know if the average is high over a period of time when the actual level may be oscillating during that period and LM would not generate any alerts otherwise). With Nagios we did this by calling back to the pnp4nagios RRD data to calculate averages, slopes, etc. This could be done in LM if using the API from within modules was supported properly, but I refuse to go there until there is library support within the module system.
Yes, creating new DS isn't an optimal/acceptable solution exactly due to that. We need to maintain each DS & if there's a new one released we would need to edit all the other ones to keep everything according...
There should just be a way of tweaking this & still maintaining the parent DS.
