Skip to main content
Cloud Insights
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Installation und Konfiguration des Kubernetes Monitoring Operator

Beitragende

Cloud Insights bietet die Kubernetes Monitoring Operator für Kubernetes an. Navigieren Sie zu Kubernetes > Collectors > +Kubernetes Collector, um einen neuen Operator bereitzustellen.

Bevor Sie den Kubernetes Monitoring Operator installieren

Siehe "Voraussetzungen" Dokumentation vor der Installation oder dem Upgrade des Kubernetes Monitoring Operator.

Installieren des Kubernetes Monitoring Operator

Anweisungen Für Den Bediener Der Überwachung
Anweisungen Für Den Bediener Der Überwachung

Schritte zum Installieren des Kubernetes Monitoring Operator Agent auf Kubernetes:
  1. Geben Sie einen eindeutigen Cluster-Namen und einen eindeutigen Namespace ein. Wenn Sie es sind Aktualisierung Verwenden Sie aus einem früheren Kubernetes-Operator den gleichen Cluster-Namen und Namespace.

  2. Sobald diese eingegeben wurden, können Sie den Download-Befehl-Snippet in die Zwischenablage kopieren.

  3. Fügen Sie das Snippet in ein bash Fenster ein und führen Sie es aus. Die Installationsdateien des Bedieners werden heruntergeladen. Beachten Sie, dass das Snippet einen eindeutigen Schlüssel hat und für 24 Stunden gültig ist.

  4. Wenn Sie ein benutzerdefiniertes oder privates Repository haben, kopieren Sie das optionale Bild-Pull-Snippet, fügen Sie es in eine bash-Shell ein und führen Sie es aus. Nachdem die Bilder gezogen wurden, kopieren Sie sie in Ihr privates Repository. Stellen Sie sicher, dass Sie dieselben Tags und Ordnerstrukturen beibehalten. Aktualisieren Sie die Pfade in Operator-Deployment.yaml sowie die Einstellungen des Docker-Repository in Operator-config.yaml.

  5. Prüfen Sie bei Bedarf die verfügbaren Konfigurationsoptionen, z. B. Proxy- oder private Repository-Einstellungen. Sie können mehr über lesen "Konfigurationsoptionen".

  6. Wenn Sie bereit sind, stellen Sie den Operator bereit, indem Sie den kubectl Apply-Snippet kopieren, herunterladen und ausführen.

  7. Die Installation wird automatisch ausgeführt. Klicken Sie anschließend auf die Schaltfläche „Next“.

  8. Wenn die Installation abgeschlossen ist, klicken Sie auf die Schaltfläche „Next“. Achten Sie darauf, auch die Datei Operator-Secrets.yaml zu löschen oder sicher zu speichern.

Wenn Sie einen Proxy verwenden, lesen Sie mehr über Proxy wird konfiguriert.

Wenn Sie über ein benutzerdefiniertes Repository verfügen, lesen Sie mehr über Ein benutzerdefiniertes/privates Docker-Repository verwenden.

Kubernetes-Monitoring-Komponenten

Cloud Insights-Kubernetes-Monitoring besteht aus vier Monitoring-Komponenten:

  • Cluster-Kennzahlen

  • Netzwerkleistung und -Zuordnung (optional)

  • Ereignisprotokolle (optional)

  • Änderungsanalyse (optional)

Die oben aufgeführten optionalen Komponenten sind standardmäßig für jeden Kubernetes-Collector aktiviert. Wenn Sie sich entscheiden, keine Komponente für einen bestimmten Collector zu benötigen, können Sie sie deaktivieren, indem Sie zu Kubernetes > Collectors navigieren und im Collector-Menü „drei Punkte“ rechts auf dem Bildschirm Modify Deployment auswählen.

Ändern Sie das Bereitstellungsmenü auf der Listenseite Kubernetes Collector

Der Bildschirm zeigt den aktuellen Status jeder Komponente an und ermöglicht es Ihnen, Komponenten für diesen Collector nach Bedarf zu deaktivieren oder zu aktivieren.

Mody-Bereitstellungsoptionen, 700

Aktualisierung

