Migration from Nagios...icinga or icinga2?


#1

Hello all,

I am really new to this whole monitoring world.
I’m currently looking into migrating a Nagios environment to Icinga. I read somewhere that migrating to icinga 1 is fairly easy and we would be able to use the same config files however migrating to Icinga2 means starting over…?

We have around 1100 servers and not a lot of time so should we simply do Icinga 1 for now?

Thank you very much !


#2

Which Nagios version?

There are a few differences at several locations but the migration should be quite easy (from Nagios 3.x to Icinga 1.x). AFAIK there is no more development for Icinga 1 so using that version has only a very limited future.


(Kevin Honka) #3

depending on your setup it is quite easy to migrate to either icinga 1 or 2. If you really do not have much time, it would be wise to hire an expert that can support you through the migration.


(Carsten Köbke) #4

You can use the NDO DB or even the status file (converted to csv) as an import source for director for the most objects. Migrating is quite easy and can be done if planed well in a short time


#5

Icinga1 is dead! Let it finally die peacefully: http://www.linux-magazin.de/news/supportende-fuer-icinga-1-2018/
I am sure there will be still companies support there own solution of icinga1. But to be honest, use Icinga2.
There are many(!) advantages over Icinga1. You have to learn the DSL (or the work with the Icinga Director). But meanwhile, the Icinga2 docs are very detailed. You have the chance to completely build up a new, very performant monitoring solution. You will love the apply rules in icinga2, trust me.


#6

Thank you all for your prompt responses!

We are using Nagios 3.5.1.

I did setup a Icinga2 environment already. Works well! My next concern was migrating everything from our current Nagios environment.

Carsten : I saw some people talking about that Director thing. I can use that to migrate?

I honestly don’t know where to start. What exactly do I need to migrate (in terms of files) ?


(Michael Friedrich) #7

I would do an inventory of your monitoring config first and consolidate what’s currently in there.

  • Hosts and their IP addresses
  • Services and their grouping
  • Used commands and plugins
  • Assigned contacts and contact groups
  • Distinct overview with existing agents or agent-less service checks

Once you’ll have such a table, you can start to define Icinga 2 specific objects.

  • Hosts with additional details
  • Service apply rules
  • CheckCommands, which do not exist in the ITL yet
  • Notification apply rules sourced from the previously collect contact assignments
  • Additional agent and distributed environments

Keep it simple, and don’t try to solve everything at once. Iterate from one host to a second and third host for instance. Once you feel familiar and see the first results, even with agents, stop and consider a possible way: Manual config file editing (just like before), UI click workflows, or generated from possible automation tools like Puppet.


#8

Thank you Michael.

I suppose I’ll be able to create “templates” of services I want to monitor and then assign the different templates to specific hosts?

Would you say an environment of 1100 hosts is a lot of work?


#9

That depends on the number of different definitions, not the number of objects. For example, if you have different thresholds for every disk check there is more work than if you have thresholds for every group of hosts.


#10

When I started to use Icinga2 over 3 years ago, I made a complete migration from OpsView (Nagios Core inside) to Icinga2.
It will take time and at the beginning it will be pain here and there. But once you got it, you will love it. And a good monitoring needs a little bit love. It is never finished (imho).
There is one huge difference between nagios and icinga2.
In Nagios you assigned hosts to a service. In Icinga2 you assign services via apply rules to hosts.
One simple example:
Lets say you have 3 templates:

  • generic-host
  • generic-windows
  • generic-linux

in your generic-host, you define variables, which are basically valid for every kind of host, e.g. check_interval, retry_interval, notification contacts etc. you can overwrite this variables later in the specific host object definition, if you need.
based on this template, you have a generic-linux and generic windows template. both templates got “import generic-host” so you always have your “basic template” imported. Here you can define default variables, which will set the thresholds of your basic checks, e.g. load, mem, disk etc. Here you give a os variable e.g. “var.os = linux” / “var.os = windows”
In your Service definitions, you use this variable to assign the Service:
object Service “load” {
…blablabla check_command = …
assign where host.vars.os == “linux”
}
object Service “load” {
…blablabla check_command = …
assign where host.vars.os == “windows”
}
(yep, the same service name for both is absolutely ok, as long as it is unique for the os)
assumed, your default thresholds are ok for the most of your clients, you later just need 3 lines of code for a new host:
object Host “mylinuxserver” {
import “generic-linux”
address = 1.2.3.4
}
and that’s it. With this 3 lines this server is added to Icinga2 and gets every Service, which has the " assign where host.vars.os == “linux”
" assign rule.
Before you start, decide how you want to check your clients! Either by NRPE/NSclient++, SSH/WMI, Icinga “Client”, SNMP etc. I used NRPE/NSclient++ at the beginning. Maybe you should do this too, as the agents should be already installed at the clients from the old Nagios (if it was used there)

A few more tipps, as I already did, what you are doing right now:

  • RTFM. Serious, before you start, read the complete Icinga2 docs. Don’t read and do and read an do. Read it completely, then start, then read again. You will always go back to the docs for e.g. ITL variables.
  • use the ITL! I saw very often now, that people don’t know, what the ITL is or don’t know, how to use it. Instead, they start hacking their own Command Objects for their services (@dnsmichi maybe this part should be made clearer in the docs?). you don’t have to create Command Objects for every service. the most common plugins are already there.
  • you will have a huge learning curve. The Icinga DSL is a beautiful way to create a super nice monitoring environment. I am personally not a fan of the Icinga Director.
  • every Nagios compatible plugin works in Icinga2. And there are many other plugins you can use (e.g. centreon-plugins)

Cheers and welcome!


#11

In chapter 2 of the documentation in the section “Configuration Overview” it says

The Icinga Template Library provides a set of common templates and CheckCommand definitions.

/** 
* The Icinga Template Library (ITL) provides a number of useful templates 
* and command definitions. 
* Common monitoring plugin command definitions are included separately. 
*/ include <itl>

#13

Hi Marcus,
Thank you very much for your response, it gave me a lot of light!

If we already use NRPE, I suppose continuing that way would mean minimal work done on the clients? Installation of the deamon and that’s it? That’s really the goal in my organization.


#14

Maybe consider using the Icinga Director.
It can’t migrate your config directly, but it has some tools to help you.

The import and sync function is able to read different sources and create configuration objects off of those.
E.g import Windows servers from AD(I use this very often, as it covers the majority of the monitored hosts in my projects) or query a SQL DB (like NDO DB).

Take a look at this talk from the Icinga Director developer, it’s in german though.


He shows some methods of imports with the Director, one being the Icinga1 IDO.

Also there is the Module fileshipper that provides more source formats for imports like CSV , JSON , YAML and XML.


#15

If I use Director, will I have something to do on the hosts? Or it’s simply connecting them at the Director level and that’s it?


#16

What hosts do you mean?

The Director is, simply spoken, a web front-end for the configuration of icinga2 objects (hosts, services, notifications and so on). It stores the configured objects in a separate database and build the config from this database, which then is used by icinga2.
What the Director needs is an API connection to the icinga2 master node to roll out the configuration.
https://icinga.com/docs/director/latest/doc/01-Introduction/


#17

By hosts I meant all the machines we have to monitor. Sorry! We have around 1100.

Is there something to do/install on them with the Director?


#18

No, you don’t have to do anything specific on the hosts you want to monitor if you are using the Director.

As said, the Director basically is just a GUI for the icinga2 config files.


#19

That’s nice! I will look into this then !
Thank you very much:)