Entfernen der Beobachtbarkeits-Plug-in-Agenten

• Wenn der Support für ob plugin endet, müssen Sie jede Komponente einzeln löschen.

  1. Bereinigen Sie die Daemonsets und 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. Optional: Löschen Sie den Namespace. Nachdem keine anderen Ressourcen im Namensraum ausgeführt werden.
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

Nachdem das Plug-in entfernt wurde, installieren Sie die Logging- und Monitoring-Agenten in Ihrem Cluster erneut – entweder über das Cluster-Dashboard, mit Terraform oder manuell.

Weitere Informationen erhalten Sie nach Auswahl der folgenden Links.

• Senden von IBM Cloud Kubernetes Service Protokolldaten an IBM Cloud Logs
• Kubernetes-Cluster überwachen

Erläuterungen zur Protokollweiterleitung an einen externen Server

Wenn Sie eine Protokollierungskonfiguration für eine Quelle in Ihrem Cluster erstellen, um Daten an einen externen Server weiterzuleiten, wird eine Fluentd wird in Ihrem Cluster eine Komponente erstellt. Fluentd erfasst die Protokolle aus den Pfaden dieser Quelle und leitet die Protokolle an einen externen Server weiter. Der Datenverkehr von der Quelle an den Protokollierungsservice am Einpflegeport wird verschlüsselt.

Für welche Quellen kann ich die Protokollweiterleitung konfigurieren?

In der folgenden Abbildung sehen Sie den Bereich der Quellen, für die Sie die Protokollierung konfigurieren können.

1. worker: Informationen, die für die Infrastrukturkonfiguration spezifisch sind, die Sie für Ihren Workerknoten konfiguriert haben. Die Mitarbeiterprotokolle werden in „ syslog “ erfasst und enthalten Betriebssystemereignisse. In der Datei auth.log finden Sie Informationen zu den Authentifizierungsanforderungen, die an das Betriebssystem gestellt werden.

   Pfade

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

2. container: Informationen, die von einem laufenden Container protokolliert werden. Pfade: Alles, was in die Dateien „ STDOUT “ oder „ STDERR “ geschrieben wird.

3. application: Informationen zu Ereignissen, die auf Anwendungsebene auftreten. Dies kann eine Benachrichtigung über ein Ereignis sein, beispielsweise eine erfolgreiche Anmeldung, eine Warnung bezüglich des Speicherplatzes oder andere Vorgänge, die auf App-Ebene durchgeführt werden können. Pfade: Sie können die Pfade festlegen, an die Ihre Protokolle weitergeleitet werden sollen. Damit Protokolle gesendet werden, müssen Sie jedoch einen absoluten Pfad in Ihrer Protokollierungskonfiguration angeben. Andernfalls können die Protokolle nicht gelesen werden. Falls Ihr Verzeichnis auf Ihrem Worker-Knoten eingebunden ist, wurde möglicherweise ein symbolischer Link erstellt. Beispiel: Wenn der angegebene Pfad „ /usr/local/spark/work/app-0546/0/stderr “ lautet, die Protokolle jedoch tatsächlich unter „ /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr “ gespeichert werden, können die Protokolle nicht gelesen werden.

4. storage: Informationen zum persistenten Speicher, der in Ihrem Cluster konfiguriert ist. Mit Hilfe von Speicherprotokollen können Sie Problembestimmungsdashboards und Alerts als Teil Ihrer DevOps-Pipeline und der Produktionsreleases konfigurieren. Hinweis: Die Pfade /var/log/kubelet.log und /var/log/syslog enthalten ebenfalls Speicherprotokolle, aber diese Protokolle werden von den Protokollquellen kubernetes und worker gesammelt.

   Pfade

   /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: Informationen von 'kubelet', 'kube-proxy' und anderen Kubernetes-Ereignissen, die im Namensbereich 'kube-system' auftreten können.

   Pfade

   /var/log/kubelet.log

   /var/log/kube-proxy.log

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

6. ingress: Informationen zum Netzdatenverkehr, der über die Ingress-ALB in einen Cluster eingeht.

   Pfade

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

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

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

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

7. kube-audit: Informationen zu clusterbezogenen Aktionen, die an den Kubernetes-API-Server gesendet werden, einschließlich der Zeit, des Benutzers und der betroffenen Ressource. Die kube-audit-Quelle kann mit einem Webhook konfiguriert werden. Weitere Informationen finden Sie in Prüfprotokolle der Kubernetes-API an einen externen Server weiterleiten.

Bin ich dafür verantwortlich, Fluentd auf dem neuesten Stand zu halten?

Zum Ändern Ihrer Protokollierungs- oder Filterkonfiguration muss die Fluentd-Protokollierungskomponente die neueste Version aufweisen. Standardmäßig sind automatische Aktualisierungen für das Add-on aktiviert. Informationen zum Inaktivieren automatischer Aktualisierungen finden Sie im Abschnitt Clusterkomponenten aktualisieren; Fluentd für die Protokollierung.

Kann ich bestimmte Protokolle aus einer Quelle in meinem Cluster weiterleiten, andere jedoch nicht?

