Monitoraggio di OpenShift

Poiché i cluster OpenShift possono subire cambiamenti importanti anche molto rapidamente in termini di numero e posizione dei singoli componenti, ti consigliamo di creare un'istanza Checkmk separata per il monitoraggio di un ambiente OpenShift, che potrà poi essere connessa al sito centrale come di consueto tramite la procedura di monitoraggio distribuito.

Checkmk monitora i tuoi cluster OpenShift in due modi:

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

Nell'esempio che segue, chiameremo questo namespace checkmk-monitoring. Se vuoi o devi scegliere un nome diverso, dovrai apportare questa modifica al momento della creazione dell'account del servizio.

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

In alternativa, puoi prima scaricare questo file YAML, personalizzarlo secondo le tue esigenze e poi applicare oc apply -f a questa copia locale del file.

Con lo strumento da linea di comando oc puoi leggere tutte le informazioni del tuo cluster che di solito devi specificare per configurare lo special agent. Se hai cambiato il nome del servizio o il namespace, devi modificare queste informazioni come descritto nei comandi seguenti.

È meglio memorizzare la password (token) dell'account del servizio nell'archivio password di Checkmk. Questa è l'opzione più sicura, perché puoi separare l'archiviazione e l'uso della password in modo organizzato. In alternativa, inserisci la password direttamente in testo normale quando crei la regola (vedi sotto).

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

Affinché Checkmk possa fidarsi 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 alla voce Setup > General > Global settings > Site management > Trusted certificate authorities for SSL:

Crea un nuovo host in Checkmk nel modo consueto e chiamalo, ad esempio, myopenshiftclusterhost. Come suggeriscono il titolo e il nome dell'host, questo host viene utilizzato per raccogliere i dati piggyback e anche per mappare tutti i servizi e le metriche a livello di cluster. Poiché questo host riceve i dati esclusivamente attraverso 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 gli oggetti in diversi cluster di Kubernetes, di solito è conveniente creare una cartella per ogni cluster tramite Setup > Hosts > Add folder, in cui la configurazione dinamica degli host può creare automaticamente tutti gli host del cluster. Tuttavia, la creazione e l'utilizzo di tale cartella è facoltativa.

Quindi, imposta un connettore per i dati piggyback in arrivo. 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, è quello di inserire l'host piggyback creato in precedenza alla voce Restrict source hosts.

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

Puoi lasciare invariati gli attributi predefiniti in Host attributes to set. Questi garantiscono che Checkmk accetti i dati piggyback solo dagli host creati automaticamente e non tenti di pingarli o di accedervi tramite SNMP, ad esempio.

In un ambiente OpenShift in cui gli oggetti monitorati e monitorabili 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 dedicato alla cancellazione automatica degli host nell'articolo sulla configurazione dinamica degli host.

Infine, attiva l'opzione Discover services during creation.

La sezione Connection Properties di questo nuovo connettore potrebbe avere il seguente aspetto:

Per impostazione predefinita, Checkmk esegue una scoperta del servizio ogni due ore e visualizza i risultati di questa ricerca 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 riportate nello screenshot qui sotto sono solo degli esempi. Dovrai decidere caso per caso cosa ha senso per i tuoi cluster.

Per limitare questa regola a tutti gli host del tuo cluster, alla voce Host labels inserisci semplicemente cmk/kubernetes:yes nel modulo Conditions. Tuttavia, se vuoi creare regole diverse per cluster diversi, utilizza l'etichetta specifica del cluster. Queste etichette sono sempre nella forma cmk/kubernetes/cluster:mycluster.

Ora che tutti i prerequisiti sono stati creati nel cluster e in Checkmk, puoi rivolgere la tua attenzione alla configurazione dell'agente special agent, che si trova 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 e serve per assegnare un nome univoco a tutti gli oggetti che provengono da questo specifico cluster. Ad esempio, se inserisci mycluster, i nomi degli host di tutti i pod di questo cluster inizieranno con pod_mycluster. La parte successiva del nome dell'host sarà sempre il namespace in cui esiste questo oggetto Kubernetes. Ad esempio, il nome dell'host di un pod potrebbe essere pod_mycluster_kube-system_svclb-traefik-8bgw7.

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

Alla voce API server connection > Endpoint, Checkmk ti chiede ora di inserire l'URL attraverso il quale il tuo server Checkmk API può essere contattato. La porta è necessaria solo se il servizio non è fornito tramite un host virtuale. In questo caso, inserisci l'indirizzo che hai determinato nella sezione Recuperare l'endpoint dell'API di Kubernetes.

Se finora hai seguito le istruzioni passo per passo e,come descritto in precedenza, hai depositato il certificato CA del tuo cluster in Checkmk, alla voce SSL certificate verification seleziona Verify the certificate.

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

L'elenco alla voce Collect information about…​ ti permette di selezionare quali oggetti del tuo cluster devono essere monitorati. Questo elenco copre gli oggetti più importanti. Se decidi di monitorare anche Pods of CronJobs, consulta l'aiuto inline per questa opzione.

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

L'opzione Cluster resource aggregation ti permette di progettare i nodi che non forniscono risorse per il workload del cluster. Questi nodi devono essere esclusi dal calcolo delle risorse disponibili, altrimenti si rischia di non rilevare i colli di bottiglia della capacità. Per questo motivo, per impostazione predefinita, escludiamo i nodi control-plane e infra dal calcolo.

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

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

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

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

A questo punto attiva le modifiche apportate e lascia che sia la configurazione dinamica degli host a fare il lavoro d'ora in poi: in questo modo verranno generati tutti gli host per i tuoi oggetti Kubernetes in un breve periodo di tempo.

Le edizioni commerciali di Checkmk vengono fornite con sei dashboard integrate per Kubernetes. Per poter utilizzare queste dashboard, è necessario che il nostro Cluster Collector sia installato e configurato. In particolare, queste dashboard sono chiamate:

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

Nella dashboard Kubernetes, tutti i cluster monitorati sono elencati sul lato sinistro. Questo elenco di cluster è anche la voce dell'elenco per approfondire le dashboard. Facendo clic sul nome di un cluster si accede alla dashboard Kubernetes Cluster per il cluster selezionato. Nella dashboard Kubernetes Cluster, facendo clic sul rispettivo nome si accede alle altre dashboard dipendenti dal contesto:

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

Allo stesso modo, cioè negli altri dashboard, attraverso i box con i nomi ID degli oggetti, è possibile visualizzare l'inventario per ogni rispettivo oggetto. L'esempio seguente mostra l'inventario HW/SW di un pod:

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