Ich sehe keinen Hyperlink/Verbindung zwischen meinem Kubernetes Persistent Volume und dem entsprechenden Back-End Storage-Gerät. Mein Kubernetes Persistent Volume wird mit dem Hostnamen des Storage-Servers konfiguriert.

Befolgen Sie die Schritte, um den bestehenden Telegraf-Agent zu deinstallieren, und installieren Sie dann den neuesten Telegraf-Agent erneut. Sie müssen Telegraf Version 2.0 oder höher verwenden, und Ihr Kubernetes Cluster Storage muss von Cloud Insights aktiv überwacht werden.

Ich sehe Nachrichten in den Protokollen, die folgendermaßen aussehen:

E0901 15:21:39.962145 1 Reflector.go:178] k8s.io/kube-State-metrics/internal/Store/Builder.go:352: Konnte *v1.MutatingWebhookKonfiguration: Der Server konnte die angeforderte Ressource nicht finden
E0901 15:21:43.168161 1 Reflector.go:178] k8s.io/kube-State-metrics/internal/Store/Builder.go:352: Fehler beim Auflisten von *v1.Lease: Der Server konnte die angeforderte Ressource nicht finden (get Leases.Coordination.k8s.io)
Usw.

Diese Nachrichten können auftreten, wenn Sie kube-State-Metrics Version 2.0.0 oder höher mit Kubernetes-Versionen unter 1.20 ausführen.


So erhalten Sie die Kubernetes-Version:

Kubectl Version

So erhalten Sie die kube-State-metrics-Version:

Kubectl get deploy/kube-State-metrics -o jsonpath='{..image}'

Um zu verhindern, dass diese Meldungen stattfinden, können Benutzer ihre Bereitstellung von kube-State-Metrics ändern, um die folgenden Leasings zu deaktivieren:

Mutatingwebhookkonfigurationen
Validatingwebhookkonfigurationen
Volumeattachments-Ressourcen

Genauer gesagt können sie das folgende CLI-Argument verwenden:

Ressourcen=zertifiziertigningrequests,configmaps,cronjobs,demonsets, Bereitstellungen,Endpunkte,horizontalpodautoscalers,ingresses,Jobs,limitranges, Namespaces,Netzwerkrichtlinien,Nodes,persistent Volumeclaims,persistent Volumes, poddisruptionbudgets,Pods,Replikasets,Replikationcontroller,resourcequotas, Secrets,Services,Statefulsets,Storageclasses

Die Standardressourcenliste lautet:

„Zertificatezigningrequest,configmaps,cronjobs,demonsets,Bereitstellungen, Endpunkte,horizontalpodautoscalers,ingresses,Jobs,Leases,limitranges, mutatingwebhookkonfigurationen,Namespaces,Netzwerkrichtlinien,Nodes,persistent Volumeclaims,persistent,Volumes,poddisruptionbudgets,Pods,Replikasets,resourcequotas,Secrets,Services,statectorSets,statectoresets Validatingwebhookkonfigurationen, Volumeanhänge“

Ich sehe Fehlermeldungen von Telegraf wie die folgenden, aber Telegraf startet und läuft:

Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: Startete den Plugin-gesteuerten Server-Agent für die Berichterstattung von Kennzahlen in InfluxDB.
Okt 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time=„2021-10-11T14:23:41Z“ Level=error msg=„konnte kein Cache-Verzeichnis erstellen. /Etc/telegraf/.Cache/snowflake, err: Mkdir /etc/telegraf/.ca
Che: Erlaubnis verweigert. Ignored\n“ func=„gosnowflake.(*defaultLogger).Errorf“ file=„log.go:120“
Okt. 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time=„2021-10-11T14:23:41Z“ Level=error msg=„Öffnen fehlgeschlagen. Ignoriert. Open /etc/telegraf/.Cache/snowflake/ocsp_response_Cache.json: Nicht so
Datei oder Verzeichnis\n“ func=„gosnowflake.(*defaultLogger).Errorf“ file=„log.go:120“
Okt. 11 14:23:41 ip-172-31-39-47 telegraf[1827]: 2021-10-11T14:23:41Z i! Telegraf 1.19.3 Starten

Dies ist ein bekanntes Problem. Siehe "Dieser GitHub-Artikel" Entnehmen. Solange Telegraf läuft, können Benutzer diese Fehlermeldungen ignorieren.