Ja. Wenn Sie zum Beispiel einen besonders datenintensiven Pod haben, kann es wünschenswert sein, zu verhindern, dass Protokolle aus diesem Pod Protokollspeicherplatz belegen, und gleichzeitig die Weiterleitung von Protokollen anderer Pods weiterhin zuzulassen. Informationen dazu, wie die Weiterleitung eines bestimmten Pods verhindert wird, finden Sie unter Protokolle filtern.

Weiterleitung von Cluster- und App-Protokollen

Erstellen Sie eine Konfiguration für die Cluster- und App-Protokollierung. Mithilfe der Optionen können Sie zwischen den verschiedenen Protokollierungsoptionen unterscheiden.

In der folgenden Tabelle sind die verschiedenen Optionen aufgeführt, die Ihnen bei der Konfiguration der Protokollierung und ihrer Beschreibungen zur Verfügung stehen.

Protokolle an Ihren eigenen Server über die Protokolle udp oder tcp weiterleiten

1. Stellen Sie sicher, dass Sie über die Zugriffsrolle „Editor“ oder „Administrator“ IBM Cloud auf der IAM-Plattform verfügen.

2. Für den Cluster, in dem sich die Protokollquelle befindet: Melden Sie sich bei Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

3. Richten Sie einen Server ein, der das „ syslog “-Protokoll auf eine von zwei Arten akzeptiert: : Richten Sie einen eigenen Server ein und verwalten Sie diesen oder lassen Sie diese Aufgaben von einem Provider durchführen. Wenn ein Provider den Server für Sie verwaltet, dann rufen Sie den Protokollierungsendpunkt vom Protokollierungsprovider ab.

   : Führen Sie „ syslog “ in einem Container aus. Sie können beispielsweise diese .yaml-Datei für die Bereitstellung verwenden, um ein öffentliches Image von Docker abzurufen, mit dem ein Container in Ihrem Cluster ausgeführt wird. Das Image veröffentlicht den Port 514 auf der öffentlichen Cluster-IP-Adresse und verwendet diese öffentliche Cluster-IP-Adresse zum Konfigurieren des Systemprotokollhosts.

   Sie können Ihre Protokolle als gültiges JSON anzeigen, indem Sie die Präfixe „ syslog “ entfernen. Fügen Sie dazu den folgenden Code am Anfang Ihrer Datei „ etc/rsyslog.conf “ ein, auf dem Ihr Server „ rsyslog “ läuft: $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. Konfiguration für die Protokollweiterleitung erstellen. Weitere Informationen zu den Parametern finden Sie in der Tabelle mit den Konfigurationsoptionen für die Protokollierung.

   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
   

Protokolle auf Ihrem eigenen Server über das Protokoll tls weiterleiten

1. Stellen Sie sicher, dass Sie die folgenden IBM Cloud IAM-Rollen innehaben:

   • Plattformzugriffsrolle Editor oder Administrator für den Cluster
   • Servicezugriffsrolle Schreibberechtigter oder Manager für den Namensbereich kube-system

2. Für den Cluster, in dem sich die Protokollquelle befindet: Melden Sie sich bei Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

3. Richten Sie einen Server ein, der das „ syslog “-Protokoll auf eine von zwei Arten akzeptiert:

   • Richten Sie einen eigenen Server ein und verwalten Sie diesen oder lassen Sie diese Aufgaben von einem Provider durchführen. Wenn ein Provider den Server für Sie verwaltet, dann rufen Sie den Protokollierungsendpunkt vom Protokollierungsprovider ab.

   • Führen Sie „ syslog “ in einem Container aus. Sie können beispielsweise diese .yaml-Datei für die Bereitstellung verwenden, um ein öffentliches Image von Docker abzurufen, mit dem ein Container in Ihrem Cluster ausgeführt wird. Das Image veröffentlicht den Port 514 unter der öffentlichen Cluster-IP-Adresse und verwendet diese öffentliche Cluster-IP-Adresse zur Konfiguration des Hosts syslog. Sie müssen die entsprechenden Zertifikate einer Zertifizierungsstelle und serverseitigen Zertifikate einfügen und die Datei syslog.conf aktualisieren, damit tls auf Ihrem Server aktiviert werden kann.

4. Speichern Sie das Zertifikat Ihrer Zertifizierungsstelle in einer Datei mit dem Namen ca-cert. Es muss genau dieser Name sein.

5. Erstellen Sie im Namensbereich kube-system einen geheimen Schlüssel für die Datei ca-cert. Verwenden Sie bei der Erstellung Ihrer Protokollierungskonfiguration den Secret-Namen für die Option „ --ca-cert “.

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

6. Konfiguration für die Protokollweiterleitung erstellen. Weitere Informationen zu den Parametern finden Sie in der Tabelle mit den Konfigurationsoptionen für die Protokollierung.

   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>
   

Weitergeleitete Protokolle filtern

Sie können auswählen, welche Protokolle an den externen Server weitergeleitet werden, indem Sie bestimmte Protokolle für einen bestimmten Zeitraum herausfiltern. Mithilfe der Optionen können Sie zwischen den verschiedenen Filteroptionen unterscheiden.

1. Erstellen Sie einen Protokollierungsfilter.

   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. Zeigen Sie die erstellten Protokollfilter an.

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

3. Aktualisieren Sie den erstellten Protokollfilter.

   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. Löschen Sie einen erstellten Protokollfilter.

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

Protokollweiterleitung überprüfen, aktualisieren und löschen

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