How to monitor your MySQL server(s) with Icinga 2

Are you responsible for one or more MySQL servers in your company or organisation? Do you run a MySQL replication setup or multiple MySQL instances on your machine? Then you probably want to know if they are performing as well as they could do and if you’re getting the most out of your hardware. Monitoring your MySQL server(s) provides valuable information — both for avoiding and dealing with problems. If you’re looking for a free and open-source solution, then it’s time to learn our tips and tricks for monitoring MySQL with Icinga 2.

This document introduces the necessary monitoring plugins and shows some Icinga 2 configuration examples for monitoring various MySQL setups, from single servers to master/slave setups with replication, to multiple MySQL instances on a single server.

Tip: All sample listings can also apply to MariaDB and Percona Server. So, whenever we talk about MySQL, this includes the two spin-offs. (more…)

Automated Monitoring – Icinga meets Foreman

foreman logoAutomated 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…)

Process Icinga Logs with Logstash

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…)

Releasing Icingabeat

Today we are happy to announce the release of Icingabeat v1.0!icingabeat checkresults

Beats are lightweight data shippers. They are based on libbeat and written in Go. You install a Beat on your server to collect various data and forward it either to Logstash or directly to Elasticsearch. For example, there is Filebeat to read log files, Metricbeat to fetch metrics from operating systems or Packetbeat to inspect network packets. Icingabeat collects data from the Icinga API. It can open a stream to receive events and simultaneously poll the current status of Icinga 2 periodically.