Auf Kubernetes berichten meine Telegraf POD(s) die folgende Fehlermeldung:
"Fehler bei der Verarbeitung von mountstats-Info: Mountstats-Datei konnte nicht geöffnet werden: /Hostfs/proc/1/mountstats, Fehler: Open /hostfs/proc/1/mountstats: Berechtigung verweigert"

Wenn SELinux aktiviert und durchgesetzt wird, wird wahrscheinlich verhindert, dass die Telegraf PODs auf die Datei /proc/1/mountstats auf dem Kubernetes-Knoten zugreifen. Um diese Einschränkung zu überwinden, bearbeiten Sie die Agentkonfiguration und aktivieren Sie die runPrivileged-Einstellung. Weitere Informationen finden Sie im "OpenShift-Anweisungen".

Auf Kubernetes meldet mein Telegraf ReplicaSet POD den folgenden Fehler:

[inputs.prometheus] Fehler im Plugin: Konnte keypair /etc/kubernetes/pki/etcd/Server.crt:/etc/kubernetes/pki/etcd/Server.key nicht laden: Öffnen /etc/kubernetes/pki/etcd/Server.crt: Datei oder Verzeichnis nicht vorhanden

Der Pod Telegraf ReplicaSet soll auf einem Knoten ausgeführt werden, der als Master oder für etc bestimmt ist. Wenn der ReplicaSet-Pod auf einem dieser Knoten nicht ausgeführt wird, werden diese Fehler angezeigt. Überprüfen Sie, ob Ihre Master/etcd-Knoten eine Tönungswalle haben. Fügen Sie in diesem Fall die erforderlichen Verträgungen in das Telegraf ReplicaSet, telegraf-rs ein.

Bearbeiten Sie beispielsweise das ReplicaSet…​

Kubectl bearbeiten rs telegraf-rs

…​Und fügen Sie die entsprechenden Toleranzen in die Spezifikation ein. Starten Sie anschließend den Pod ReplicaSet neu.

Ich habe eine PSP/PSA Umgebung. Hat dies Auswirkungen auf meinen Überwachungsperator?

Wenn Ihr Kubernetes-Cluster mit Pod-Sicherheitsrichtlinie (PSP) oder Pod Security Admission (PSA) ausgeführt wird, müssen Sie ein Upgrade auf den aktuellen Kubernetes Monitoring Operator durchführen. Führen Sie die folgenden Schritte aus, um auf den aktuellen Bediener mit Unterstützung für PSP/PSA zu aktualisieren:

1. Deinstallieren Der vorherige Überwachungsoperator:

Kubectl delete Agent-Monitoring-netapp -n netapp-Monitoring
Kubectl löschen ns netapp-Monitoring
Kubectl löschen crd agents.monitoring.netapp.com
Kubectl delete clusterrole Agent-Manager-role Agent-Proxy-role Agent-metrics-reader
Kubectl delete clusterrolebinding Agent-Manager-rolebinding Agent-Proxy-rolebinding Agent-Cluster-admin-rolebinding

2. Installieren Die neueste Version des Überwachungsbedieners.

Ich habe Probleme beim Versuch, den Operator bereitzustellen, und ich habe PSP/PSA in Gebrauch.

1. Bearbeiten Sie den Agenten mit dem folgenden Befehl:

Kubectl -n <name-space>-Bearbeitungsagent

2. Markieren Sie "Sicherheit-Politik-aktiviert" als "falsch". Dadurch werden Pod-Sicherheitsrichtlinien und Pod-Sicherheitszulassung deaktiviert und der Bediener kann die Bereitstellung durchführen. Bestätigen Sie die Bestätigung mit folgenden Befehlen:

Kubectl get psp (sollte zeigen, dass die Pod-Sicherheitsrichtlinie entfernt wurde)
Kubectl get all -n <namespace> (sollte zeigen, dass nichts gefunden wird)

„ImagePullBackoff“-Fehler erkannt

Diese Fehler können auftreten, wenn Sie über ein benutzerdefiniertes oder privates Docker-Repository verfügen und den Kubernetes Monitoring Operator noch nicht so konfiguriert haben, dass er es richtig erkennt. Weitere Informationen Info zur Konfiguration für benutzerdefinierte/private Repo.

Ich habe ein Problem mit der Installation meines Monitoring-Bedieners, und die aktuelle Dokumentation hilft mir nicht, es zu lösen.

