Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serviceescalation assignet to servicegroups #1756

Open
Bierchermuesli opened this issue Nov 17, 2015 · 5 comments

Comments

@Bierchermuesli
Copy link

commented Nov 17, 2015

I think there is an issue with escalations which are assigned to a servicegroup

Described in in the Advanced Docs and mentioned in the shinken Forum

Base Set:

define host {
  host_name   ServerDummy
  address     localhost
  contacts    admin
  use         generic-host
}

define service {
 service_description      Service
 host_name                ServerDummy
 check_command            always_critical
 check_interval           3
 max_check_attempts       1
 retry_interval           1  
 notification_interval    1
 servicegroups            urgent
 escalations              to_boss1
}
define servicegroup{
 servicegroup_name   urgent
 alias               All critcal service
 }

This "old" fashioned Nagios escalation doesnt work - boss2 gets never informed.

define serviceescalation{
    servicegroup_name       urgent
    contact                 boss2
    first_notification      2
    last_notification       10
    notification_interval   1
}

The "new" escalation works nice (but does not fit well within my setup)

define escalation{
    escalation_name         to_boss1
    contacts                boss1         
    first_notification_time 2
    last_notification_time  10
    notification_interval   1
}

Fresh shinken 2.4.2 (pip) - Configuration migration from an (working) Nagios Setup cannot say if its new in 2.4.2...

Maybe somebody can me some advice to start troubleshooting? Is there a way to see the "compiled" running configuration which shinken use?
No Special findings in the daemon debug logs.

thanks in advance

@Bierchermuesli

This comment has been minimized.

Copy link
Author

commented Dec 7, 2015

im wondering if I am wrong or anybody can confirm this?

@geektophe

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2016

Sorry for my late answer.

In your first configuration sample, you explicitly set the escalations on the host through the escalations attribute. But if it's not defined in configuration configuration (which I think is the case because you state two different tests), it may not work.

I highly suspect that both methods are mutually exclusive (on a same host).

So I'd say that either you define the escalations attribute on the host, and the corresponding escalation objects, or you define servicegroup based escalation without the escalations attribute. Explicit being better that implicit, I won't be shocked by this behavior.

Could you try with the old fashion configuration, but remove the escalations attribute ?

@Bierchermuesli

This comment has been minimized.

Copy link
Author

commented Jan 28, 2016

Hello

Thanks for your reply.
The escalations to_boss1 attribute was just in this example here. :) Whats the best way to troubleshoot this issue?

@naparuba naparuba added the TOSORT label Apr 30, 2016

@naparuba naparuba added this to the Not prioritized milestone Apr 30, 2016

@justinpryzby

This comment has been minimized.

Copy link

commented Aug 4, 2016

I have the same problem, not able to use old "serviceescalation" with servicegroups. Reproduced with minimal changes to template config of shinken 2.0, but also affects our "production" instances running 2.4.
define service{
servicegroup g
}
define serviceescalation {
servicegroup g
contacts admin2
first_notification 1
last_notification 0
notification_interval 1
}

Is this expected to work ??

@justinpryzby

This comment has been minimized.

Copy link

commented Aug 7, 2016

It'd be really nice to know if this was expected/intended/tested to work.

I tried using servicegroup dependencies as described and found another problem.
http://shinken.readthedocs.io/en/latest/07_advanced/objecttricks.html#id7
File "/usr/local/lib/python2.7/dist-packages/shinken/objects/servicedependency.py", line 189, in explode
dep_snames = [d.strip() for d in sd.dependent_service_description.split(',')]
AttributeError: 'Servicedependency' object has no attribute 'dependent_service_description'

It seems to me that servicegroups aren't exploded, as needed at least for dependencies and escalations .. no ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.