Results 1 to 9 of 9

Thread: Passive checks logging

  1. #1
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Passive checks logging

    Hey everyone,

    We have a nice Shinken system running that does both active and passive checks. All our passive checks are basically SNMP Traps sent to shinken with submit_check_result (via snmptt). So far so good, we get our alarms in thruk and it makes us very happy... except for one thing: we don't get any "PASSIVE CHECK SERVICE" in nagios.log. We do manage to get some "EXTERNAL COMMAND" log lines if I set log_level to INFO, but this also generates a lot of unuseful logs. I did set log_passive_checks=1 in nagios.cfg, but according to docs it is meant to be the default and even if explicitly enabled it doesn't change anything.

    Does anyone have a clue what might be happening or what other info I should post to get some help on this ?

    Thanks,
    Marc.
    Marc-Olivier Barre.

  2. #2
    Shinken project leader
    Join Date
    May 2011
    Location
    Bordeaux (France)
    Posts
    2,130

    Re: Passive checks logging

    Do you have theses lines with INFO level or not?
    No direct support by personal message. Please open a thread so everyone can see the solution

  3. #3
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Re: Passive checks logging

    Nope, not even when I enable INFO level. I tried debugging the broker, but I couldn't see much (also, not sure what to look for). Maybe the debug log could show me which log classes are really active ?
    Marc-Olivier Barre.

  4. #4
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Re: Passive checks logging

    I'm burning my brains out on this one. I just can't figure out what is wrong.

    Nap ? Would you have a clue what could happen ? Any ideas of things I could look at ?
    Marc-Olivier Barre.

  5. #5
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Re: Passive checks logging

    Hi,

    I finally found what was wrong. It wasn't just the passive checks. Something we hadn't noticed until yesterday is that the passive check where all coming from 2 of the sub-realms. It was actually the sub-realms who where not being logged by the broker. Strange thing, the graphite broker module was sending data for those machines all along...

    The issue was a typo in shinken-specific.cfg that was silently accepted. It's not the first time I see an issue with subrealms and errors in shinken-specific.cfg. It might be worth looking into adding some form of parsing there so that at least the corresponding module can complain.

    The big issue here was that we had no errors, and the broker was still working ok for other things in this realm. Only alert logging in simple-log and livestatus was broken.

    If you need anymore info, feel free to ask.
    Marc-Olivier Barre.

  6. #6
    Shinken project leader
    Join Date
    May 2011
    Location
    Bordeaux (France)
    Posts
    2,130

    Re: Passive checks logging

    What was the typo, did it make an invalid situation for the broker? (like no modules or things like that?).

    "what ever" property name is by design, to allow modules to use the name they want in objects, we can't to a "break" on unknown property name.
    No direct support by personal message. Please open a thread so everyone can see the solution

  7. #7
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Re: Passive checks logging

    My schedulers where all defined as follow:

    Code:
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 10.129.31.150
     scheduler_name scheduler-claranet
     max_check_attempts 3
     port 7768
     realm Claranet
    }
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 192.168.10.113
     scheduler_name scheduler-frankfurt
     max_check_attempts 3
     port 7768
     realm Frankfurt
    }
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 192.168.20.113
     scheduler_name scheduler-washington
     max_check_attempts 3
     port 7768
     realm Washington
    }
    Notice the ',' right before the 'PickleRetention' ? Very perverse, hard to see and not related to a module option. It is basic syntax checking in my opinion. So even if the parser does not complain about unknown keywords, syntax checking should be done.

    What do you think ?
    Marc-Olivier Barre.

  8. #8
    Junior Member
    Join Date
    Sep 2012
    Location
    France
    Posts
    9

    Re: Passive checks logging

    Wait, I got that wrong. The arbiter also had the typo. The weird thing is that logging was working just fine for the Claranet realm. Only Washington and Frankfurt were behaving strangely.

    Code:
    define arbiter {
     arbiter_name Arbiter-Master
     modules ,PickleRetentionArbiter
     spare 0
     address 10.129.31.150
     port 7770
     realm All
    }
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 10.129.31.150
     scheduler_name scheduler-claranet
     max_check_attempts 3
     port 7768
     realm Claranet
    }
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 192.168.10.113
     scheduler_name scheduler-frankfurt
     max_check_attempts 3
     port 7768
     realm Frankfurt
    }
    define scheduler {
     data_timeout 120
     check_interval 60
     weight 1
     skip_initial_broks 0
     modules ,PickleRetention
     spare 0
     timeout 3
     address 192.168.20.113
     scheduler_name scheduler-washington
     max_check_attempts 3
     port 7768
     realm Washington
    }
    Marc-Olivier Barre.

  9. #9
    Shinken project leader
    Join Date
    May 2011
    Location
    Bordeaux (France)
    Posts
    2,130

    Re: Passive checks logging

    A void object should not be a problem, but maybe the scheduler got such a problem for module linking. can you open a ticket about it on the shinken github? Thanks
    No direct support by personal message. Please open a thread so everyone can see the solution

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •