Hi,
On 09 Apr 2016, at 13:58, Toussaint OTTAVI
<t.ott...@bc-109.com<mailto:t.ott...@bc-109.com>> wrote:
Hi,
I'm new to this ML. I'm planning to migrate from Nagios, and I'm evaluating
Icinga2.
I read a lot of things about the new sytax of the configuration files, and all
the advices telling to re-write configuration files from scratch.
Yep. That’s our experience from now 2 years of community and customer support.
And I am doing quite a lot of support, as others say.
But... that clearly won't be possible on our production environment ! We have
hundreds of hosts, and thousands of services. Re-writing all the config files
by hand, just to get the same thing as before, would involve several days
(weeks ?) of work. I don't have that time.
You haven’t started yet, so you can’t estimate it anyways. Give it a try once
you’re learned the new syntax and do a small prototype first.
Having the ability to import, let's say, 80% of the actual config (even it is
not optimized at all), would be the minimum. Without that, Icinga may be the
best software in the world, I can't afford spending too much time re-writing
existing files with another syntax.
We discussed writing a config parser for the Icinga 1.x language, just in
Icinga 2. That was iirc in late 2012 or somewhere in 2013. We decided against
it. Then we would have to maintain two configuration languages and users will
never switch to a new format. The one were a lot of effort has been running
into allowing to easily deploy thousands of services with some simple apply
rules.
You will see the old world partially, as there’s status.dat or DB IDO or the
command pipe. In the end you don’t care much when looking into the Icinga Web 2
frontend. One thing which could be interesting as well is the REST API which
allows your to create objects at runtime without doing a reload.
About the "migration script", I didn't really understand what's the currest
status : Is it still a "standalone" tool ? Is it integrated in the icingacli (I
didn't find it) ? Is there any documentation (I didn't ever find ow to specify
the source path for old files) ? Is it still supported, or is it considered as
"deprecated" and "unuseful” ?
The answer is simple - everyone thought a migration script will solve the pain
of rewriting the configs. So we created one. Turns out that your config objects
look horrible and you are not able to maintain such in production.
Even harder - doing a migration automatically will hide several cool new
features from you, and later on you will find yourself needing to learn about
the new stuff in a short while. Especially when you ask for support and someone
sees your “vars.ARG1” custom attributes. That works but is far from elegant in
production.
I’m the author of that script which partially uses code for parsing the old
config done by Tom. It will never get integrated into icingacli, bugs won’t be
fixed and it is now deprecated. Will be removed soon enough allowing anyone to
copy the code if they want to.
The future in terms of configuration tools is the Icinga Director, which I have
been eagerly waiting for. If you have some sort of CMDB or $datastorage you can
import your monitoring data from, look into that. Better than any migration
script.
I understand all what has been said about the advantages of the new file
structure. But without a decent migration tool, I just can't afford spending so
much time in rewriting my existing Nagios files by hand.
Instead of fearing the time it would take, you should do an inventory at first
glance.
Find out what’s running currently, find similarities and identify your plugins,
check commands, and checkable objects. Further, dive into the notification and
dependency world. Get to know your contacts and parents.
There is no unique guidance in doing such a migration, as each Nagios/Icinga1
system has grown over time to something special in your very own environment
and daily usage.
I guess you are also using one of the many “object tricks”, e.g. assigning
services to a hostgroup where hosts are members of. They inherit the service
relation then. Cool stuff, can be done with Icinga 2’s apply rules.
But there is more to go for. Do you have multiple ping services with different
thresholds, based on the server type (or hostgroup)? Go for apply rules with
conditionals for command arguments (custom attributes).
apply Service “ping4” {
check_command = “ping4"
if (host.vars.server_type == “prod”) {
vars.ping_wrta = 50
} else {
vars.ping_wrta = 100
}
assign where host.vars.server_type
}
There’s probably room for improvement on the migration hints, as we learned
from community feedback and we also added new features since the initial
release 2.0.0 two years ago. At that time we did not have apply-for rules,
conditionals, functions, object accessors, and so on.
Though Icinga has a vibrant community and we as developers are active in many
channels. We cannot do your migration, but help you with guidance on specific
examples. The faster you learn from the community’s advice, the sooner your
migration is finished.
Kind regards,
Michael
Thank you in advance for your help and advices.
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org<mailto:icinga-users@lists.icinga.org>
https://lists.icinga.org/mailman/listinfo/icinga-users
--
Michael Friedrich, DI (FH)
Senior Developer
NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
Tel: +49 911 92885-0 | Fax: +49 911 92885-77
CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
http://www.netways.de | michael.friedr...@netways.de
** OSDC 2016 - April - netways.de/osdc **
** OSBConf 2016 - September - osbconf.org **
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
