Rimozione degli agenti plug-in di osservabilità

• Una volta terminato il supporto per il sito ob plugin, è necessario eliminare ogni singolo componente.

  1. Pulire i daemonset e le configmap.

      kubectl delete daemonset logdna-agent -n ibm-observe
      kubectl delete daemonset sysdig-agent -n ibm-observe
      kubectl delete configmap <logdna-configmap> -n ibm-observe
      kubectl delete configmap <sysdig-configmap> -n ibm-observe
      ```
  1. Facoltativo: Cancellare lo spazio dei nomi. Dopo che nessun'altra risorsa è in esecuzione nello spazio dei nomi.
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

Una volta rimosso il plug-in, reinstallare gli agenti di registrazione e monitoraggio nel cluster utilizzando la dashboard del cluster, Terraform o manualmente.

Per ulteriori informazioni, consulta i seguenti link:

• Invio dei dati di log di IBM Cloud Kubernetes Service a IBM Cloud Logs
• Monitoraggio di un cluster Kubernetes

Descrizione dell'inoltro dei log a un server esterno

Quando si crea una configurazione di registrazione per una sorgente nel proprio cluster al fine di inoltrare i dati a un server esterno, nel cluster viene creato un Fluentd viene creato un componente nel cluster. Fluentd raccoglie i log dai percorsi di tale origine e inoltra i log a un server esterno. Il traffico dall'origine al servizio di registrazione sulla porta di inserimento è crittografato.

Per quali sorgenti posso configurare l'inoltro dei log?

Nell'immagine seguente è possibile vedere l'area delle sorgenti per le quali è possibile configurare la registrazione.

1. worker: informazioni specifiche per la configurazione dell'infrastruttura del tuo nodo di lavoro. I registri dei processi vengono acquisiti in syslog e contengono gli eventi del sistema operativo. In auth.log puoi trovare informazioni sulle richieste di autenticazione che vengono effettuate al sistema operativo.

   Percorsi

   • /var/log/syslog
   • /var/log/auth.log

2. container: Informazioni registrate da un container in esecuzione. Percorsi: Qualsiasi dato scritto in STDOUT o STDERR.

3. application: informazioni sugli eventi che si verificano a livello dell'applicazione. Potrebbe trattarsi di una notifica relativa al verificarsi di un evento, come ad esempio un accesso riuscito, un avviso relativo allo spazio di archiviazione o altre operazioni eseguibili a livello di app. Percorsi: è possibile impostare i percorsi a cui inoltrare i log. Tuttavia, affinché i log vengano inviati, è necessario utilizzare un percorso assoluto nella configurazione della registrazione; in caso contrario, i log non potranno essere letti. Se il percorso è montato sul nodo di lavoro, è possibile che sia stato creato un collegamento simbolico. Esempio: se il percorso specificato è /usr/local/spark/work/app-0546/0/stderr ma i log vengono effettivamente salvati su /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr, allora non è possibile leggerli.

4. storage: informazioni sull'archiviazione persistente configurata nel tuo cluster. I log di archiviazione possono aiutarti a configurare dashboard e avvisi di determinazione dei problemi come parte delle tue release di produzione e pipeline DevOps. Nota: i percorsi/var/log/kubelet.log e /var/log/syslog contengono anche log di archiviazione, ma i log di questi percorsi vengono raccolti dalle origini log kubernetes e worker.

   Percorsi

   /var/log/ibmc-s3fs.log

   /var/log/ibmc-block.log

   Pod

   portworx-***

   ibmcloud-block-storage-attacher-***

   ibmcloud-block-storage-driver-***

   ibmcloud-block-storage-plugin-***

   ibmcloud-object-storage-plugin-***

5. kubernetes: informazioni da kubelet, kube-proxy e altri eventi Kubernetes che si verificano nello spazio dei nomi kube-system del nodo di lavoro.

   Percorsi

   /var/log/kubelet.log

   /var/log/kube-proxy.log

   /var/log/event-exporter/1..log

6. ingress: Informazioni sul traffico di rete in entrata in un cluster tramite l'ALB di Ingress.

   Percorsi

   /var/log/alb/ids/*.log

   /var/log/alb/ids/*.err

   /var/log/alb/customerlogs/*.log

   /var/log/alb/customerlogs/*.err

7. kube-audit: informazioni sulle azioni relative al cluster che vengono inviate al server API Kubernetes, inclusi l'ora, l'utente e la risorsa interessata. L'origine kube-audit può essere configurata con un webhook. Per ulteriori informazioni, vedi Inoltro dei log di verifica API Kubernetes a un server esterno.

Sono tenuto a mantenere aggiornato il sito Fluentd?

Per modificare le configurazioni di registrazione o dei filtri, è necessario che il componente di registrazione " Fluentd " sia aggiornato all'ultima versione. Per impostazione predefinita, gli aggiornamenti automatici per il componente aggiuntivo sono abilitati. Per disabilitare gli aggiornamenti automatici, vedi Aggiornamento dei componenti del cluster: Fluentd per la registrazione.

Posso inoltrare alcuni log, ma non altri, da una fonte del mio cluster?

Sì. Ad esempio, se hai un pod particolarmente ridondante, puoi impedire che i log di tale pod occupino spazio di archiviazione, consentendo comunque l'inoltro dei log di altri pod. Per impedire che i log di uno specifico pod vengano inoltrati, vedi Filtraggio dei log.

Inoltro dei log del cluster e delle applicazioni

Crea una configurazione per la registrazione del cluster e delle applicazioni. È possibile distinguere le diverse opzioni di registrazione utilizzando le opzioni.

La tabella riportata di seguito mostra le diverse opzioni a tua disposizione quando configuri la registrazione e le relative descrizioni.

Inoltro dei log al proprio server tramite i protocolli udp o tcp

1. Assicurarsi di disporre di Ruolo di accesso della piattaforma Editor o Amministratore IBM Cloud IAM.

2. Per il cluster in cui si trova la fonte di log: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

3. Configurare un server che accetti il protocollo syslog in uno dei due modi seguenti: : Configura e gestisci il tuo proprio server o utilizza un provider per gestirlo al tuo posto. Se un provider gestisce il server al tuo posto, richiama l'endpoint di registrazione dal provider di registrazione.

   : Esegui " syslog " da un container. Ad esempio, puoi utilizzare questo file.yaml di distribuzione per scaricare un'immagine pubblica Docker che esegue un container nel tuo cluster. L'immagine pubblica la porta 514 sull'indirizzo IP del cluster pubblico e utilizza questo indirizzo IP per configurare l'host syslog.

   È possibile visualizzare i log in formato JSON valido rimuovendo i prefissi " syslog ". Per farlo, aggiungi il seguente codice all'inizio del file etc/rsyslog.conf sul server su cui è in esecuzione rsyslog : $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. Crea una configurazione di inoltro dei log. Per ulteriori informazioni sui parametri, vedi la tabella delle opzioni di configurazione della registrazione.

   ibmcloud ks logging config create --cluster CLUSTER_NAME_OR_ID --logsource LOG_SOURCE --namespace KUBERNETES_NAMESPACE --hostname LOG_SERVER_HOSTNAME_OR_IP --port LOG_SERVER_PORT --type syslog --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS --syslog-protocol PROTOCOL
   

Inoltro dei log al proprio server tramite il protocollo tls

1. Assicurati di disporre dei seguenti ruoli IBM Cloud IAM:

   • Ruolo di accesso alla piattaforma come redattore o amministratore per il cluster
   • Ruolo di accesso al servizio " Writer " o " Manager " per lo spazio dei nomi kube-system

2. Per il cluster in cui si trova la fonte di log: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

3. Configurare un server che accetti il protocollo syslog in uno dei due modi seguenti:

   • Configura e gestisci il tuo proprio server o utilizza un provider per gestirlo al tuo posto. Se un provider gestisce il server al tuo posto, richiama l'endpoint di registrazione dal provider di registrazione.

   • Esegui " syslog " da un container. Ad esempio, puoi utilizzare questo file.yaml di distribuzione per scaricare un'immagine pubblica Docker che esegue un container nel tuo cluster. L'immagine pubblica la porta 514 sull'indirizzo IP pubblico del cluster e utilizza tale indirizzo IP pubblico del cluster per configurare l'host syslog. Devi inserire l'autorità di certificazione (CA, certificate authority) pertinente e i certificati del lato server e aggiornare il file syslog.conf per abilitare tls sul tuo server.

4. Salvare il certificato dell'autorità di certificazione in un file denominato ca-cert. Deve essere proprio quel nome.

5. Crea un segreto nello spazio dei nomi kube-system per il file ca-cert. Quando crei la configurazione di registrazione, utilizza il nome del segreto per l'opzione " --ca-cert ".

   kubectl -n kube-system create secret generic --from-file=ca-cert
   

6. Crea una configurazione di inoltro dei log. Per ulteriori informazioni sui parametri, vedi la tabella delle opzioni di configurazione della registrazione.

   ibmcloud ks logging config create --cluster <cluster name or id> --logsource <log source> --type syslog --syslog-protocol tls --hostname <ip address of syslog server> --port <port for syslog server, 514 is default> --ca-cert <secret name> --verify-mode <defaults to verify-none>
   

Filtraggio dei log inoltrati

Puoi scegliere quali log inoltrare al tuo server esterno eliminando tramite filtro specifici log per un periodo di tempo. È possibile distinguere le diverse opzioni di filtraggio utilizzando le opzioni.

1. Crea un filtro di registrazione.

   ibmcloud ks logging filter create --cluster CLUSTER_NAME_OR_ID --type LOG_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

2. Visualizza il filtro di log che hai creato.

   ibmcloud ks logging filter get --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --show-matching-configs
   

3. Aggiorna il filtro di log che hai creato.

   ibmcloud ks logging filter update --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --type SERVER_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

4. Elimina un filtro di log che hai creato.

   ibmcloud ks logging filter rm --cluster CLUSTER_NAME_OR_ID --id FILTER_ID [--all]
   

Verifica, aggiornamento ed eliminazione dell'inoltro dei log

ibmcloud ks logging config update --cluster CLUSTER_NAME_OR_ID --id LOG_CONFIG_ID --namespace NAMESPACE --type SERVER_TYPE --syslog-protocol PROTOCOL --logsource SOURCE --hostname HOSTNAME_OR_INGESTION_URL --port PORT --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS