Suppression des agents du plug-in d'observabilité

• Lorsque l'assistance pour le site ob plugin prend fin, vous devez supprimer chaque composant individuellement.

  1. Nettoyer les daemonsets et les configmaps.

      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. Optionnel : Supprimer l'espace de noms. Si aucune autre ressource n'est en cours d'exécution dans l'espace de noms.
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

Une fois le plug-in supprimé, réinstallez les agents de journalisation et de surveillance dans votre cluster à l'aide du tableau de bord du cluster, de Terraform ou manuellement.

Pour plus d'informations, voir les liens suivants :

• Envoi des données de IBM Cloud Kubernetes Service à IBM Cloud Logs
• Surveillance d'un cluster Kubernetes

Description de l'acheminement des journaux vers un serveur externe

Lorsque vous créez une configuration de journalisation pour une source de votre cluster afin de transférer les données vers un serveur externe, un Fluentd composant est créé dans votre cluster. Fluentd collecte les journaux à partir des chemins de cette source et les transmet à un serveur externe. Le trafic provenant de cette source destiné au service de journalisation sur le port d'ingestion est chiffré.

Pour quelles sources puis-je configurer le transfert des journaux?

Sur l'image ci-dessous, vous pouvez voir la zone correspondant aux sources pour lesquelles vous pouvez configurer la journalisation.

1. worker : informations spécifiques à la configuration de l'infrastructure dont vous disposez pour votre noeud worker. Les journaux des utilisateurs sont enregistrés dans syslog et contiennent les événements du système d'exploitation. Dans auth.log vous pouvez trouver des informations sur les demandes d'authentification effectuées après du système d'exploitation.

   Chemins

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

2. container: Informations enregistrées par un conteneur en cours d'exécution. Chemins d'accès: tout ce qui est écrit dans les fichiers STDOUT ou STDERR.

3. application : informations sur les événements qui se produisent au niveau de l'application. Il peut s'agir d'une notification signalant qu'un événement s'est produit, comme une connexion réussie, d'un avertissement concernant l'espace de stockage ou d'autres opérations pouvant être effectuées au niveau de l'application. Chemins d'accès: vous pouvez définir les chemins d'accès vers lesquels vos journaux sont transférés. Cependant, pour que les journaux soient envoyés, vous devez utiliser un chemin d'accès absolu dans votre configuration de journalisation pour que les journaux ne puissent être lus. Si votre répertoire est monté sur votre nœud de travail, il se peut qu'un lien symbolique ait été créé. Exemple : si le chemin indiqué est /usr/local/spark/work/app-0546/0/stderr mais que les fichiers journaux sont en réalité stockés à l'adresse /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr, ceux-ci ne pourront pas être lus.

4. storage : informations sur le stockage persistant configuré dans votre cluster. Les journaux de stockage peuvent vous aider à configurer des tableaux de bord et des alertes pour identifier les problèmes, dans le cadre des éditions de production et pipeline DevOps. Remarque : les chemins /var/log/kubelet.log et /var/log/syslog contiennent également des journaux de stockage, mais les journaux de ces chemins sont collectés par les sources de journal kubernetes et worker.

   Chemins

   /var/log/ibmc-s3fs.log

   /var/log/ibmc-block.log

   Pods

   portworx-***

   ibmcloud-block-storage-attacher-***

   ibmcloud-block-storage-driver-***

   ibmcloud-block-storage-plugin-***

   ibmcloud-object-storage-plugin-***

5. kubernetes : informations de kubelet, kube-proxy et en provenance d'autres événements Kubernetes qui se produisent dans l'espace de noms kube-system du noeud worker.

   Chemins

   /var/log/kubelet.log

   /var/log/kube-proxy.log

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

6. ingress : informations sur le trafic réseau qui arrive dans un cluster via l'équilibreur de charge d'application Ingress.

   Chemins

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

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

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

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

7. kube-audit : informations sur les actions associées au cluster qui sont envoyées au serveur d'API Kubernetes, notamment la date et l'heure, l'utilisateur et la ressource concernée. La source kube-audit peut être configurée avec un webhook. Pour plus d'informations, voir Transmission des journaux d'audit d'API Kubernetes à un serveur externe.

Est-ce à moi de veiller à ce que le site Fluentd soit mis à jour?

Pour modifier vos configurations de journalisation ou de filtre, le composant de journalisation Fluentd doit correspondre à la dernière version. Par défaut, les mises à jour automatiques de ce module sont activées. Pour désactiver les mises à jour automatiques, voir Mise à jour de composants de cluster : Fluentd pour la journalisation.

Puis-je transférer certains fichiers journaux, mais pas d'autres, à partir d'une source de mon cluster?

Oui. Si vous avez, par exemple, un pod particulièrement bavard, vous éviterez d'allouer de l'espace de stockage aux journaux de ce pod, tout en autorisant l'acheminement de journaux d'autres pods. Pour empêcher l'acheminement des journaux d'un pod particulier, voir Filtrage des journaux.

Acheminement des journaux de cluster et d'application

Créez une configuration pour la journalisation de cluster et d'application. Vous pouvez distinguer les différentes options de journalisation à l'aide des options.

Le tableau suivant présente les différentes options dont vous disposez lorsque vous configurez la journalisation, ainsi que leur description.

Acheminement des journaux vers votre propre serveur via les protocoles udp ou tcp

1. Assurez-vous de disposer de l'Rédacteur en chef ou le rôle d'accès à la plateforme IAM d' Administrateur IBM Cloud.

2. Pour le cluster où se trouve la source de journal : connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

3. Configurez un serveur prenant en charge le protocole syslog de l'une des deux manières suivantes : : Configurez et gérez votre propre serveur ou confiez la gestion du serveur à un fournisseur. Dans ce cas, obtenez le noeud final de journalisation du fournisseur de journalisation.

   : Exécutez « syslog » à partir d'un conteneur. Par exemple, vous pouvez utiliser ce fichier.yaml de déploiement pour récupérer une image publique Docker qui exécute un conteneur dans votre cluster. L'image publie le port 514 sur l'adresse IP du cluster public et utilise cette adresse pour configurer l'hôte syslog.

   Vous pouvez consulter vos journaux au format JSON valide en supprimant les préfixes « syslog ». Pour ce faire, ajoutez le code suivant au début de votre fichier etc/rsyslog.conf sur le serveur où s'exécute votre application rsyslog : $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. Créer une configuration d'acheminement des journaux. Pour plus d'informations sur les paramètres, voir Description des options de configuration de journalisation.

   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
   

Acheminement des journaux vers votre propre serveur via le protocole tls

1. Vérifiez que vous disposez des rôles IBM Cloud IAM suivants :

   • Rôle d'accès à la plateforme Editeur ou Administrateur pour le cluster
   • Rôle d'accès au service Auteur ou Responsable pour l'espace de noms kube-system

2. Pour le cluster où se trouve la source de journal : connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

3. Configurez un serveur prenant en charge le protocole syslog de l'une des deux manières suivantes :

   • Configurez et gérez votre propre serveur ou confiez la gestion du serveur à un fournisseur. Dans ce cas, obtenez le noeud final de journalisation du fournisseur de journalisation.

   • Exécutez « syslog » à partir d'un conteneur. Par exemple, vous pouvez utiliser ce fichier.yaml de déploiement pour récupérer une image publique Docker qui exécute un conteneur dans votre cluster. L'image publie le port 514 sur l'adresse IP publique du cluster et utilise cette adresse IP publique du cluster pour configurer l'hôte syslog. Vous devez injecter les certificats de l'autorité de certification et les certificats côté serveur appropriés et mettre à jour le fichier syslog.conf pour activer tls sur votre serveur.

4. Enregistrez votre certificat d'autorité de certification dans un fichier nommé ca-cert. Ce nom doit exactement celui-ci.

5. Créez un secret dans l'espace de noms kube-system pour le fichier ca-cert. Lorsque vous créez votre configuration de journalisation, utilisez le nom du secret pour l'option « --ca-cert ».

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

6. Créer une configuration d'acheminement des journaux. Pour plus d'informations sur les paramètres, voir Description des options de configuration de journalisation.

   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>
   

Filtrage des journaux qui sont acheminés

Vous pouvez déterminer les journaux que vous allez acheminer en filtrant des journaux spécifiques sur une période donnée. Vous pouvez distinguer les différentes options de filtrage à l'aide des options.

1. Créez un filtre de journalisation.

   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. Affichez le filtre de journal que vous avez créé.

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

3. Mettez à jour le filtre de journal que vous avez créé.

   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. Supprimez un filtre de journal que vous avez créé.

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

Vérification, mise à jour et suppression de l'acheminement des journaux

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