Migrating from Nagios to Icinga2

Question

I need to migrate Nagios instance which has large number of nodes and services being monitored to Icinga2. I came across following documentation: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#migration

It doesn't have mentioned if there's automated way to translate all configuration of Nagios to Icinga2 configuration format. It says how to do manually. Has anyone migrated Nagios to Icinga2 with auto configuration conversion. Or any suggestion to do so in less painful way.

Thanks

Answer 1

If you are not going for finding similarities or patterns, it is also a good time for evaluating different methods for configuration. And start over.

I've seen many many Nagios/Icinga1 installations which have grown over time, and instead of "fixing" the problems, you'll just copy e.g. an existing checkcommand, give it a new name, and use that one. Or die with a hell of object tricks no-one has ever written documentation for. Sometimes such configs also "work" because of bugs in the core. Some have been fixed in Icinga 1.x but I do know some in Nagios Core which are still pretty much annoying when building configuration.

Turns out, if you take pen, paper and a drawing board for your current environment, you'll learn about existing bottlenecks, or new methods of firing your checks. Example: Don't care about load and swap on your VM? Then don't add checks for your monitoring and alerting then.

Already have some sort of config management stack and automated environements using Puppet, Ansible, Chef, Salt? Go for a native module and let it generate the configs based on your client facts.

Prefer to create objects in an automated fashion? Take the Icinga 2 REST API and create objects at runtime without a restart. Want to sync those objects to satellite nodes? Have the zone attribute set. Works.

If you happen to have a CMDB, NDO database, PuppetDB/Foreman, etc. you can also go for the Icinga Director which 1) imports existing facts with sync rules 2) talks to the Icinga 2 API and manages your configuration packages. Bonus: You'll get a configuration UI for Icinga 2 as well.

There are many possibilities as you see, and people love to still have them.

In your use case I would go for learning the new language with some simple examples. Take your company's webserver and let it monitor by Icinga 2.

Once you've gained success look for alternatives. Or even better methods for just generating config objects.

apply rules and apply-for rules defined just once. For services, notifications, dependencies. Using conditions (if then else) for assigning different thresholds based on host custom attributes.

Use group assignments similar to the assign where expressions you know from the apply rules. That way you can e.g. match on your user's email attribute, and create a usergroup. Use that in your notification apply rules.

Add/remove a host. It will get services, notifications, dependencies generated from the apply rules.

Add/remove a user. He/She will get notified (if the email matches). If the user is removed, no more notifications. (and of course - no need to edit any host/service or contactgroup members)

Well, I could talk all day long about it. Maybe you'll get the chance to join us for an Icinga Camp (look at https://www.icinga.org for announcements) :-)

Answer 2

There were some config converters, but i had back luck with them.

I personally would not do it. Reasonably fast way is to notice patterns in your config and use icinga2's programatic rules to minimize the amount of work necessary. The hard part are those single services, that do not fall under those generic rules. You still do way less typing than in nagios.

If necessary, use scripts to quickly template repetetive boilerplate code of config files, which is something i did.

The end result is that you end with much more compact config that does the same. There are various techniques to make icinga2's functions do the majority of the heavy lifting for you.

Most time saving thing was using Thruk UI with nagios, over livestatus. It offers a way to view complete command invocation for each check, with all args expanded, and you can export any custom view into csv file for processing.