Upgrade auf den neuesten Kubernetes Monitoring Operator

Ermitteln Sie, ob eine AgentConfiguration bei dem vorhandenen Operator vorhanden ist (wenn Ihr Namespace nicht der Standardwert netapp-Monitoring ist, ersetzen Sie den entsprechenden Namespace):

 kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration
Wenn eine AgentConfiguration vorhanden ist:

Wenn AgentConfiguration nicht vorhanden ist:

  • Notieren Sie sich den von Cloud Insights erkannten Cluster-Namen (wenn Ihr Namespace nicht der standardmäßige netapp-Monitoring ist, ersetzen Sie den entsprechenden Namespace):

     kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'
    * Erstellen Sie eine Sicherung des bestehenden Operators (wenn Ihr Namespace nicht der Standard-netapp-Überwachung ist, ersetzen Sie den entsprechenden Namespace):
     kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml
    * <<to-remove-the-kubernetes-monitoring-operator,Deinstallieren>> Der vorhandene Operator.
    * <<installing-the-kubernetes-monitoring-operator,Installieren>> Der neueste Operator.
    • Verwenden Sie denselben Cluster-Namen.

    • Nachdem Sie die neuesten Operator YAML-Dateien heruntergeladen haben, können Sie alle in Agent_Backup.yaml gefundenen Anpassungen vor der Bereitstellung an den heruntergeladenen Operator-config.yaml übertragen.

    • Stellen Sie sicher, dass Sie es sind Die neuesten Container-Bilder werden angezeigt Wenn Sie ein benutzerdefiniertes Repository verwenden.

Anhalten und Starten des Kubernetes Monitoring Operator

So beenden Sie den Kubernetes Monitoring Operator:

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
So starten Sie den Kubernetes Monitoring Operator:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1

Deinstallation

Um den Kubernetes Monitoring Operator zu entfernen

Beachten Sie, dass der Standard-Namespace für den Kubernetes Monitoring Operator „netapp-Monitoring“ ist. Wenn Sie Ihren eigenen Namespace festgelegt haben, ersetzen Sie diesen Namespace in diesen und allen nachfolgenden Befehlen und Dateien.

Neuere Versionen des Überwachungsoperators können mit den folgenden Befehlen deinstalliert werden:

kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE>
kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>

Wenn der Überwachungsoperator in seinem eigenen dedizierten Namespace bereitgestellt wurde, löschen Sie den Namespace:

 kubectl delete ns <NAMESPACE>
Wenn der erste Befehl „Keine Ressourcen gefunden“ zurückgibt, verwenden Sie die folgenden Anweisungen, um ältere Versionen des Überwachungsoperators zu deinstallieren.

Führen Sie jeden der folgenden Befehle in der Reihenfolge aus. Abhängig von Ihrer aktuellen Installation können einige dieser Befehle Nachrichten ‘object not found’ zurückgeben. Diese Meldungen können sicher ignoriert werden.

kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp
kubectl delete crd agents.monitoring.netapp.com
kubectl -n <NAMESPACE> delete role agent-leader-election-role
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged
kubectl delete <NAMESPACE>-psp-nkmo
kubectl delete ns <NAMESPACE>

Wenn zuvor eine Sicherheitskontextbeschränkung erstellt wurde:

kubectl delete scc telegraf-hostaccess

Über Kube-State-Metrics

Der NetApp Kubernetes Monitoring Operator installiert seine eigenen kube-State-Metriken, um Konflikte mit anderen Instanzen zu vermeiden.

Informationen über Kube-State-Metrics finden Sie unter "Auf dieser Seite".

Konfigurieren/Anpassen des Bedieners

Diese Abschnitte enthalten Informationen zur Anpassung Ihrer Bedienerkonfiguration, zur Arbeit mit Proxy, zur Verwendung eines benutzerdefinierten oder privaten Docker-Repositorys oder zur Arbeit mit OpenShift.

Konfigurationsoptionen

