The tutorial does not show the command creation/configuration step because they are using a already defined command from the ITL. Those are mostly already good to go, as they often have some default values set.
If you want to fit them to your needs I suggest the following:
Go to the (in your case) http command, switch to the fields tab and add all the fields you need for your check. You will get a drop down menu there that will give you the fields of that command under argument macros
The description what each field is for can be found in the Preview tab.
You will find that, for example, the field for -S/–ssl is not present in the drop-down list(as are some others). This is because this field is not assigned to value but to set_if, meaning it is a boolean field not a field that expects a string.
For those fields you need to create the data field with the name http_ssl and type boolean by hand and can then add it via the drop-down list in the fields tab of the command (it will be listed further down the list in alphabetical order and not under the argument macros
What I’m trying to also achieve is to use the -u option to check a URL that runs a web based email login. So check_http -H ourhost -u https://ourhost.ourdomain.edu/webmail I added it as a Service
But this is what Inspect shows: '/usr/lib64/nagios/plugins/check_http' '-H' 'ourhost' '-u' 'https://ourhost.ourdomain.edu/webmail' '-I' 'x.x.x.x' '-p' '443'
But the Executed Command has the extra arguments/options that cause this to show an error: HTTP WARNING: HTTP/1.1 400 Bad Request. Where can I find how to omit -i and -p?
yes, of the already existinghttp command in the External commands section.
I recommend you use that. There is no need to create a new command.
This is not what this parameter is for. Check check_http -h to get to know the plugin and its parameters.
I suggest you start over, delete the service template and your command. Add your required fields to the http command, then create a service template (e.g “service-template-http-generic”) using this command. Then you can create another service template (e.g “service-template-https”) and set the SSL option to true there and then apply a service from it to a host.
Does this mean I can’t combine these 2 checks into one service template, i.e., one for a full URL with the -H and -u options, and another check for --ssl or -S True and an optional port number?
So this works from CLI:
sudo -u icinga /usr/lib64/nagios/plugins/check_http -H ourhost -u https://ourdomain.edu/webmail
HTTP OK: HTTP/1.1 302 Found - 461 bytes in 0.002 second response time |time=0.001751s;;;0.000000 size=461B;;;0
I thought between Arguments and Fields, as well as making them optional, could be covered in one service template?
Interesting.
I would have run the check like check_http -H ourdomain.edu -u /webmail -S
For the director this would mean you have a host object for ourdomain.edu and add a service to this were you set http_uri to /webmail and http_ssl to yes (from the drop down after having create http_ssl as a boolean type data field)
Wow so you “paramaterize” all the elements into objects. Guess there’s more than one way to skin a cat here. This now works, where I created a service just for this host:
I generally prefer combining into one service as well. You can think of it similar to checking tcp port 443, checking the SSL handshake and then checking a GET, but all in one command. If it fails the TCP handshake, it will be CRITICAL and inform why - so there is generally no reason to deconstruct each test into individual services.
Does this look right? Still no email notifications. I have an Always Time Period. Email from CLI works. What does ‘corp’ refer to here? icinga2 object list --type=notification does not return any values/output.
“corp” was relevant in the other thread but may not be here. The reason I used it as an example was with regards to the fact that it is a boolean and to use that same syntax (i.e. do not compare it to a string).
zones.d/master/notification_apply.conf
apply Notification "Services Notification" to Service {
import "Template for Services to be monitored"
period = "Always"
assign where host.vars.os in [ "Linux" ]
states = [ Critical ]
types = [ Problem ]
users = [ "sysadmin" ]
}
zones.d/master/notification_apply.conf
apply Notification "Host Notifications" to Host {
import "Template for Hosts to be monitored"
period = "Always"
assign where host.vars.os in [ "Linux" ]
states = [ Down ]
users = [ "sysadmin" ]
}
First guess is assign where host.vars.os in [ "Linux" ]. You may not be getting that value (there are some other threads that are similar, iirc). I would test it with something more standard/universally accessible first. Personally I like using host.groups since can be used somewhat like a tag.
zones.d/master/notification_apply.conf
apply Notification "Services Notification" to Service {
import "Template for Services to be monitored"
period = "Always"
assign where "admin" in host.groups
states = [ Critical ]
types = [ Problem ]
users = [ "sysadmin" ]
}
[2021-11-06 22:55:06 -0400] warning/ApplyRule: Apply rule 'Services Notification'
(in [stage]/zones.d/master/notification_apply.conf: 1:0-1:52) for type 'Notification' does not match anywhere!
[2021-11-06 22:55:06 -0400] warning/ApplyRule: Apply rule 'Host Notifications'
(in [stage]/zones.d/master/notification_apply.conf: 11:1-11:47) for type 'Notification' does not match anywhere!
