Monitoraggio di OpenShift

Dato che i cluster OpenShift possono subire cambiamenti significativi in tempi molto rapidi per quanto riguarda il numero e la posizione dei singoli componenti, ti consigliamo di creare un'istanza Checkmk separata per il monitoraggio di un ambiente OpenShift. Questo può poi essere collegato all'istanza centrale come al solito tramite la procedura di monitoraggio distribuito.

Checkmk effettua il monitoraggio dei tuoi cluster OpenShift in due modi:

Per prima cosa, devi configurare un namespace e un account di servizio per Checkmk nel tuo cluster OpenShift. Il modo più veloce per farlo è tramite la CLI di OpenShift (abbreviata in oc).

Nell'esempio seguente, chiameremo questo namespace checkmk-monitoring. Se vuoi o devi scegliere un nome diverso, dovrai apportare questa modifica anche durante la creazione dell'account del servizio.

L'account di servizio con il ruolo associato e il cosiddetto RoleBinding può essere creato specificando il nostro file YAML già pronto pubblicato su GitHub. Check il suo contenuto e poi esegui il seguente comando:

In alternativa, puoi prima effettuare lo scaricamento di questo file YAML, personalizzarlo in base alle tue esigenze e poi applicare oc apply -f a questa copia locale del file.

Con lo strumento da riga di comando oc ora puoi anche leggere tutte le informazioni dal tuo cluster, che di solito dovresti specificare per configurare l'special agent. Se hai cambiato il nome dell'account di servizio o il namespace, devi modificare queste informazioni come descritto per i seguenti comandi.

È consigliabile memorizzare la password (token) dell'account di servizio nell'archivio password di Checkmk. Questa è l'opzione più sicura, poiché ti permette di separare in modo organizzato la memorizzazione e l'utilizzo della password. In alternativa, inserisci la password direttamente in chiaro durante la creazione della regola (vedi sotto).

Per aggiungere la password all'archivio password di Checkmk, vai su Setup > General > Passwords > Add password. Nel nostro esempio usiamo My OpenShift Token come ID e titolo:

Affinché Checkmk si fidi della catena di certificati dell'account di servizio, dovrai memorizzarla in Checkmk. Copia tutto qui — comprese le righe contenenti BEGIN CERTIFICATE e END CERTIFICATE — e aggiungi il certificato nel menu di configurazione sotto Setup > General > Global settings > Site management > Trusted certificate authorities for SSL:

Crea un nuovo host in Checkmk come al solito e chiamalo, ad esempio, myopenshiftclusterhost. Come suggeriscono il titolo e il nome host, questo host viene utilizzato per raccogliere i dati piggyback e anche per effettuare la mappatura di tutti i servizi e le metriche a livello di cluster. Poiché questo host riceve dati esclusivamente tramite l’agente speciale, nelle proprietà dell’host assicurati di impostare l’opzione IP address family su No IP. Conferma l’intera configurazione premendo il pulsante Save & view folder.

Per garantire la separazione tra oggetti in diversi cluster Kubernetes, di solito è comodo creare una cartella per ogni cluster tramite Setup > Hosts > Add folder, in cui la gestione dinamica degli host può creare automaticamente tutti gli host di un cluster. Tuttavia, la creazione e l'utilizzo di tale cartella sono facoltativi.

Successivamente, configura una connessione per i dati piggyback in entrata. Per farlo, vai su Setup > Hosts > Dynamic host management > Add connection. Inserisci prima un titolo e poi, sotto "Connection Properties", clicca su "show more".

Il passo successivo, molto importante, è inserire l'host piggyback creato in precedenza sotto "Restrict source hosts".

Quindi, sotto "Piggyback creation options", clicca su "Add new element" e sotto "Create hosts in" seleziona la cartella creata in precedenza.

Puoi lasciare gli attributi predefiniti in Host attributes to set così come sono. Questi assicurano che Checkmk accetti solo i dati piggyback dagli host creati automaticamente e non tenti di eseguire il ping su questi o di accedervi tramite SNMP, ad esempio.

In un ambiente OpenShift in cui gli oggetti monitorabili e monitorati vanno e vengono continuamente, di solito si consiglia di abilitare anche l'opzione Automatically delete hosts without piggyback data. Cosa fa esattamente questa opzione e in quali circostanze gli host vengono effettivamente eliminati è spiegato nel capitolo sull'eliminazione automatica degli host nell'articolo sulla gestione dinamica degli host.

Infine, abilita l'opzione "Discover services during creation".

La sezione "Connection Properties" di questa nuova connessione potrebbe apparire come segue:

Per impostazione predefinita, Checkmk esegue la scoperta del servizio ogni due ore e visualizza il risultato di questa scoperta nel servizio "Check_MK Discovery". Puoi trovare questa impostazione nel set di regole "Periodic service discovery". Nel contesto di OpenShift, ti consigliamo di creare una regola con l'etichetta "cmk/kubernetes:yes" per tutti gli host. Questo perché ogni host che rappresenta oggetti Kubernetes riceve automaticamente questa etichetta da Checkmk. In questo caso dovresti scegliere un intervallo più breve di due ore per la scoperta del servizio e attivare anche l'opzione "Automatically update service configuration". Le impostazioni nella schermata qui sotto sono solo esempi. Dovrai decidere cosa è più sensato per i tuoi cluster caso per caso.

Per limitare questa regola a tutti gli host del tuo cluster, in "Host labels" inserisci semplicemente "cmk/kubernetes:yes" nel campo "Conditions". Tuttavia, se vuoi creare regole diverse per cluster diversi, usa qui l'etichetta specifica del cluster corrispondente. Queste etichette hanno sempre il formato "cmk/kubernetes/cluster:mycluster".

Ora che tutti i prerequisiti sono stati creati nel cluster e in Checkmk, puoi dedicarti alla configurazione dell'special agent. Lo trovi all'indirizzo Setup > Agents > VM, cloud, container > Kubernetes. Crea una nuova regola con Add rule.

Prima di tutto, devi assegnare un nome al cluster da monitorare. Questo nome può essere specificato liberamente come desideri. Viene utilizzato per assegnare un nome univoco a tutti gli oggetti che provengono da questo specifico cluster. Ad esempio, se qui inserisci mycluster, i nomi degli host per tutti i pod in questo cluster inizieranno in seguito con pod_mycluster. La parte successiva del nome host sarà quindi sempre lo space dei nomi in cui si trova questo oggetto Kubernetes. Ad esempio, il nome host di un pod potrebbe essere pod_mycluster_kube-system_svclb-traefik-8bgw7.

In Token , seleziona ora la voce creata in precedenza dall'archivio password di Checkmk.

In API server connection > Endpoint, Checkmk richiede ora di inserire l'URL tramite il quale è possibile contattare il tuo server API Kubernetes. La porta è richiesta solo se il servizio non viene fornito tramite un host virtuale. Qui, inserisci l'indirizzo che hai determinato nella sezione Recupera l'endpoint API di Kubernetes.

Se finora hai seguito queste istruzioni passo dopo passo e hai — come descritto sopra — depositato il certificato CA del tuo cluster in Checkmk, allora sotto "SSL certificate verification" seleziona "Verify the certificate".

Abilita l'opzione "Enrich with usage data", seleziona "Use data from OpenShift" nel menu seguente e inserisci l'Prometheus API endpoint che hai individuato nella sezione "Recupera l'endpoint API di Prometheus".

L'elenco sotto "Collect information about…​" ti permette di selezionare quali oggetti all'interno del tuo cluster devono essere sottoposti a monitoraggio. Questo elenco include gli oggetti più rilevanti. Se decidi di sottoporre a monitoraggio anche l'Pods of CronJobs, consulta l'aiuto in linea per questa opzione.

Le due selezioni successive ti consentono di restringere ulteriormente gli oggetti da monitorare. Se sei interessato solo agli oggetti di determinati namespace, imposta questa opzione di conseguenza in "Monitor namespaces". Qui puoi inserire singoli namespace da monitorare oppure escludere esplicitamente singoli namespace dal monitoraggio.

L'opzione "Cluster resource aggregation" ti permette di indicare i nodi che non forniscono risorse per il carico di lavoro del tuo cluster. Questi nodi dovrebbero essere esclusi dal calcolo delle risorse disponibili. Altrimenti, c'è il rischio che i colli di bottiglia di capacità non vengano rilevati. Per questo motivo, di default escludiamo dal calcolo i nodi control-plane e infra.

Come opzione finale, puoi importare le cosiddette annotazioni da Kubernetes. In Checkmk, queste annotazioni diventano etichette dell'host e possono quindi essere ulteriormente utilizzate come condizioni nelle regole. Usa le espressioni regolari per specificare quali annotazioni devono essere importate. A questo punto, consulta nuovamente l'aiuto in linea.

Nota: l'opzione "Import all valid annotations" è fornita qui solo per completezza. Non consigliamo di importare tutte le annotazioni in una volta sola, perché questo può creare una montagna enorme di etichette inutili in Checkmk.

Importante: In Conditions > Explicit hosts devi ora inserire l'host creato in precedenza:

Quindi salva la regola ed esegui la scoperta del servizio per questo host. I primi servizi a livello di cluster appariranno subito qui:

Ora attiva tutte le modifiche che hai apportato e lascia che la gestione dinamica degli host faccia il resto d'ora in poi. Questo genererà tutti gli host per i tuoi oggetti Kubernetes in breve periodo di tempo.

Le edizioni commerciali di Checkmk sono fornite con sei dashboard integrate per Kubernetes. Per poter interpretare correttamente queste dashboard, è necessario che il nostro Cluster Collector sia installato e configurato. Nello specifico, queste dashboard si chiamano:

Il punto di accesso è sempre la dashboard di Kubernetes, a cui puoi accedere tramite Monitor > Applications > Kubernetes:

Nella dashboard di Kubernetes, tutti i cluster monitorati sono elencati sul lato sinistro. Questo elenco di cluster è anche il tuo punto di accesso per approfondire le dashboard. Cliccando sul nome di un cluster verrai reindirizzato alla dashboard di Kubernetes Cluster relativa al cluster selezionato. Nella dashboard di Kubernetes Cluster, cliccando sul nome corrispondente verrai reindirizzato alle altre dashboard dipendenti dal contesto:

Il monitoraggio di OpenShift con Checkmk supporta anche l'inventario HW/SW. Ad esempio, nella dashboard del cluster sopra riportata, cliccando sul nome dell'ID del cluster (qui: mycluster) verrai reindirizzato all'inventario del cluster.

Allo stesso modo, ovvero nelle altre dashboard tramite le box con i nomi ID degli oggetti, è possibile visualizzare l'inventario di ciascun oggetto. L'esempio seguente mostra l'inventario HW/SW di un pod:

Se hai utilizzato il nostro file YAML predefinito per creare l'account di servizio, puoi anche eliminarlo come segue: