service template _srv_disk_win with inherited disk_win_crit and disk_win_warn from command
service apply “Disk $config$”, importing _srv_disk_win and applying host.vars.disks:
apply Service for (config in host.vars.disks) {
name = "Disk " + config
import “srv_disk_win"
assign where match("win*”, host.vars.os)
vars.disk_win_path = config
import DirectorOverrideTemplate
}
a host service override for a specific host
object Host “myhostname” {
import “_host_generic”
import “_os_win-srv-2008r2”
import “_net_internal-lan”
display_name = “My Server”
address = “1.2.3.4.”
check_command = “hostalive”
vars["_override_servicevars"] += {
“Disk $config$” = {
disk_win_crit = “5%”
disk_win_warn = “10%”
}
}
vars.disks = [ “C:\”, “D:\” ]
}
However, the servicevars override is not used in the check…the service is warning disk c: at 15% free.
Inspecting the service shows only “vars { disk_win_path: “C:\” }”
I found a bug @Github but which was fixed in Mid-2018.
This is using an apply for rule which looks into host.vars.disks and iterates over the array elements. The overriding import of the template doesn’t look good in the host object, especially the $config$ string will never match nor will the template override be aware of this.
Yet, I am not sure if apply for loops fully support such service overrides. At least the name expansion to “Disk C:” is missing in order to override the specific variables.
Which steps were taken in the web interface to achieve exactly this situation, best with screenshots? Maybe we can reproduce the question with you.
Hi @dnsmichi
thanks for your reply…
I did some screenshots, I hope I catched everything to gather the config path. But due to community limits I have to split it up…
Btw: I am a little bit lost in the middle of using “service-apply rules” which makes it harder to have different defaults (e.g. different thresholds) or “service-sets” where I can not iterate through host.vars…:-/
Any news here?
I sill have the same problem with director 1.8.0. Overrides are stored for the host but not for the applied services. The services still use the default values.
The problem is not the applied service but the “apply for”.
There is a issue for this, but without any recent updates and it has been moved from milestone to milestone over the years.
Overrides for “normal” applied services (coming from a single apply rule or a service set) work without problems
Director was never intended to offer more sophisticated features of Icinga. It’s focused on automatic syncs and for easy delegation to users who don’t know much about how Icinga 2 works.
Director not having more complicated features implemented is on purpose. (Personally spoken) unfortunately there were some of the more complicated features implemented so we have now a mix of the easy to use GUI with some of the more powerful features. It was never intended to be a “GUI for Icinga” as far as I know.
If you want things like apply for, use the DSL. Director is for easy to use and easy to understand features that require more typing and less knowledge.
@twidhalm well thats a pitty, but the users have to respect the decision of the project.
Nevertheless the project should think about the following
“market demand” why not delivering a feature which the “market” / “here users” ask for
communication: it is called “icingaweb2” what else should be expected than a web interface? Especially if the project’s pages state: “A lightweight and extensible web interface to keep an eye on your environment. Analyse problems and act on them.”
If automation is the purpose: why offering the config parts at all? And why not calling it icingaautomate
I also dont see why for recurring configurations users should use config file editing and for automation setup (less recurring) there should be a web interface…
Sorry, but from product management perspective: doesnt make sense
So IMHO a decision thats a pity as this kind is missing rrally and the foundations are there.
Of course “Icinga Web 2” is a web interface for Icinga 2. For viewing and making minor changes like enableing or disabling notifications temporarly. What I meant is “Icinga Director is not a management GUI for Icinga that’s a full replacement for writing code in DSL”. Yes, there are many installations that only rely on Director to manage configuration but that includes missing out on many options you have when using DSL. If you prefer the easy way </yoda voice> where you do a lot of configuration manually, that’s totally fine. But if you want to make use of all the power for easy and elegant configuration Icinga 2 has to offer, Director is the wrong tool.
Director is great for automation. And it’s great for delegation. Say, you have a cople Icinga admins who really know the ins and outs of Icinga 2 and it’s configuration. They build a set of easy to use templates and offer other admins (usually Windows mouse-herders) with an easy to use interface. “Put the name of the host here, the IP address there and chose from the list of host types (referring to templates). The rest will be done automatically”. That’s where Director is big and shiny.
Why not build a tool like that? The answer might be a bit religiously biased but you can’t build a GUI that’s as powerful as a configuration language. The only option would be to have big text fields where you enter Icinga DSL anyway. Everything else might be just too complex to build as a GUI. And even if it were possible - it’s always a matter of resources.
And for your second point: Icinga Director offers automation that’s not available without Director at all. So it’s not about building a GUI for something you do only on rare occasions. Synchronizing config items from external sources is a feature you only get from Director.
Director combines two parts in one tool: Sync from external sources (not available without Director but can be done by creating your own solution) and delegation (it’s basically doing the same as changing configuration files but in a waaaaay easier way)
Just following up on this thread because I still can’t get the hang of with it these apply rules and property overrides. This was a showstopper back then when we first had a look at the director, the same issue seems to be there still. We currently doing the DSL way on the CLI which works totally fine but because of growing, more people without linux knowledge need to have access to the monitoring and make changes.
Can anyone help me out how I can transform our current config into the director?
apply Service for (win_service => config in host.vars.win_service) {
import "default-service"
check_command = "service-windows"
command_endpoint = host.vars.remote_client
vars += config
display_name = win_service
assign where host.vars.remote_client
}
This is the simple apply for service we are running, on the host side we define the services like this:
So I need one service template to define all my services and custom thresholds. I saw the example in the docs but this doesn’t allow me to override e.g “service_win_service”
Is it really the intention to create one service for each service, disk or process i want to monitor?
Hi Thomas,
are you intending to say that such “override”-features for an apply-for service is possible in the DSL? As far as I could test it in the DSL, I could not replicate the expected behavior as in OP’s first post. I could upload the small config I created for my test if you wish.
Or is the “override”-feature for an apply-for service simply not implemented in the DSL yet?
