Zum Wochenende möchte ich euch meine fünf “most used” API-Aufrufe in einem Blogpost verewigen:
1) Testen des Logins
Bevor ihr jetzt alle lacht weil diese Zeile in der Doku sehr gut zu finden ist, ja, ich habe die dort raus kopiert. Warum? Weil sie wichtig ist! Egal ob ihr nur ganz einfach den Icinga Director installiert oder komplexe Automatismen bauen möchtest, viele (ja, seeeeeehr viele!) scheitern schon an der sehr einfachen Grundeinrichtung der API. Deshalb: Bitte vor Verwendung testen!
/usr/bin/curl -k -s -u 'root:icinga' https://localhost:5665/v1
2) Status der Endpoints
Ein sehr beliebter Aufruf beim Betrieb von Clustern bzw. Endpoints
/usr/bin/curl -k -s -u root:icinga 'https://localhost:5665/v1/status/ApiListener' | jq
3) Anzeige der Service-Check result Details
Ihr kennt das sicher. Euer neu eingerichteter Service check macht nicht das was er soll. Ihr habt mühsam das Command zusammen gebaut und irgendetwas ist in der Definition schief gelaufen. Im Output seht ihr beim Attribut “command” exakt auf welche Weise Icinga 2 das Command zusammen baut und ausführt 😉
/usr/bin/curl -k -s -u root:icinga 'https://localhost:5665/v1/objects/services?service=test-host-01!test-service-01&attrs=name&attrs=last_check_result'|jq
4) Filtern nach Customvars
/usr/bin/curl -k -s -u 'root:icinga' -H 'X-HTTP-Method-Override: GET' -X POST 'https://localhost:5665/v1/objects/hosts' -d '{ "filter": "host.vars.os == os", "filter_vars": { "os": "Linux" } }' | jq
5) Anzeige aller Services die unhandled sind und weder in Downtime, noch acknowledged sind
/usr/bin/curl -k -s -u 'root:icinga' -H 'X-HTTP-Method-Override: GET' -X POST 'https://127.0.0.1:5665/v1/objects/services' -d '{ "attrs": [ "__name", "state", "downtime_depth", "acknowledgement" ], "filter": "service.state != ServiceOK && service.downtime_depth == 0.0 && service.acknowledgement == 0.0" }''' | jq
