Seu host define o atributo personalizado "http_vhosts" como dicionário, mas isso nunca é usado (não há como aplicar a regra definida iterando sobre esse dicionário e geberando objetos de serviço).
Em vez disso, a regra de aplicação do serviço (sem um loop for) apenas aplica o serviço "httpS". Por acidente, o atributo personalizado do host "http_ssl" está definido - ele deve ser verdadeiro como booleano, em vez de um número como string (isso sempre é verdade).
Você provavelmente deseja verificar vários URIs, não apenas /.
Minha proposta (2 soluções):
1) Corrija a regra de aplicação do serviço e remova os atributos customizados http_ * da definição do objeto host. Em vez disso, adicione-os à regra de aplicação do serviço:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Você pode encontrar todos os atributos personalizados usados como parâmetros de comando para o http CheckCommand na documentação: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check- command-http
2) Use um serviço para aplicar regra e faça um loop sobre o dicionário http_vhosts definido no host.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Observe a nomeação aqui: "https /" será o nome do serviço gerado. http_ssl e http_uri são exatamente os mesmos nomes que os atributos customizados necessários pelo http CheckCommand.
A mágica acontece dentro da regra de solicitação de inscrição: a chave do dicionário será o nome do serviço. O valor do dicionário é um dicionário aninhado e contém http_uri e http_ssl como chaves. No exemplo chamado "config". Esse dicionário de configuração tem exatamente a mesma estrutura que o atributo "vars", e é por isso que podemos apenas adicioná-lo dentro do serviço Apply for Definition.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Verifique a configuração usando o icinga2 daemon -C e, em seguida, examine os objetos de serviço gerados para ver quais atributos customizados são gerados (lista de objetos icinga2).
Uma coisa boa - todos os hosts que possuem o atributo personalizado http_vhosts definido geram esses objetos de serviço, não há necessidade de uma expressão extea "assign where" (talvez prefira ignorar where para exceções). Com a estratégia certa, você escreverá para aplicar regras apenas uma vez e adicionar novos hosts com o dicionário de atributos personalizados correspondente no futuro :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Embora a solução 2) exija conhecimento avançado sobre a linguagem de configuração do icinga 2 e suas palavras-chave, tipos de valor e truques de mágica. No entanto, acreditamos que esses métodos e práticas recomendadas ajudam a reduzir a manutenção a longo prazo com a adoção e alteração de arquivos.
Você também pode ir além e usar condições if-else para threshokds diferentes com base no nome do host. Ou use funções para definir limites dinâmicos com base em períodos de tempo, por exemplo.