Die am häufigsten geänderten Einstellungen können in der benutzerdefinierten Ressource AgentConfiguration konfiguriert werden. Sie können diese Ressource bearbeiten, bevor Sie den Operator bereitstellen, indem Sie die Datei Operator-config.yaml bearbeiten. Diese Datei enthält kommentierte Beispiele für Einstellungen. Siehe Liste von "Verfügbare Einstellungen" Für die neueste Version des Bedieners.

Sie können diese Ressource auch bearbeiten, nachdem der Operator bereitgestellt wurde, indem Sie den folgenden Befehl verwenden:

 kubectl -n netapp-monitoring edit AgentConfiguration
Um festzustellen, ob die bereitgestellte Version des Operators AgentConfiguration unterstützt, führen Sie den folgenden Befehl aus:
 kubectl get crd agentconfigurations.monitoring.netapp.com
Wenn die Meldung „Fehler vom Server (notfound)“ angezeigt wird, muss Ihr Bediener aktualisiert werden, bevor Sie die AgentConfiguration verwenden können.

Proxy-Unterstützung Wird Konfiguriert

Es gibt zwei Stellen, an denen Sie einen Proxy in Ihrer Umgebung verwenden können, um den Kubernetes Monitoring Operator zu installieren. Es kann sich um dieselben oder separate Proxy-Systeme handelt:

  • Proxy benötigt bei Ausführung des Installationscodes Snippet (mit "Curl"), um das System, an dem das Snippet ausgeführt wird, mit Ihrer Cloud Insights-Umgebung zu verbinden

  • Proxy für die Kommunikation mit Ihrer Cloud Insights Umgebung durch das Ziel-Kubernetes-Cluster

Wenn Sie einen Proxy für eine oder beide dieser Optionen verwenden, müssen Sie zuerst sicherstellen, dass Ihr Proxy für eine gute Kommunikation mit Ihrer Cloud Insights-Umgebung konfiguriert ist, um den Kubernetes Operating Monitor zu installieren. Wenn Sie über einen Proxy verfügen und über den Server/die VM auf Cloud Insights zugreifen können, von dem aus Sie den Operator installieren möchten, wird Ihr Proxy wahrscheinlich richtig konfiguriert.

Für den Proxy, der zur Installation des Kubernetes Operating Monitor verwendet wird, legen Sie vor der Installation des Operators die Umgebungsvariablen http_Proxy/https_Proxy fest. In einigen Proxy-Umgebungen müssen Sie möglicherweise auch die Variable no_Proxy Environment festlegen.

Um die Variablen festzulegen, führen Sie die folgenden Schritte auf Ihrem System aus * bevor* den Kubernetes Monitoring Operator installiert:

  1. Legen Sie die Umgebungsvariable https_Proxy und/oder http_Proxy für den aktuellen Benutzer fest:

    1. Wenn der Proxy, der eingerichtet wird, keine Authentifizierung (Benutzername/Passwort) aufweist, führen Sie den folgenden Befehl aus:

       export https_proxy=<proxy_server>:<proxy_port>
      .. Wenn der Proxy, der eingerichtet wird, über Authentifizierung (Benutzername/Passwort) verfügt, führen Sie folgenden Befehl aus:
      export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>

Damit der Proxy, der für das Kubernetes-Cluster zur Kommunikation mit der Cloud Insights-Umgebung verwendet wird, den Kubernetes Monitoring Operator installieren kann, nachdem alle diese Anweisungen gelesen wurden.

Konfigurieren Sie den Proxy-Abschnitt von AgentConfiguration in Operator-config.yaml, bevor Sie den Kubernetes Monitoring Operator bereitstellen.

agent:
  ...
  proxy:
    server: <server for proxy>
    port: <port for proxy>
    username: <username for proxy>
    password: <password for proxy>

    # In the noproxy section, enter a comma-separated list of
    # IP addresses and/or resolvable hostnames that should bypass
    # the proxy
    noproxy: <comma separated list>

    isTelegrafProxyEnabled: true
    isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
    isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
    isAuProxyEnabled: <true or false> # true if AU enabled
  ...
...

Verwenden eines benutzerdefinierten oder privaten Docker Repositorys

Standardmäßig zieht der Kubernetes Monitoring Operator Container-Images aus dem Cloud Insights-Repository. Wenn Sie ein Kubernetes-Cluster als Ziel für das Monitoring verwenden und der Cluster so konfiguriert ist, dass er nur Container-Images aus einem benutzerdefinierten oder privaten Docker-Repository oder der Container-Registrierung zieht, müssen Sie den Zugriff auf die Container konfigurieren, die vom Kubernetes Monitoring Operator benötigt werden.

Führen Sie das „Image Pull Snippet“ aus der NetApp Monitoring Operator Installationskachel aus. Dieser Befehl meldet sich beim Cloud Insights-Repository an, zieht alle Image-Abhängigkeiten für den Operator und meldet sich vom Cloud Insights-Repository ab. Wenn Sie dazu aufgefordert werden, geben Sie das angegebene temporäre Repository-Passwort ein. Mit diesem Befehl werden alle vom Bediener verwendeten Bilder heruntergeladen, einschließlich optionaler Funktionen. Nachfolgend sehen Sie, für welche Funktionen diese Bilder verwendet werden.

Core Operator-Funktionalität und Kubernetes Monitoring

  • netapp Monitoring

  • ci-kube-rbac-Proxy

  • ci-ksm

  • ci-telegraf

  • Distroless-root-user

Ereignisprotokoll

  • ci-Fluent-Bit

  • ci-kubernetes-Event-Exporteur

Netzwerkleistung und -Zuordnung

  • ci-Netz-Beobachter

Übertragen Sie das Operator-Docker-Image gemäß Ihren Unternehmensrichtlinien in das private/lokale/unternehmenseigene Docker-Repository. Stellen Sie sicher, dass die Bild-Tags und Verzeichnispfade zu diesen Bildern in Ihrem Repository mit denen im Cloud Insights-Repository übereinstimmen.

Bearbeiten Sie die Bereitstellung des Monitoring-Operators in Operator-Deployment.yaml, und ändern Sie alle Bildverweise, um Ihr privates Docker-Repository zu verwenden.

image: <docker repo of the enterprise/corp docker repo>/kube-rbac-proxy:<ci-kube-rbac-proxy version>
image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>

Bearbeiten Sie die AgentConfiguration in Operator-config.yaml, um die neue Position des Docker-Repo zu berücksichtigen. Erstellen Sie ein neues imagePullSecret für Ihr privates Repository. Weitere Informationen finden Sie unter https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

agent:
  ...
  # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry
  # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository
  dockerRepo: your.docker.repo/long/path/to/test
  # Optional: A docker image pull secret that maybe needed for your private docker registry
  dockerImagePullSecret: docker-secret-name

OpenShift-Anweisungen

Wenn Sie OpenShift 4.6 oder höher ausführen, müssen Sie die AgentConfiguration in Operator-config.yaml bearbeiten, um die Einstellung runPrivileged zu aktivieren:

# Set runPrivileged to true SELinux is enabled on your kubernetes nodes
runPrivileged: true

OpenShift kann zusätzliche Sicherheitsstufen implementieren, die den Zugriff auf einige Kubernetes-Komponenten blockieren könnten.

Ein Hinweis über Geheimnisse

Um die Berechtigung für den Kubernetes Monitoring Operator zum Anzeigen der geheimen Daten im gesamten Cluster zu entfernen, löschen Sie vor der Installation die folgenden Ressourcen aus der Datei Operator-Setup.yaml:

 ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

Wenn es sich um ein Upgrade handelt, löschen Sie auch die Ressourcen aus Ihrem Cluster:

 kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

Wenn die Änderungsanalyse aktiviert ist, ändern Sie die Optionen AgentConfiguration oder Operator-config.yaml, um den Änderungsmanagementabschnitt zu entkommentieren und kindsToIgnoreFromWatch: '"Secrets" im Bereich Change-Management aufzunehmen. Notieren Sie sich das Vorhandensein und die Position von einfachen und doppelten Anführungszeichen in dieser Zeile.

# change-management:
  ...
  # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector
  # # Each kind will have to be prefixed by its apigroup
  # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"'
  kindsToIgnoreFromWatch: '"secrets"'
  ...

Überprüfen Von Kubernetes Prüfsummen

Das Cloud Insights Agent-Installationsprogramm führt Integritätsprüfungen durch. Einige Benutzer müssen jedoch vor der Installation oder Anwendung heruntergeladener Artefakte möglicherweise ihre eigenen Überprüfungen durchführen. Um einen nur-Download-Vorgang durchzuführen (im Gegensatz zum Standard-Download-and-install), können diese Benutzer den Agent-Installation Befehl erhalten von der UI und entfernen Sie die nachhängbare "Installation" Option.

Führen Sie hierzu folgende Schritte aus:

  1. Kopieren Sie das Agent Installer-Snippet wie angewiesen.

  2. Anstatt das Snippet in ein Befehlsfenster einzufügen, fügen Sie es in einen Texteditor ein.

  3. Entfernen Sie den nachfolgenden „--install“ aus dem Befehl.

  4. Kopieren Sie den gesamten Befehl aus dem Texteditor.

  5. Fügen Sie es nun in Ihr Befehlsfenster ein (in einem Arbeitsverzeichnis) und führen Sie es aus.

    • Download und Installation (Standard):

       installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download –-install
      ** Nur Download:
      installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download

Der Download-Only-Befehl lädt alle erforderlichen Artefakte vom Cloud Insights in das Arbeitsverzeichnis herunter. Die Artefakte umfassen, dürfen aber nicht beschränkt sein auf:

  • Ein Installationsskript

  • Einer Umgebungsdatei

  • YAML-Dateien

  • Eine signierte Prüfsumme-Datei (sha256.signed)

  • Eine PEM-Datei (netapp_cert.pem) zur Signaturverifizierung

Das Installationsskript, die Umgebungsdatei und die YAML-Dateien können mittels Sichtprüfung verifiziert werden.

Die PEM-Datei kann durch Bestätigung des Fingerabdrucks wie folgt verifiziert werden:

 1A918038E8E127BB5C87A202DF173B97A05B4996
Genauer gesagt,
 openssl x509 -fingerprint -sha1 -noout -inform pem -in netapp_cert.pem
Die signierte Prüfsummendatei kann mit der PEM-Datei verifiziert werden:
 openssl smime -verify -in sha256.signed -CAfile netapp_cert.pem -purpose any
Sobald alle Artefakte zufriedenstellend überprüft wurden, kann die Agenteninstallation durch Ausführen von gestartet werden:
sudo -E -H ./<installation_script_name> --install

Toleranzen und Verfleckungen

Die DemonSets netapp-CI-telegraf-ds, netapp-CI-Fluent-Bit-ds und netapp-CI-net-Observer-l4-ds müssen für jeden Node im Cluster einen Pod planen, damit Daten auf allen Nodes korrekt erfasst werden. Der Operator wurde so konfiguriert, dass er einige bekannte Fehler toleriert. Wenn Sie auf Ihren Nodes benutzerdefinierte Taints konfiguriert haben und damit verhindern, dass Pods auf jedem Knoten ausgeführt werden, können Sie für diese Taints eine Toleration erstellen "In der AgentConfiguration". Wenn Sie auf alle Nodes im Cluster benutzerdefinierte Taints angewendet haben, müssen Sie der Operator-Bereitstellung auch die erforderlichen Toleranzen hinzufügen, damit der Operator-Pod geplant und ausgeführt werden kann.

Weitere Informationen zu Kubernetes "Tönungen und Tolerationen".

Fehlerbehebung

Bei Problemen beim Einrichten des Kubernetes Monitoring Operator sollten Sie Folgendes versuchen:

Problem: Versuchen Sie dies:

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.

Erfassen oder notieren Sie die Ausgabe der folgenden Befehle, und wenden Sie sich an den technischen Support.

 kubectl -n netapp-monitoring get all
 kubectl -n netapp-monitoring describe all
 kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true
 kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true

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.

Rufen Sie den Namen des POD für den Event-Exporter ab:

`kubectl -n netapp-monitoring get pods

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.

Weitere Informationen finden Sie im "Unterstützung" Oder auf der "Data Collector Supportmatrix".