On 03/01/18 19:31, Thomas Gelf wrote:
> Am 03.01.2018 um 19:09 schrieb Chris Boot:
>> [..] import data into Icinga2 from various sources [..] I'd like to avoid
>> avoid using Icinga Director [..]
>
> IMHO there is no better tool for tracking history than the Icinga
> Director, especially when your configuration is going to be influenced
> by a bunch of external sources. Disclaimer: I'm definitively biased ;-)
Hi Thomas,
Perhaps I'm missing something about how Director works, then. Can I use
it to simply import data into Icinga2? Or am I missing the point entirely?
One of the reasons we want to use VCS (in our case Git hosted on a
private GitLab instance) is not only for version control but also for
peer review and integration with our other processes. I use Director
myself for my personal Icinga2 instance, but it doesn't feel like a good
fit for my employer based on that experience - but I'd be happy if you
persuaded me otherwise!
>> object Host "linux.example.com" {
>> import "linux-host"
>> vars.sla = "foobar"
>> }
>>
>> object Host "ipmi.example.com" {
>> import "ipmi-host"
>>
>> var parent = get_host("linux.example.com")
>> # ^ will often be null
>> vars.sla = parent.vars.sla # <= this is what we want to do
>> }
>>
>> Is there a way of achieving the same result that might work better?
>
> Parse-time VS run-time, it's... complicated. This should do the job:
>
> globals.getSlaFromHost = function (hostname) {
> var host = get_host(hostname);
> if (host) {
> return host.vars.sla;
> } else {
> return null;
> }
> }
>
> object Host "ipmi.example.com" {
> vars.sla = {{ return globals.getSlaFromHost("linux.example.com"); }}
> }
>
> The function is optional, you can of course place all the code within
> those double brackets. Please note that this variable never really has a
> value, but carries an anonymous function. It will be evaluated at check
> time, so when using $sla$ in your CheckCommand everything should work as
> expected. But please do not expect to see this variable in the IDO,
> Icinga Web 2 to will show "sla: Object of type 'Function'".
I had considered this approach too, but one of the things we use the SLA
value for is to determine group membership and to apply notifications
only for certain SLAs, for example:
object HostGroup "foobar-servers" {
display_name = "Foobar Servers"
assign where host.vars.sla == "foobar"
}
apply Notification "foobar-service-notifications" to Service {
import "mail-service-notification"
assign where host.vars.sla == "foobar"
}
These are fictionalised examples but are an accurate representation of
what we do.
My understanding is that using a function or lambda for the SLA value
would prevent this from working because the "assign where" would be
evaluated once while the configuration is being parsed.
> Eventually one of our core developers can jump in with a better
> solution, this here is just the first one that came to my mind.
I guess my biggest issue with get_host() is that it seems
non-deterministic. It occasionally works from within a Host object, but
mostly not.
Interestingly, from Service objects it seems to work reliably every time.
Thanks,
Chris
--
Chris Boot
bo...@boo.tc
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
