Le migliori pratiche del server Nagios?

Gestisco un server Nagios di medie dimensioni. Monitora attualmente circa 40 server con 180 servizi e cresce solo di giorno in giorno.

Sono migrato da una vecchia installazione di Nagios configurata in modo molto esoterico, costringendomi a riconfigurare tutto da zero.

Ora che il server è in esecuzione e funziona per la maggior parte di ciò di cui abbiamo bisogno , sto cercando di renderlo un po 'più scalabile; attualmente ogni host ha il suo file /etc/nagios/hosts/e ogni host ha tutti i suoi servizi nello stesso file. Questo ovviamente non è ottimale, ma neppure offusca tutta la mia configurazione in centinaia di file diversi.

Quindi la mia domanda è questa: per tutti gli amministratori Nagios esperti là fuori, qual è il modo migliore per utilizzare hostgroup / gruppi di servizi senza complicare eccessivamente la configurazione?

Hostgroup e modelli.

I modelli ti consentono di definire le classi per i tuoi host e servizi, ad esempio "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.

È possibile utilizzare più modelli su una singola risorsa, quindi è possibile comporre modelli appropriatamente ortogonali. Ad esempio, puoi avere

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

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

I gruppi di 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, le sshcapacità e qualunque altra cosa dovrebbe essere su ogni host che si monitora. Aggiungi gruppi come "https-server" con controlli per connettività HTTP, connettività HTTPS e date di scadenza del certificato SSL; "fileservers" con controlli di accessibilità NFS e SMB e controlli del disco forse più aggressivi; o "macchine virtuali" con controllo del corretto funzionamento degli strumenti di accessibilità della VM.

Inserisci ogni host e gruppo host nel suo file. Tale file deve contenere prima la definizione host o hostgroup, seguita dalle definizioni dei servizi ad esso applicabili.

Se usi la cfg_dirdirettiva nel tuo nagios.cfgfile, Nagios cercherà ricorsivamente attraverso quella directory. Usalo. Per un'impostazione di cfg_dir=/etc/nagios/conf.d, è possibile avere un albero di directory come il seguente:

• /etc/nagios/conf.d/
  • commands.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 esigenze dell'organizzazione. In un lavoro passato, ho usato le sottodirectory hosts.dper ogni sito diverso. Nel mio lavoro attuale, la maggior parte delle definizioni degli host Nagios sono gestite da Puppet, quindi esiste una directory per host gestiti da Puppet e una separata per host gestiti a mano.

Si noti che quanto sopra suddivide anche i comandi in più file, generalmente per protocollo. Così, il nrpe.cfgfile potrebbe avere i comandi check_nrpee check_nrpe_1arg, mentre http.cfgpotrebbe 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.cfgfile e un services.d/templates.cfgfile. Se li usi più pesantemente, possono andare in file con nomi appropriati in una templates.ddirectory.

¹ Mi piace anche avere un check_http_blindlycomando, che è fondamentalmente check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; restituisce OK anche se ottiene un codice di risposta 403.

Fare ampio uso del servizio e dei gruppi host e dei modelli. Creare hostgroup e assegnare servizi agli hostgroup. Utilizzare i gruppi di servizi per dipendenze, escalation e raggruppamento logico nell'interfaccia utente Web.

Se hai gruppi per tutto, l'aggiunta di un nuovo host è di sole 3 o 4 righe: nome, indirizzo, modello (i) e (facoltativamente) gruppi di 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 fa risparmiare molto tempo.

Ero abituato a configurare i miei server nagios (prima di passare a Icinga) in questo modo, e non mancano le prestazioni fino a quando non si raggiungono più di 500 servizi almeno con un server Memory / 1 CPU da 512 Mb. hostgroup e gruppi di servizi possono essere trattati completamente separatamente, e consiglierei questo approccio poiché consente di avere un file per server (servizi per questo server definiti in questo file) e quindi, su file per gruppo host / gruppi di servizi. Questo è solo più comprensibile / chiaro.

Se riscontri problemi di scalabilità, potresti voler dare un'occhiata a nagios-nrpe-server, che esegue controlli sul lato client e tutto ciò che fa il tuo nagios server richiede solo risultati; che risparmia la risorsa dell'assegno. (Nagios avvia check_nrpe, viene richiesto il client, esegue controlli localmente e risponde a nagios). Tenendo presente che tutti i controlli non possono essere trattati in questo modo (SNMP ad esempio).

Per finire, e anche se può sembrare fuori portata rispetto alla tua domanda, suggerirei di passare a Icinga, che è molto più scalabile, trattenuto da una comunità più forte che si prende davvero cura delle nuove implementazioni di funzionalità e del supporto utente. La configurazione è la stessa (stessi file di configurazione, stessa sintassi).

Sto usando questo schema:

• padroni di casa,
• hostgroups,
• servizi remoti,
• servizi locali.

Ogni entità ha il suo file. Inoltre con i template puoi sempre rendere il tuo dispositivo di configurazione più leggibile. Ad esempio, potresti avere una media di carico, spazio su disco, memoria su ogni host. Quindi è abbastanza facile e pratico creare un modello generico e usarlo.

Non è possibile complicare la configurazione con la creazione di gruppi. Come dice asciiphil, fai un file o puoi definire gli stessi gruppi in alcuni dei file esistenti come (hosts.cfg o qualsiasi altra cosa), e fai questo file o dici ai nagios che questo file è attivo (questo è se si crea un nuovo campo, se non è già attivo), e questo è nel file nagios.cfg dove si inserisce il percorso del file appena creato. "File_cfg = / usr / local / nagios / etc / oggetti / NEW_FILE.cfg"

L'altra cosa è solo creare gruppi in base alla propria infrastruttura. Se per esempio ho Linux e Windows Server creerò due diversi gruppi uno per Linux e l'altro per Windows. È lo stesso con i servizi. A seconda di come si desidera configurare e vedere quando si esegue il monitoraggio sul monitor, come si desidera vederli come gruppi.

E per il file o la parte come creare un gruppo è semplice.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

E sulla configurazione dell'host / o se si utilizza un modello o se si è già definito un modello o un servizio host e si utilizza l'utilizzo, è possibile indicare automaticamente a tutti gli host / finestre o host Linux di essere membri di un hostgroup definito creato.