We at Icinga / NETWAYS (yes, that’s the order) held an internal event recently. It’s name was Knowledge Days and I got to to talk about how I review code. Now, I will share my knowledge with you! Though, this is specifically how I personally perform reviews. This is by no means the definitive way of doing it! Find your own, I can only share my experience. So without further ado…

You want to monitor your infrastructure? Monitoring is essential to ensure system stability, security and optimal performance. Without proper monitoring, small issues can quickly escalate into major problems and affect productivity and service availability. While there is no fixed checklist for infrastructure monitoring and it depends on your setup, there are some key areas that are worth considering when building your own monitoring strategy that fits the needs of your own environment.

In a previous article, Julian provided a comprehensive overview of the characteristics and functionality of Incidents in Icinga Notifications. In today’s blog, I will explain the concept of Incident muting and its underlying mechanisms.

Automating the monitoring process for a huge amount of servers, virtual machines, applications, services, private and public clouds is a main driver for users when they decide to use Icinga. In fact, monitoring large environments is not a new demand for us at all. We experienced this challenge in tandem with many corporations for many years.

As many of you have already seen in our previous blog posts and our early beta release, we’re working on a new, independent notification module. Right now, we only offer three ready-made channels for sending notifications. Today, I want to show you how you can create your own channel and add it to the Icinga Notifications module. In this blog post, I’ll show you how to build a bridge to Telegram and send new notifications to a group chat.

We are excited to announce the release of Icinga for Kubernetes v0.2.0! This update brings a host of new features and improvements that enhance our monitoring solution for Kubernetes. It makes it easier than ever to analyze problems and understand complex Kubernetes hierarchies.

In today’s fast-paced, digitally-driven business world, cloud computing has become the foundation of scalable and flexible IT infrastructure. As organizations transition to the cloud to gain agility, scalability, and cost savings, it becomes crucial to monitor cloud environments rigorously. This ensures performance, security, and reliability. That’s why having a good cloud monitoring system, like Icinga, is critical for cloud operations.

Following the Icinga Notifications beta announcement, we already had a more general post on how to get started and one going into the details of schedules. This week’s blog post is a follow up in this series and will describe incidents, escalations, and event rules in Icinga Notifications in more detail. In case you haven’t seen the first two referenced blog posts, you might want to have a look at them first, otherwise, you could miss out on the big picture.

From time to time we want to bring not so widely known features of Icinga into spotlight. In this effort it’s a not so obvious feature, that was available in the monitoring module of Icinga Web 2 at some point already. It has also been available in Icinga DB Web since its release. We’re talking about selecting multiple list items. Our goal was to make it as obvious as possible, without wasting screen space for those users who are already aware of the feature.

Today we are very happy to announce the first beta release of Icinga for Windows with with version 1.13.0.0! This new release provides a huge number of improvements and changes to the Framework as well as the default Windows Plugins, which we will talk about later on.