Best practice del server Nagios?

Gruppi host e modelli.

I modelli ti consentono di definire le classi per i tuoi host e servizi, ad es. "servizio normale", "servizio critico", "host a bassa priorità". Servono anche come un modo utile per dividere le responsabilità se hai più team con responsabilità diverse, quindi puoi avere un modello "host linux" e un modello "host windows", con ognuno che definisce le informazioni di contatto appropriate.

Puoi utilizzare più modelli su una singola risorsa, in modo da poter comporre modelli opportunamente ortogonali. Ad esempio, puoi avere

host foo {
    use windows-host,normal-priority-host
    ...
}

che riporterebbe le informazioni di contatto (e le escalation) per il team di Windows e i tassi di polling e le soglie per un host "normale".

I gruppi host ti consentono di raggruppare tutti i controlli per un sottoinsieme dei tuoi host. Avere cose come "baseline-linux-hosts" che controllano il carico, lo spazio su disco, ssh capacità e qualsiasi altra cosa dovrebbe essere su ogni host monitorato. Aggiungi gruppi come "server https" con controlli per connettività HTTP, connettività HTTPS e date di scadenza del certificato SSL; "file server" con controlli per l'accessibilità NFS e SMB e forse controlli del disco più aggressivi; o "macchine virtuali" con controlli per verificare se gli strumenti di accessibilità VM funzionano correttamente.

Inserisci ogni host e gruppo host nel proprio file. Quel file dovrebbe contenere prima la definizione dell'host o del gruppo host, seguita dalle definizioni dei servizi che si applicano ad esso.

Se usi il cfg_dir direttiva nel tuo nagios.cfg file, Nagios cercherà ricorsivamente attraverso quella directory. Usalo. Per un'impostazione di cfg_dir=/etc/nagios/conf.d , puoi avere un albero di directory come il seguente:

• /etc/nagios/conf.d/
  • comandi.d/
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d/
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d/
    • hostgroup1.cfg
    • hostgroup2.cfg

Tendo a creare una directory per ogni tipo di risorsa (comandi, gruppi di contatti, contatti, escalation, gruppi di host, host, gruppi di servizi, periodi di tempo) ad eccezione dei servizi, che vengono raggruppati con gli host o i gruppi di host che li utilizzano.

La struttura precisa può variare in base alle vostre esigenze organizzative. In un lavoro precedente, ho utilizzato le sottodirectory in hosts.d per ogni sito diverso. Nel mio attuale lavoro, la maggior parte delle definizioni degli host di Nagios sono gestite da Puppet, quindi c'è una directory per gli host gestiti da Puppet e una separata per gli host gestiti manualmente.

Si noti che quanto sopra suddivide anche i comandi in più file, generalmente in base al protocollo. Pertanto, il nrpe.cfg file avrebbe i comandi check_nrpe e check_nrpe_1arg , mentre http.cfg potrebbe avere check_http , check_http_port , check_https , check_https_port e check_https_cert .

In genere non ho un numero enorme di modelli, quindi di solito ho solo un hosts.d/templates.cfg file e un services.d/templates.cfg file. Se li usi più pesantemente, possono andare in file con nomi appropriati in un templates.d cartella.

Mi piace avere anche un check_http_blindly comando, che in pratica è check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; restituisce OK anche se riceve un codice di risposta 403.

Fai ampio uso di servizi, gruppi host e modelli. Creare gruppi host e assegnare servizi ai gruppi host. Utilizza i gruppi di servizio per le dipendenze, le escalation e il raggruppamento logico nell'interfaccia utente web.

Se hai gruppi per tutto, l'aggiunta di un nuovo host richiede solo 3 o 4 righe:nome, indirizzo, modello/i e (facoltativamente) gruppi host. Tutto può essere modellato.

Assicurati di leggere i documenti sull'ereditarietà e anche la pagina dei trucchi per risparmiare tempo. L'ereditarietà multipla può diventare complicata, ma se usata correttamente è un enorme risparmio di tempo.