Amministrazione dell’istanza con omd

In alcuni casi è anche utile specificare l'ID utente/gruppo del nuovo utente da creare. Questo si fa con le opzioni -u e -g, ad esempio:

Puoi visualizzare una panoramica delle altre opzioni con omd create --help. Le opzioni più importanti sono:

Per impostazione predefinita, la directory home di una nuova istanza viene creata in /omd/sites/ e riempita con i file predefiniti. Tuttavia, puoi anche creare una directory home vuota, ad esempio per montare un volume esterno in questa posizione. Questo si ottiene con l'opzione --no-init:

Questa opzione omette anche l'integrazione con l'Apache di sistema, lasciando /omd/apache/mysite.conf vuota. Potresti quindi montare qualsiasi directory o volume e continuare il Setup:

omd init poi recupera i due passaggi omessi, quindi aggiunge i file predefiniti e crea la configurazione di Apache.

Come utente dell’istanza puoi semplicemente richiamare la modalità interattiva con:

Non appena modifichi un'impostazione mentre l'istanza è in esecuzione, OMD ti informerà che devi prima arrestare l'istanza e lo farà se necessario:

Non dimenticare di riavviare l'istanza al termine del lavoro. omd confignon lo farà automaticamente per te.

Chi non ama la modalità interattiva o preferisce lavorare con gli script può impostare le singole impostazioni come variabili tramite la riga di comando. A questo scopo è disponibile il comando omd config set. L'esempio seguente imposta la variabile AUTOSTART su off:

Questo può essere eseguito anche come root se il nome dell'istanza viene aggiunto come argomento:

L'assegnazione attuale di tutte le variabili viene visualizzata come root il comando omd config mysite show e come utente dell’istanza omd config show:

L'output sopra riportato è stato abbreviato per chiarezza e mostra solo le prime voci.

omd config offre numerose impostazioni. Le più importanti sono:

Nota: puoi vedere queste variabili con gli stessi nomi anche in modalità interattiva.

A volte è utile creare una copia di un'istanza per fare dei test o quando ti prepari per un aggiornamento. Ovviamente potresti semplicemente copiare la directory /omd/sites/mysite_old in /omd/sites/mysite_new. Questo però non funzionerà come vorresti, perché:

Per semplificare la copia di un'istanza, c'è invece il comando omd cp, che tiene conto di tutto questo. Esegui il comando come root e inserisci semplicemente il nome dell'istanza esistente seguito dal nome di quella nuova. Ad esempio:

La copia funziona solo se:

Entrambe queste condizioni assicurano che l'istanza sia in uno stato coerente al momento della copia e non cambi durante l'operazione.

Inizialmente, OMD poteva handle solo i file creati effettivamente durante la creazione dell'istanza con omd create e che contenevano anche l'ID dell'istanza ($OMD_SITE). Questi file si trovano nella directory dell'istanza ~/etc con questo comando:

In precedenza, OMD non poteva fare nulla con i file di configurazione creati successivamente tramite il lavoro con il sito Checkmk (ad esempio, le configurazioni degli host aggiunti in un secondo momento). Da un punto di vista puramente tecnico, questo comportamento corrisponde esattamente all’ambito di OMD. Tuttavia, la maggior parte degli utenti si aspetta che un’omd cpe crei un’istanza completamente nuova che possa continuare a essere utilizzata in modo produttivo, inclusa la propria configurazione di monitoraggio.

A partire dalla versione 2.1.0 di Checkmk, OMD può ora personalizzare anche gli elementi più importanti della configurazione di Checkmk. A proposito, non devi fare nulla, l’intera migrazione descritta di seguito avviene automaticamente.

Un esempio tipico: Nelle proprietà di un host puoi usare l'attributo Monitored on site per specificare manualmente su quale istanza questo host debba essere sottoposto a monitoraggio, ad esempio mysite_old. Dopo un omd cp mysite_old mysite_new il valore cambierà di conseguenza in mysite_new. (In precedenza questa procedura avrebbe portato alla voce Unknown site (mysite_old)).

L'effettiva implementazione tecnica di questa migrazione è la seguente: OMD rileva le modifiche all'ID dell'istanza e quindi esegue il comando post-rename-site -v -o mysite_new. I singoli passaggi della migrazione vengono successivamente elaborati in modo completamente automatico tramite i cosiddetti plugin delle azioni di rinominazione, che puoi trovare su cmk/post_rename_site/plugins/actions nel repository Git.

