Il tuo host definisce l'attributo personalizzato "http_vhosts" come dizionario ma non viene mai utilizzato (non è possibile applicare l'iterazione definita dalla regola su quel dizionario e gli oggetti del servizio di gebering).
Invece la regola di applicazione del servizio (senza un ciclo for) applica solo il servizio "httpS". Per caso l'ospite attributo personalizzato "http_ssl" è impostato - dovrebbe leggere vero come booleano invece di un numero come stringa (che è sempre vero).
Probabilmente vuoi controllare più URI, non solo /.
La mia proposta (2 soluzioni):
1) Correggi la regola di applicazione del servizio e rimuovi gli attributi personalizzati http_ * dalla definizione dell'oggetto host. Invece aggiungili alla regola di applicazione del servizio:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Puoi trovare tutti gli attributi personalizzati usati come parametri di comando per http CheckCommand nella documentazione: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check- comando-http
2) Utilizzare invece un servizio applicare per la regola e scorrere il dizionario http_vhosts definito nell'host.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Nota la denominazione qui: "https /" sarà il nome del servizio generato. http_ssl e http_uri sono gli stessi nomi esatti degli attributi personalizzati richiesti da http CheckCommand.
La magia si verifica all'interno della domanda di applicazione: la chiave del dizionario sarà il nome del servizio. Il valore del dizionario è un dizionario nidificato e contiene http_uri e http_ssl come chiavi. Nell'esempio che si chiama "config". Quel dizionario di configurazione ha la stessa struttura dell'attributo "vars", motivo per cui possiamo semplicemente aggiungerlo all'interno del servizio per la definizione.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Verificare la configurazione utilizzando il demone icinga2 -C e quindi esaminare gli oggetti servizio generati per vedere quali attributi personalizzati vengono generati (elenco oggetti icinga2).
Una cosa positiva: tutti gli host che hanno definito l'attributo personalizzato http_vhosts genereranno questi oggetti di servizio, non c'è bisogno di un'espressione extea "Assegna dove" (forse aggiungi ignora dove per eccezioni). Con la giusta strategia scriverai per applicare le regole solo una volta, e in futuro aggiungerai solo nuovi host con il corrispondente dizionario degli attributi personalizzati :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Sebbene la soluzione 2) richieda una conoscenza avanzata del linguaggio di configurazione icinga 2 e delle sue parole chiave, tipi di valore e trucchi magici. Tuttavia riteniamo che tali metodi e buone pratiche contribuiscano a ridurre la manutenzione a lungo termine con l'adozione e la modifica dei file.
Potresti anche andare oltre e utilizzare le condizioni if-else per differenti trebbie in base al nome host. Oppure utilizzare le funzioni per definire soglie dinamiche basate, ad esempio, su periodi di tempo.