Recently I wrote about the changes in NSClient++ 0.5.0 and its REST API capabilities. Icinga 2 bundles the NSClient++ installer and additional check commands in the “nscp-local” namespace for your convenience for a while already now.
The documentation highlights a short example for querying performance counters with the Icinga 2 client as command endpoint and local NSClient++ check plugin calls.
While testing the 0.5.0 integration I’ve also taken the steps of adding service checks for every available check command we have added so far to the Icinga 2 template library. I thought sharing this with you will hopefully generate feedback for documentation updates – how you are currently using NSClient++ in combination with the Icinga 2 client?
Icinga 2 can generate its own alerts when a host or service has reached a certain state (hosts: UP, DOWN, or UNREACHABLE, services: OK, WARNING, CRITICAL, or UNKNOWN). With the right configuration the monitoring software sends out emails, text or instant messages, etc. to users or user groups. (Check out our documentation to learn more about Notification objects.) As soon as you want to organise notifications for more than a few people or several teams with different on-call duties, things can become a bit uncomfortable in Icinga 2. (more…)
Today we are happy to announce version 1.0 of our Icinga Output Plugin for Logstash! It allows you to process check results, send notifications and manage downtimes by calling the Icinga API directly from Logstash. Furthermore, the Icinga output plugin for Logstash can be used in a high available manner, making sure you don’t lose any data. (more…)
Automated monitoring configuration has many facilities. Some use configuration management software such as Puppet or Chef to deploy their host and service definitions. Others use the Director to import hosts from an existing CMDB and users from Active Directory. Independent from the technique that you use, I am sure we all agree that automated monitoring configuration is a huge benefit.
Today I am pleased to tell you about a new mechanism that came up recently to automate host creation in Icinga. The Foreman is a complete lifecycle management tool for physical and virtual servers. Servers can be installed classically via PXE or by using a cloud provider like Azure or DigitalOcean. You can also easily spawn Docker containers. The Foreman integrates configuration management tools such as Puppet, Chef or Ansible to set up and configure software after the installation. The list of available plugins is endless. (more…)
A while back we’ve written about changes inside our Vagrant box demo environments – and many things happened ever since.
There are a couple of new Icinga Web 2 modules directly integrated into the Vagrant boxes (Director, Grafana, Cube, Globe). In terms of metrics and event collecting we’ve integrated Elastic Stack with Icingabeat and also InfluxDB with Grafana. We are happy to release v1.3.0 today.
Central log management has always been a topic for almost every sysadmin. In the past we used a central syslog server to collect all logs from clients and store them in plain text files. Instead of searching the logs on 10 web servers, the sysadmin had to run just a single grep command on one machine. When someone managed to hack into your server, he probably wasn’t fast or clever enough to disable the remote logging. He did what he did, but your logs were save for later analysis. In an ideal world even network hardware would send their logs to this central syslog instance. Well, in an ideal world the “syslog” format would be the same on each device. In an ideal world developers would use reasonable and standardised timestamp formats. Instead, we have to write regexes for the umpteenth time to parse this stuff. Sigh. (more…)