La migrazione include anche l'invio di notifiche su tutto ciò che non può essere migrato automaticamente.

Ecco un esempio concreto: stai utilizzando il monitoraggio distribuito e rinomini sia l’istanza centrale che un’istanza remota.

Istanza centrale: il plug-in sites.py rileva che si tratta di un'istanza centrale e aggiorna, tra le altre cose, il valore URL prefix, che si trova nelle impostazioni di connessione dell'istanza locale alla voce Setup > General > Distributed Monitoring.

Istanza remota: il plug-in warn_remote_site.py riconosce che si tratta di un’istanza remota e indica di conseguenza che l’istanza centrale deve essere controllata e, se necessario, personalizzata manualmente. Ciò significa a sua volta che nelle impostazioni di monitoraggio distribuito sull’istanza centrale, il nuovo nome dell’istanza remota deve essere inserito nelle impostazioni di connessione all’istanza remota rinominata — ovviamente OMD non può farlo da un computer remoto.

OMD stesso ti informa in dettaglio sull'intera procedura nel terminale. Qui puoi vedere un esempio dei messaggi di migrazione dall'output di omd cp durante la ridenominazione di un'istanza centrale — suddivisi in messaggi di successo e di avviso. Gli rename action pluginsi elaborati sono numerati singolarmente. Prima l'output delle attività di migrazione eseguite automaticamente (qui abbreviato):

La seconda parte dell'output contiene ora suggerimenti relativi alle impostazioni che potrebbe essere necessario configurare manualmente (qui fortemente abbreviati):

L'elemento "Warn about configurations to review…​" include note generali su singoli aspetti che in genere devono essere controllati manualmente durante una migrazione, come i filtri hardcoded per le visualizzazioni:

Ecco una panoramica dei sei plug-in attualmente attivi — l'ordine qui corrisponde alla numerazione nell'output sopra riportato:

Se stai monitorando un gran numero di host con l'istanza, il volume dei dati da copiare può essere piuttosto consistente. La maggior parte di questi dati è costituita dai valori misurati memorizzati nei Database Round Robin (RRD). Ma anche i file di log contenenti gli eventi storici possono generare volumi di dati più grandi.

Se la cronologia non è necessaria (ad esempio, perché vuoi solo testare rapidamente qualcosa), questi possono essere omessi dalla copia. In questi casi è possibile aggiungere le seguenti opzioni a omd cp:

L'ordine delle opzioni è importante:

La ridenominazione di un'istanza viene eseguita con il comando omd mv. L'operazione è simile alla copia di un'istanza, ha gli stessi prerequisiti e viene eseguita includendo anche la migrazione della configurazione. Le opzioni per limitare il volume dei dati non sono disponibili poiché i dati vengono solo spostati in un'altra directory e non vengono duplicati.

Esempio:

Quando si rinomina un sito con omd mv, il nome dell'istanza verrà modificato, ma alcuni attributi dell'istanza rimarranno invariati, incluso l'ID dell'istanza. Questo comando non è quindi adatto per gestire un'istanza che è stata duplicata, ad esempio tramite un backup, contemporaneamente alla sua versione originale in un monitoraggio distribuito — anche se le istanze coinvolte hanno nomi diversi dopo l'esecuzione di un omd mv.

Come per la creazione di un sito, anche la copia e la ridenominazione creano un nuovo utente Linux. Pertanto, anche omd cp e omd mv hanno alcune delle stesse opzioni di omd create, ad esempio per specificare gli ID utente e gruppo. Per informazioni più dettagliate, usa i comandi omd cp --help e omd mv --help.

La gestione delle istanze in Checkmk dispone di un meccanismo integrato per il backup e il ripristino delle istanze Checkmk. I comandi omd backup e omd restore sono fondamentali per comprimere tutti i dati dell’istanza in un archivio tar e, rispettivamente, per estrarre tali dati in vista di un ripristino.

Nota: Checkmk offre anche la possibilità di eseguire backup e ripristini senza usare la riga di comando, tramite la GUI in Setup > Maintenance > Backups. Lì puoi anche creare backup crittografati e pianificare richieste di backup. Consulta l'articolo Backup per imparare come farlo.

Il backup di un sito con omd backup non richiede permessi droot. Può essere eseguito da un utente dell’istanza. Basta inserire come argomento il nome del file di backup da creare:

Nota che:

Se la directory di destinazione del backup non è scrivibile per un utente dell’istanza, puoi anche eseguire il backup come root. In questo caso è richiesto un argomento aggiuntivo, come sempre, che specifichi il nome dell’istanza di cui eseguire il backup:

Il backup contiene tutti i dati dell’istanza, con l’eccezione dei dati volatili presenti in ~/tmp/. Con il comando tar tzf è possibile visualizzare facilmente il contenuto del file:

La maggior parte dei dati da spostare durante un backup dell'istanza sono i valori misurati memorizzati nei database Round Robin (RRD) e i file di log con gli eventi storici. Un'altra parte significativa dei dati da spostare durante un backup dell'istanza sono i pacchetti degli agenti, che vengono memorizzati da agent bakery nella directory ~/var/check_mk/agents, ma questi possono essere facilmente ricreati se necessario.

omd backup offre le stesse opzioni di omd cp quando si copia per escludere questi dati. Nell'esempio seguente, il backup viene creato completamente senza questi dati:

Durante il backup, puoi anche specificare quali dei dati sopra indicati desideri escludere. Usa omd backup --help per visualizzare le opzioni disponibili.

È possibile creare un backup anche da un'istanza in esecuzione. Per garantire uno stato coerente degli RRD utilizzati per la registrazione dei dati di misurazione, il comando omd backup modifica automaticamente la cache Round Robin in una modalità in cui gli aggiornamenti in corso vengono scritti solo nel journal e non più negli RRD. I file del journal sono gli ultimi ad essere sottoposti a backup: in questo modo è possibile includere nel backup il maggior numero possibile di dati di misurazione generati durante il backup stesso.

Ripristinare un backup è semplice quanto crearne uno. Il comando omd restore effettua il ripristino di un'istanza da un backup — nella versione di Checkmk utilizzata per eseguire il backup dell'istanza. Pertanto, affinché il ripristino funzioni, questa stessa versione deve essere installata sul server.

L'istanza viene completamente svuotata e riempita nuovamente. Prima di eseguire il comando omd restore, l'istanza deve essere arrestata e successivamente riavviata:

Un ripristino può essere eseguito anche da un utente root. A differenza di quando viene richiamato dall'utente dell’istanza, l’istanza verrà ricreata con il backup.

Quindi, se esiste già una istanza con lo stesso nome, dovrai eliminarla prima del ripristino. Questo può essere eseguito sia con un omd rm, sia semplicemente includendo l'opzione --reuse nel comando omd restore. Un --kill garantisce inoltre che l'istanza già esistente venga arrestata prima che il ripristino proceda. Non è necessario specificare il nome dell'istanza nel comando, poiché è contenuto nel backup:

Come root , puoi anche effettuare il ripristino di un'istanza con un nome diverso da quello presente nel backup. Per farlo, specifica il nome desiderato come argomento dopo la parola restore:

L'elenco lungo delle conversioni che avvengono qui ha la stessa funzione descritta in precedenza per la copia e la rinominazione delle istanze. Il nome dell'istanza è presente in numerosi file di configurazione e, con questa procedura, tutte le occorrenze verranno sostituite automaticamente con il nuovo nome.

I comandi omd backup e omd restore possono — nella buona vecchia tradizione Unix — funzionare anche tramite input/output standard invece che tramite file. Invece del percorso del file tar, inserisci semplicemente un trattino (-).

In questo modo è possibile creare un pipe e "trasmettere" i dati direttamente a un altro computer senza bisogno di file intermedi. Più grande è il backup, più vantaggioso sarà questo metodo, poiché non sarà necessario spazio temporaneo nel file system del server di cui si esegue il backup.

Il comando seguente esegue il backup di un'istanza su un altro computer utilizzando SSH:

Se vuoi invertire l'accesso SSH, cioè preferisci effettuare la connessione dal server di backup all'istanza Checkmk, anche questo è possibile, come mostra l'esempio seguente. Per farlo, devi prima autorizzare un login SSH come utente dell’istanza.

Se sei furbo e combini quanto sopra con un omd restore che legge i dati dall'input standard, puoi copiare un'istanza completa e funzionante da un server all'altro — senza bisogno di spazio aggiuntivo per un file di backup:

E ora di nuovo l'intera procedura con accesso SSH inverso — questa volta dal sistema di origine a quello di destinazione: