The Icinga 2 configuration DSL is different to the old 1.x format. The differences are explained in the documentation which also show that a scripted 1:1 conversion is not possible.
With using apply rules and more goodies from the DSL, you can render the configuration more readable and make it easier to maintain.
Decide on the method
In addition to configuration file editing you can use tools like
- Icinga Director
- Automation Tools: Puppet modules, Ansible playbooks, Chef cookbooks
- Integrations into other tools using Icinga 2’s REST API
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.
It’s also possible to use an Icinga 1.x IDO database with SQL queries and extract e.g. the hosts, their address attribute and apply pre-defined service sets on top. You can see an example in this OSMC presentation.
Depending on your infrastructure management, you may already have Puppet, Ansible, Chef, Saltstack, etc.
There are existing modules which help define these resources, so you don’t need to reinvent the wheel by yourself.