How to monitor remote “https” with Icinga version 2?

Your host defines the custom attribute "http_vhosts" as dictionary but that's never used (there's no apply for rule defined iterating over that dictionary and geberating service objects).

Instead the service apply rule (without a for loop) just applies the service "httpS". By accident the host custom attribute "http_ssl" is set - it should read true as boolean instead of a number as string (that's always true).

You probably want to check multiple URIs, not only /.

My proposal (2 solutions):

1) Fix your service apply rule and remove the http_* custom attributes from your host object definition. Instead add them to the service apply rule:

apply Service "httpS" {
  import "generic-service"
  check_command = "http"
  vars.http_uri = "/"
  vars.http_ssl = true
  assign where host.name == "mailserver-01"
}

You can find all custom attributes used as command parameters for the http CheckCommand in the documentation: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-http

2) Use a service apply for rule instead and loop over the http_vhosts dictionary defined at the host.

vars.http_vhosts["https /"] = {
  http_ssl = true
  http_uri = "/"
}

Note the naming here: "https /" will be the generated service name. http_ssl and http_uri are the exact same names as the required custom attributes by the http CheckCommand.

The magic happens inside the apply for rule: The dictionary key will be the service name. The dictionary value is a nested dictionary and contains http_uri and http_ssl as keys. In the example that's called "config". That config dictionary has the exact same structure as the "vars" attribute which is why we can just add it inside the service apply for definition.

apply Service for (servicename => config in host.vars.http_vhosts) {
  import "generic-service"
  check_command = "http"
  vars += config
}

Verify the config using icinga2 daemon -C and then look into the generated service objects to see which custom attributes are generated (icinga2 object list).

One good thing - all hosts which have the http_vhosts custom attribute defined will generate these service objects, there's no need for an extea "assign where" expression (maybe rather add ignore where for exceptions). With the right strategy you'll write apply for rules just once, and only add new hosts with matching custom attribute dictionary in the future :-)

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for

Though solution 2) requires advanced knowledge about the icinga 2 configuration language and its keywords, value types and magic tricks. Yet we think that such methods and best practices help reduce the long term maintenance with adopting and changing files.

You could also go further and use if-else conditions for different threshokds based on the host name. Or use functions to define dynamic thresholds based on timeperiods for example.

I googled and found http command in

/usr/share/icinga2/include/command-plugins.conf

In this example i have tried to monitor https://mail.google.com Below is /etc/icinga2/conf.d/hosts.conf

object Host "www.google.com" {
address = "74.125.136.84"
check_command = "http"
vars.http_vhost = "mail.google.com"
vars.http_ssl = "1"
}

Here what it looks like on icingaweb2 dashboard

Example2

object Host "secure.example.com" {
    address = "14.28.83.22"
    check_command = "http"
    vars.http_vhosts["secure.example.com"] = {
    http_uri = "/merchant/login.aspx"    
    }
        vars.notification["mail"] = {
        groups = [ "icingaadmins" ]
        }
    vars.http_ssl="1"
}