process-check-result : check_source not working

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi Guys,


    I'm currently using the rest-api to pass check results to passive checks. So far everything works - except for the check_source :


    Code
    1. /usr/bin/curl -k -s -u root:XXX -H 'Accept: application/json' -X POST 'https://icinnga.domain.tld:5665/v1/actions/process-check-result?service=HOST!SERVICE' -d '{ "exit_status": "2", "plugin_output": "foo", "check_source": "SATELLITE" }'
    2. + python -m json.tool
    3. {
    4. "results": [
    5. {
    6. "code": 200.0,
    7. "status": "Successfully processed check result for object 'HOST!SERVICE'."
    8. }
    9. ]
    10. }


    The check_source is simply not overwritten .. instead the icinga-master is set as the check_source ..


    I followed the documentation and couldnt find any problems.. do you maybe have any ideas on this issue?


    Thank you in advance!

  • Im running icinga2 in version r2.6.3-1 on a Ubuntu 16.04.3 LTS


    Unfortunately i can't put out any details on the exact FQDNs used.


    In manual state '0' (ok) the check got the correct check_source : <satellite>.


    As soon as i sent the curl request from the satellite to the master (see curl request in the first post), the check goes in critical state (2) which is wanted.

    The check_source however changes to <icinga-master> instead of the <satellite> which is in the curl request set.



    The debug-log on the icinga-master doesn't show any noticeable when receiving the curl-request.


    Code
    1. [2017-11-16 10:09:32 +0100] debug/HttpRequest: line: POST /v1/actions/process-check-result?service=HOST!SERVICE HTTP/1.1, tokens: 3
    2. [2017-11-16 10:09:32 +0100] information/HttpServerConnection: Request: POST /v1/actions/process-check-result?service=HOST%21SERVICE (from [192.168.62.99]:35408, user: root)
    3. [2017-11-16 10:09:32 +0100] debug/DbEvents: add log entry history for 'HOST!SERVICE'
    4. [2017-11-16 10:09:32 +0100] debug/DbEvents: add checkable check history for 'HOST!SERVICE'
    5. [2017-11-16 10:09:32 +0100] debug/DbEvents: add state change history for 'HOST!SERVICE'
    6. [2017-11-16 10:09:32 +0100] notice/Checkable: State Change: Checkable HOST!SERVICE soft state change from OK to CRITICAL detected.


    The configuration of the service :



    Strange to say 'check_source' isn't set at all :


    Code
    1. root@master:~# icinga2 object list | grep check_source
    2. root@master:~# 
  • What if you target the API call against the satellite, will the check_source reflect that at the master, then ?

  • Can confirm observed behaviour at icinga version: r2.7.2-1:

    check_source will not reflect the value given in the API call - neither in icingaweb2 nor in API queries.

    In icingaweb2, it seems to keep the last value. For the API, it reflects the master.

  • What if you target the API call against the satellite, will the check_source reflect that at the master, then ?

    I just ran the curl query (from 1st post) against the satellite instead the master and the icingaweb2-gui reflected the correct check_source.


    However, I haven't found the time to test check the check_source-value via API call yet.


    But it doesn't seem to get the value from the variable via API. I left out the variable in the APi call and check_source was set accordingly. Probably due to the fact that I entered it locally on the host via API.


    On the other hand, I used another host than the host on which I call the API locally in the variable check_source. The value is not taken into account. It is simply always the host on which APi_Call is received.


    I hope you understand what I mean.

  • Sorry for misusing this thread. But because i got another problem with this exact configuration I thought it's easier to post it here :


    As said before i'm using the http api to post a passive check result. In the logs i can see that the state changes from OK to CRITICAL. Which is absoletely perfect.


    Code
    1. [2017-12-28 10:37:46 +0100] debug/HttpRequest: line: POST /v1/actions/process-check-result?service=host.domain.tld!TrapInterfaceDown_ge-0/0/3 HTTP/1.1, tokens: 3
    2. [2017-12-28 10:37:46 +0100] debug/DbEvents: add log entry history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    3. [2017-12-28 10:37:46 +0100] debug/DbEvents: add checkable check history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    4. [2017-12-28 10:37:46 +0100] debug/DbEvents: add state change history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    5. [2017-12-28 10:37:46 +0100] notice/Checkable: State Change: Checkable host.domain.tld!TrapInterfaceDown_ge-0/0/3 soft state change from OK to CRITICAL detected.
    6. [2017-12-28 10:37:46 +0100] debug/HttpRequest: line: POST /v1/actions/process-check-result?service=host.domain.tld!TrapInterfaceDown_ge-0/0/3 HTTP/1.1, tokens: 3
    7. [2017-12-28 10:37:46 +0100] debug/DbEvents: add log entry history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    8. [2017-12-28 10:37:46 +0100] debug/DbEvents: add checkable check history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    9. [2017-12-28 10:37:46 +0100] debug/DbEvents: add state change history for 'host.domain.tld!TrapInterfaceDown_ge-0/0/3'
    10. [2017-12-28 10:37:46 +0100] notice/Checkable: State Change: Checkable host.domain.tld!TrapInterfaceDown_ge-0/0/3 soft state change from OK to CRITICAL detected.



    But the icinga-GUI instead shows just a soft state "1/3". It seems also no notification is generated


    Do you have any ideas on this?


    Thank you in advance!


    Is it maybe connected to the check-result-problem i still have, too?

  • But the icinga-GUI instead shows just a soft state "1/3". It seems also no notification is generated


    Do you have any ideas on this?

    Thats absolutly ok if you have set "max_check_attempts" to 3 (which is the default). If you want to have a notification on the first state change, youhave to set this to 1 in your service. Otherwise the service needs to be 3 times in critical state before you get a notification.


    Regards,

    Carsten