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

Bierchermuesli opened this issue Nov 17, 2015 · 5 comments


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


This comment has been minimized.

Copy link

commented Dec 7, 2015

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


This comment has been minimized.

Copy link

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 ?


This comment has been minimized.

Copy link

commented Jan 28, 2016


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


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 ??


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.
File "/usr/local/lib/python2.7/dist-packages/shinken/objects/", 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
None yet
4 participants
You can’t perform that action at this time.