NET-Observer (Workload Map)-Pods im Operator Namespace befinden sich in CrashLoopBackOff

Diese Pods entsprechen dem Workload Map-Datensammler für Network Observability. Versuchen Sie Folgendes:
• Überprüfen Sie die Protokolle eines der Pods, um die minimale Kernel-Version zu bestätigen. Beispiel:

----
{„CI-Tenant-id“:„your-Tenant-id“,„Collector-Cluster“:„your-k8s-Cluster-Name“,„environment“:„prod“,„Level“:„error“,„msg“:„failed in validation. Grund: Kernelversion 3.10.0 ist kleiner als die minimale Kernelversion von 4.18.0","Time":"2022-11-09T08:23:08Z"}
----

• Net-Observer PODs benötigen die Linux Kernel Version mindestens 4.18.0. Überprüfen Sie die Kernel-Version mit dem Befehl „uname -r“ und stellen Sie sicher, dass sie >= 4.18.0 sind

Pods werden im Operator Namespace ausgeführt (Standard: netapp-Monitoring), es werden jedoch keine Daten in der UI für die Workload-Zuordnung oder Kubernetes-Metriken in Abfragen angezeigt

Überprüfen Sie die Zeiteinstellung auf den Knoten des K8S-Clusters. Für eine genaue Prüfung und Datenberichterstattung wird dringend empfohlen, die Zeit auf dem Agent-Rechner mit Network Time Protocol (NTP) oder Simple Network Time Protocol (SNTP) zu synchronisieren.

Einige der Net-Observer-Pods im Namespace Operator befinden sich im Status „Ausstehend“

NET-Observer ist ein DemonSet und führt in jedem Knoten des K8s-Clusters einen Pod aus.
• Beachten Sie den Pod, der sich im Status „Ausstehend“ befindet, und prüfen Sie, ob ein Ressourcenproblem für CPU oder Speicher vorliegt. Stellen Sie sicher, dass der erforderliche Arbeitsspeicher und die erforderliche CPU im Knoten verfügbar sind.

Ich sehe Folgendes in meinen Protokollen sofort nach der Installation des Kubernetes Monitoring Operator:

[inputs.prometheus] Fehler im Plugin: Fehler beim Erstellen einer HTTP-Anforderung an http://kube-state-metrics.<namespace>.svc.Cluster.local:8080/metrics: Get http://kube-state-metrics.<namespace>.svc.Cluster.local:8080/metrics: Dial tcp: Lookup kube-State-metrics.<namespace>.svc.Cluster.local: Kein solcher Host

Diese Meldung wird normalerweise nur angezeigt, wenn ein neuer Operator installiert ist und der Pod „telegraf-rs“ vor dem Einschalten des Pod „ksm“ steht. Diese Meldungen sollten beendet werden, sobald alle Pods ausgeführt werden.

Ich sehe keine Kennzahlen für die Kubernetes-Kronjobs, die in meinem Cluster vorhanden sind, erfasst.

Überprüfen Ihrer Kubernetes Version (d. h. kubectl version). Wenn es v1.20.x oder niedriger ist, ist dies eine erwartete Einschränkung. Die mit dem Kubernetes Monitoring Operator implementierte Version von kube-State-Metrics unterstützt nur v1.cronjob. Bei Kubernetes 1.20.x und niedriger befindet sich die Ressource cronjob unter v1beta.cronjob. Daher können kube-State-Metriken die Ressource cronjob nicht finden.

Nach der Installation des Bedieners geben die telegraf-ds-Pods CrashLoopBackOff ein und die POD-Protokolle zeigen „su: Authentication failure“ an.

Bearbeiten Sie den Abschnitt telegraf in AgentConfiguration, und setzen Sie dockerMetricCollectionEnabled auf false. Weitere Informationen finden Sie im Abschnitt des Bedieners "Konfigurationsoptionen".

HINWEIS: wenn Sie die Cloud Insights Federal Edition verwenden, können Benutzer mit Einschränkungen hinsichtlich der Verwendung von su keine Docker-Metriken erfassen, da der Zugriff auf den Dockersockel entweder den telegraf-Container als root ausführen muss oder su verwenden muss, um den telegraf-Benutzer zur Docker-Gruppe hinzuzufügen. Die Docker Metric Collection und die Verwendung von su sind standardmäßig aktiviert. Um beides zu deaktivieren, entfernen Sie den Eintrag telegraf.Docker in der Datei AgentConfiguration:

…​
Spez.:
…​
telegraf:
…​
     - Name: docker
            Run-Modus:
              - DemonSet
            Ersetzungen:
              - SCHLÜSSEL: DOCKER_UNIX_SOCK_PLACEHOLDER
                Wert: unix:///run/Docker.Sock
…​
…​

Ich sehe wiederholte Fehlermeldungen wie die folgenden in meinen Telegraf-Protokollen:

E! [Agent] Fehler beim Schreiben in Outputs.http: Post "https://<tenant_url>/Rest/v1/Lake/ingest/influxdb": Kontext-Deadline überschritten (Client. Zeitüberschreitung beim Warten auf Header überschritten)

Bearbeiten Sie den Abschnitt telegraf in AgentConfiguration, und erhöhen Sie outputTimeout auf 10s. Weitere Informationen finden Sie im Abschnitt des Bedieners "Konfigurationsoptionen".

Ich vermisse involvedobject Daten für einige Event Logs.

Stellen Sie sicher, dass Sie die Schritte im befolgt haben "Berechtigungen" Abschnitt oben.

Wieso werden zwei Monitoring Operator Pods ausgeführt, einer mit dem Namen netapp-CI-Monitoring-Operator-<pod> und der andere mit dem Namen Monitoring-Operator-<pod>?

Ab dem 12. Oktober 2023 hat Cloud Insights den Betreiber refaktorisiert, um unseren Nutzern besser zu dienen. Damit diese Änderungen vollständig übernommen werden, müssen Sie dies tun Entfernen Sie den alten Bediener Und Installieren Sie den neuen.

Meine kubernetes-Ereignisse berichteten unerwartet nicht mehr an Cloud Insights.

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
Es sollte entweder „netapp-CI-Event-Exporteur“ oder „Event-Exporteur“ sein. Bearbeiten Sie anschließend den Monitoring-Agent kubectl -n netapp-monitoring edit agent, Und legen Sie den Wert für LOG_FILE so fest, dass der entsprechende POD-Name für den Event-Exporter im vorherigen Schritt angezeigt wird. Genauer gesagt sollte LOG_FILE auf "/var/log/Containers/netapp-CI-Event-exporteur.log" oder "/var/log/Containers/Event-exporteur*.log" gesetzt werden

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter*.log
…​
…​.
Alternativ kann man auch Deinstallieren Und Neu installieren Der Agent.

Ich sehe POD(s), die vom Kubernetes-Monitoring-Operator bereitgestellt werden, aufgrund unzureichender Ressourcen.

Weitere Informationen finden Sie im Kubernetes Monitoring Operator "Konfigurationsoptionen" Um die CPU- und/oder Speichergrenzen je nach Bedarf zu erhöhen.

Durch ein fehlendes Image oder eine ungültige Konfiguration wurden die netapp-CI-kube-State-metrics Pods nicht gestartet oder nicht einsatzbereit gemacht. Jetzt bleibt StatefulSet stecken und Konfigurationsänderungen werden nicht auf die Pods mit den netapp-CI-kube-State-Metriken angewendet.

Das StatefulSet befindet sich in A "Defekt" Bundesland. Nachdem Sie Konfigurationsprobleme behoben haben, springen die netapp-CI-kube-State-metrics-Pods an.

Pods mit netapp-CI-kube-Status-Metriken können nicht gestartet werden, nachdem ein Kubernetes Operator Upgrade ausgeführt wurde. Es wird ErrImagePull geworfen (es konnte nicht das Image entfernt werden).

Versuchen Sie, die Pods manuell zurückzusetzen.

„Event disorded as being alder then maxEventAgeSeconds“ Meldungen werden für meinen Kubernetes Cluster unter Log Analysis beobachtet.

Ändern Sie den Operator agentkonfiguration, und erhöhen Sie die Erweiterung Event-exporteur-maxEventAgeSeconds (d. h. auf 60s), Event-exporteur-kubeQPS (d. h. auf 100) und Event-exporteur-kubeBurst (d. h. auf 500). Weitere Informationen zu diesen Konfigurationsoptionen finden Sie im "Konfigurationsoptionen" Seite.

Telegraf warnt vor unzureichenden, abschließbaren Speichern oder stürzt ab.