Highly likely. Our relationship is not the best, since they tried everything to fight against forks and thus against the community. 6 years ago this exploded with lying about the monitoring plugins project. That included some illegal actions and public shaming of community members. Nothing I’d like to dig up again, still, the Internet doesn’t forget, and neither do well known community members.
Luckily the majority of our users shares a long and friendly history with us, and we are all thriving for making Icinga better, no matter if it is called 1.x or 2.x, or just without. We are not a fork anymore.
@rsx The whole distributed monitoring and cluster thing is always forgotten, thanks. And there’s even more, ranging from packages (no more compiling) to more convenient documentation to specific modules with business processes, certificate monitoring, etc. - The Icinga Stack » 6-in-1-Stack easily explained
Besides, from the core parts, the DSL is “monitoring as code”. Ranging from the simplicity to create a ping service for all hosts …
apply Service "ping4" {
check_command = "ping4"
assign where host.address != ""
}
to advanced methods with conditionally creating notifications and generating objects from nested hashes. You can even do runtime calculations.
Besides, Icinga 2 has a real REST API, not only status but also object creation, actions, etc. Safe and secure, in contrast to the command pipe permission foo.
All in all, after thinking about this, there’s so many details added with the lovely feedback from our community making this a strong monitoring ecosystem.
And it does not end there - IcingaConf is coming soon, with more enhancements on the backend side (IcingaDB), reporting in all its glory (free, no enterprise model) and event pipelines. You’ll also learn more about technology (containers, cloud, incident handling, observability, etc.).
Cheers,
Michael
