Warnungs-Runbooks

Schweregrade von Warnungen und Fehlerbehebungsverfahren für Automation Suite-Warnungen in EKS/AKS.

Hinweis:

• Allgemeine Anweisungen zur Verwendung der verfügbaren Tools für Warnungen, Metriken und Visualisierungen finden Sie unter Verwenden des Überwachungs-Stacks.
• Weitere Informationen zur Behebung von Problemen und zum Erstellen eines Supportpakets für UiPath® Support-Ingenieure finden Sie unter Fehlerbehebung.
• Wenn Sie sich an den UiPath®-Support wenden, stellen Sie sicher, dass Sie alle Warnungen angeben, die derzeit ausgelöst werden.

Schlüssel zum Schweregrad der Warnung

In der folgenden Tabelle werden die Schweregrade der Warnungen beschrieben.

Warnungsschweregrad	Beschreibung
Information (Info)	Unerwartet, aber harmlos. Kann stummgeschaltet werden, kann aber bei der Diagnose nützlich sein.
Warnung	Hinweis auf eine gezielte Beeinträchtigung der Funktionalität oder die Wahrscheinlichkeit einer Beeinträchtigung in naher Zukunft, die den gesamten Cluster betreffen kann. Schlägt sofortige Maßnahmen (in der Regel innerhalb weniger Tage) vor, um den Cluster in Ordnung zu halten.
Kritisch	Es kommt zu schwerwiegenden Beeinträchtigungen der Funktionalität, die oft im gesamten Cluster verbreitet sind. Erfordert sofortiges Handeln (am selben Tag), um den Cluster zu reparieren.

allgemeine.regeln

TargetDown

Prometheus ist nicht in der Lage, Metriken von dem Ziel in der Warnung zu sammeln, was bedeutet, dass die Grafana-Dashboards und weitere Warnungen, die auf Metriken von diesem Ziel basieren, nicht verfügbar sind. Überprüfen Sie andere Warnungen, die dieses Ziel betreffen.

Kubernetes-storage

KubePersistentVolumeFillingUp

Bei Warnung : Der verfügbare Speicherplatz beträgt weniger als 30 % und ist wahrscheinlich innerhalb von vier Tagen voll.

Wenn kritisch : Der verfügbare Speicherplatz beträgt weniger als 10 %.

Bei allen Diensten, bei denen der Speicherplatz knapp wird, kann es schwierig werden, die Daten wiederherzustellen. Daher sollten die Volumes verkleinert werden, bevor der verfügbare Speicherplatz 0 % erreicht.

Für Prometheus-spezifische Warnungen finden Sie weitere Informationen unter PrometheusStorageUsage .

kubernetes-apps

KubePodNotReady

Ein Pod wurde gestartet, reagiert aber nicht erfolgreich auf den Integritätstest. Das kann bedeuten, dass er hängen geblieben und für den Verkehr nicht verfügbar ist. Sie können die Pod-Protokolle mit kubectl logs überprüfen, um festzustellen, ob es Anzeichen für Fortschritte gibt. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.

kubernetes-system-kubelet

KubeNodeNotReady, KubeNodeUnreachable, KubeletDown

Diese Warnungen weisen auf ein Problem mit einem Knoten hin. In HA-fähigen Produktionsclustern mit mehreren Knoten würden Pods wahrscheinlich auf andere Knoten umgeleitet. Wenn das Problem weiterhin besteht, sollten Sie den Knoten entfernen und entleeren, um die Integrität des Clusters aufrechtzuerhalten. In Clustern ohne zusätzliche Kapazität sollte zuerst ein anderer Knoten mit dem Cluster verbunden werden.

Wenn die Probleme weiterhin bestehen, wenden Sie sich an den UiPath®-Support.

kubernetes-system

KubernetesMemoryPressure

Diese Warnung weist darauf hin, dass die Speicherauslastung auf dem Kubernetes-Knoten sehr hoch ist.

Der Vorfallstyp Kubernetes-Knoten mit MemoryPressure tritt auf, wenn ein Kubernetes-Clusterknoten nicht mehr über den Arbeitsspeicher verfügt, was durch einen Speicherverlust in einer Anwendung verursacht werden kann. Dieser Vorfalltyp erfordert sofortige Aufmerksamkeit, um Ausfallzeiten zu vermeiden und das ordnungsgemäße Funktionieren des Kubernetes-Clusters sicherzustellen.

Wenn diese Warnung ausgelöst wird, versuchen Sie, den Pod auf dem Knoten zu identifizieren, der mehr Speicher verbraucht, indem Sie die folgenden Schritte ausführen:

1. Rufen Sie die CPU- und Speicherstatistiken der Knoten ab:

   kubectl top node
   

2. Rufen Sie die Pods ab, die auf dem Knoten ausgeführt werden:

   kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}
   

3. Überprüfen Sie die Speichernutzung für Pods in einem Namespace mit:

   kubectl top pod --namespace <namespace>
   kubectl logs -f <pod-name> -n <ns>
   

Wenn Sie einen Pod mit hoher Speicherauslastung identifizieren können, überprüfen Sie die Protokolle des Pods und suchen Sie nach Speicherverlustfehlern.

Um das Problem zu beheben, erhöhen Sie nach Möglichkeit die Speicherspezifikation für die Knoten.

Wenn das Problem weiterhin besteht, generieren Sie dasSupportpaket und wenden sich an den UiPath®-Support.

KubernetesDiskPressure

Diese Warnung weist darauf hin, dass die Datenträgernutzung auf dem Kubernetes-Knoten sehr hoch ist.

Wenn diese Warnung ausgelöst wird, versuchen Sie herauszufinden, welcher Pod mehr Datenträger verbraucht:

• Bestätigen Sie mit dem folgenden Befehl, ob sich der Knoten unter DiskPressure befindet:

  kubectl describe node <node-name>
  

Identifizieren Sie für die Bedingung DiskPressure in der Ausgabe.

• Überprüfen Sie die Speicherplatznutzung auf dem betroffenen Knoten:

  df -h
  

Hier wird die Datenträgernutzung auf allen bereitgestellten Dateisystemen angezeigt. Ermitteln Sie die hohe Nutzung.

• Wenn der Datenträger voll und die Bereinigung unzureichend ist, sollten Sie eine Größenänderung des Datenträgers für den Knoten in Betracht ziehen ( insbesondere in Cloud-Umgebungen wie AWS oder GCP). Dieser Prozess kann je nach Ihrer Infrastruktur eine Erweiterung der Volumes erfordern.

node-exporter

NodeFilesystemSpaceFillingUp

Das Dateisystem auf einem bestimmten Knoten füllt sich.

Wenn diese Warnung ausgelöst wird, sollten Sie die folgenden Schritte beachten:

• Bestätigen Sie mit dem folgenden Befehl, ob sich der Knoten unter DiskPressure befindet:

  kubectl describe node <node-name>
  

Identifizieren Sie für die Bedingung DiskPressure in der Ausgabe.

• Löschen Sie die Protokolle und temporären Dateien. Suchen Sie nach großen Protokolldateien in /var/log/ und bereinigen Sie diese, wenn möglich.
• Überprüfen Sie die Speicherplatznutzung auf dem betroffenen Knoten:

  df -h
  

Hier wird die Datenträgernutzung auf allen bereitgestellten Dateisystemen angezeigt. Ermitteln Sie die hohe Nutzung.

• Wenn der Datenträger voll und die Bereinigung unzureichend ist, sollten Sie eine Größenänderung des Datenträgers für den Knoten in Betracht ziehen ( insbesondere in Cloud-Umgebungen wie AWS oder GCP). Dieser Prozess kann je nach Ihrer Infrastruktur eine Erweiterung der Volumes erfordern.

NodeNetworkReceiveErrs

Diese Fehler weisen darauf hin, dass der Netzwerktreiber eine hohe Anzahl von Fehlern meldet. Dies kann durch physische Hardwarefehler oder Fehlkonfiguration im physischen Netzwerk verursacht werden. Dieses Problem betrifft das Betriebssystem und wird nicht durch die UiPath®-Anwendung gesteuert.

Die Warnung wird durch die Überwachung des Zählers/proc/net/dev ausgelöst, den der Linux-Kernel bereitstellt.

Wenden Sie sich an Ihren Netzwerkadministrator und das Team, das die physische Infrastruktur verwaltet.

NodeNetworkTransmitErrs

Diese Fehler weisen darauf hin, dass der Netzwerktreiber eine hohe Anzahl von Fehlern meldet. Dies kann durch physische Hardwarefehler oder Fehlkonfiguration im physischen Netzwerk verursacht werden. Dieses Problem betrifft das Betriebssystem und wird nicht durch die UiPath®-Anwendung gesteuert.

Die Warnung wird durch die Überwachung des Zählers/proc/net/dev ausgelöst, den der Linux-Kernel bereitstellt.

Wenden Sie sich an Ihren Netzwerkadministrator und das Team, das die physische Infrastruktur verwaltet.

InternodeCommunicationBroken

Der Knoten reagiert aufgrund eines Problems nicht mehr, das zu einer Unterbrechung der Kommunikation zwischen Knoten im Cluster führte.

Wenn das Problem weiterhin besteht, wenden Sie sich mit dem generierten Supportpaket an den UiPath®-Support.

uipath.prometheus.resource.provisioning.alerts

PrometheusMemoryUsage, PrometheusStorageUsage

Diese Warnungen warnen, wenn sich der Cluster den konfigurierten Grenzwerten für Arbeitsspeicher und Speicher nähert. Dies ist wahrscheinlich bei Clustern der Fall, bei denen die Nutzung in letzter Zeit erheblich zugenommen hat (normalerweise von Robotern und nicht von Benutzern) oder wenn Knoten zum Cluster hinzugefügt werden, ohne Prometheus-Ressourcen anzupassen. Dies ist auf eine Zunahme der Menge der gesammelten Metriken zurückzuführen.

Dies könnte auch auf eine große Anzahl von Warnungen zurückzuführen sein. Es ist wichtig zu überprüfen, warum die große Anzahl von Warnungen ausgelöst wird.

Wenn dieses Problem weiterhin besteht, wenden Sie sich mit dem generierten Supportpaket an den UiPath®-Support.

alertmanager.rules

AlertmanagerConfigInconsistent

Diese Warnung wird ausgelöst, wenn Alertmanager Instanzen innerhalb desselben Clusters unterschiedliche Konfigurationen haben. Dies könnte auf ein Problem mit der Konfigurationsrolle hinweisen, die nicht in allen Instanzen von Alertmanager konsistent ist.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

1. Führen Sie ein diff -Tool zwischen allen alertmanager.yml aus, die bereitgestellt werden, um das Problem zu identifizieren.
2. Löschen Sie das falsche Geheimnis, und stellen Sie das richtige bereit.

Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.

AlertmanagerFailedReload

AlertManager konnte die Konfiguration nicht laden oder neu laden. Bitte überprüfen Sie alle benutzerdefinierten AlertManager-Konfigurationen auf Eingabefehler; andernfalls wenden Sie sich an den UiPath®-Support und stellen Sie das Supportpaket bereit. Weitere Informationen finden Sie unter Verwenden des Automation Suite-Supportpakets.

AlertmanagerMembersInconsistent

Diese Warnung wird ausgelöst, wenn Alertmanager nicht alle anderen Mitglieder des Clusters gefunden hat.

UiPathAvailabilityHighTrafficBackend, UiPathAvailabilityMediumTrafficUserFacing, UiPathAvailabilityMediumTrafficBackend, UiPathAvailabilityLowTrafficUserFacing, UiPathAvailabilityLowTrafficBackend

Die Anzahl der http 500-Antworten von UiPath®-Diensten überschreitet einen bestimmten Schwellenwert.

In der folgenden Tabelle sind die Schwellenwerte für die Datenverkehrsebene und die Fehlerraten aufgeführt.

Verkehrsaufkommen	Anzahl der Anfragen in 20 Minuten	Fehlerschwellenwert (für HTTP 500)
Hoch	>100.000	0,1 %
Mittel	Zwischen 10.000 und 100.000	1 %
Niedrig	< 10.000	5 %

Fehler in benutzerorientierten Diensten würden wahrscheinlich zu einer Beeinträchtigung der Funktionalität führen, die in der Benutzeroberfläche der Automation Suite direkt sichtbar ist, während Fehler in Backend-Diensten weniger offensichtliche Folgen hätten.

Die Warnung gibt an, welcher Dienst eine hohe Fehlerquote aufweist. Um zu verstehen, welche Kaskadenprobleme von anderen Diensten aus auftreten können, von denen der Berichtdienst abhängt, können Sie das Istio Workload-Dashboard verwenden, das Fehler zwischen Diensten anzeigt.

Bitte überprüfen Sie alle kürzlich neu konfigurierten Automation Suite-Produkte. Detaillierte Protokolle sind auch mit dem Befehl kubectl logs verfügbar. Wenn der Fehler weiterhin auftritt, wenden Sie sich bitte an den UiPath®-Support.

uipath.cronjob.alerts.rules

IdentityKerberosTgtUpdateFailed

Dieser Auftrag aktualisiert das neueste Kerberos-Ticket für alle UiPath®-Dienste. Fehler in diesem Auftrag würden dazu führen, dass die SQL Server-Authentifizierung fehlschlägt. Wenden Sie sich bitte an den UiPath®-Support.

ceph.rules, cluster-state-alert.rules

CephMgrIsAbsent

Diese Warnung weist darauf hin, dass der Ceph Manager aus der Prometheus-Zielerkennung verschwunden ist.

Wenn diese Warnung ausgelöst wird, überprüfen und stellen Sie sicher, dass der Ceph Manager-Pod in Betrieb ist und fehlerfrei ist. Wenn der Pod fehlerfrei ist, überprüfen Sie bitte die Protokolle und stellen Sie sicher, dass der Pod in der Lage ist, Prometheus-Metriken auszugeben.

CephNodeDown

Diese Warnung weist darauf hin, dass ein Knoten, der Ceph-Pods ausführt, ausgefallen ist. Während der Speichervorgang weiterhin funktioniert, da Ceph für den Umgang mit einem Knotenfehler entwickelt wurde, wird empfohlen, das Problem zu beheben, um das Risiko zu minimieren, dass ein anderer Knoten ausfällt und die Speicherfunktionen beeinträchtigt werden.

Wenn diese Warnung ausgelöst wird, muss der Pod bei einem Cluster mit mehreren Knoten auf einem anderen Knoten geplant werden. Stellen Sie sicher, dass die neuen osd-Pods im Namespace rook-ceph ausgeführt werden und sich im neuen Knoten in einem fehlerfreien Zustand befinden.

Sie können den Knotenfehler überprüfen, indem Sie den Knoten mit dem folgenden Befehl beschreiben:

kubectl get nodes

Überprüfen Sie den Knoten, um die Ursache des Problems zu ermitteln, und wenden Sie sich an den UiPath®-Support.

Ceph-Warnungen

CephClusterCriticallyFull

Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 80 % überschritten hat und bei 85 % schreibgeschützt ist.

Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets im AI Center löschen, oder erweitern Sie den für Ceph-PVC verfügbaren Speicherplatz.

Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen.

CephClusterReadOnly

Diese Warnung gibt an, dass die Nutzung des Ceph-Speicherclusters 85 % überschritten hat und jetzt schreibgeschützt ist. Geben Sie Speicherplatz frei, oder erweitern Sie den Speichercluster sofort.

Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets im AI Center löschen, oder erweitern Sie den für Ceph-PVC verfügbaren Speicherplatz.

Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen.

CephPoolQuotaBytesCriticallyExhausted

Diese Warnung gibt an, dass die Nutzung des Ceph-Speicherpools 90 % überschritten hat.

Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in CEPH, indem Sie einige ungenutzte Dataset in AI Center löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.

Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen.

CephClusterErrorState

Diese Warnung gibt an, dass sich der Ceph-Speichercluster seit mehr als 10 Minuten im Fehlerzustand befindet.

Diese Warnung gibt an, dass sich der rook-ceph-mgr -Auftrag für eine inakzeptable Zeit im Fehlerstatus befindet. Suchen Sie nach anderen Warnungen, die möglicherweise vor dieser Warnung ausgelöst wurden, und beheben Sie diese zuerst.

CephOSDCriticallyFull

Wenn der Schweregrad der Warnung Kritisch ist, ist der verfügbare Speicherplatz kleiner als 20 %.

Bei allen Diensten, bei denen der Speicherplatz knapp wird, kann es schwierig werden, die Daten wiederherzustellen. Daher sollten die Volumes verkleinert werden, bevor der verfügbare Speicherplatz 10 % erreicht. Siehe folgende Anweisungen: .

uipath.requestrouting.alerts

UiPathRequestRouting

Fehler in der Anforderungsroutingschicht würden zu einer eingeschränkten Funktionalität führen, die direkt in der Automation Suite-UI sichtbar ist. Die Anforderungen werden nicht an Back-End-Dienste weitergeleitet.

Das detaillierte Fehlerprotokoll der Anforderungsweiterleitung in istio-ingressgateway -Pods finden Sie im Namespace istio-system. Rufen Sie den Pod-Namen ab, indem Sie die folgenden Befehle ausführen:

kubectl get pods -n istio-system
kubectl logs <istio-ingressgateway-pod-name> -n istio-system

Wenn der Fehler weiterhin auftritt, wenden Sie sich an den UiPath®-Support.

osd-alert.rules

CephOSDlapping

Diese Warnung weist darauf hin, dass der Speicher-Daemon in den letzten fünf Minuten mehr als fünfmal neu gestartet wurde.

Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:

1. Überprüfen Sie den Zustand des Ceph-Clusters. Sie müssen ceph status in der Ceph-Toolbox ausführen, um die schwebenden OSDs zu identifizieren:

   kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
   

   Sie können den Pod der Ceph-Tools identifizieren, indem Sie die Pods im Namespace auflisten:

   kubectl -n rook-ceph get pod | grep tools
   

2. Überprüfen Sie die OSD-Protokolle auf den wechselnden OSD-Pod, um Probleme zu identifizieren:

   kubectl -n rook-ceph logs <osd-pod>
   

3. Probleme auf Knotenebene identifizieren:

   • Überprüfen Sie die Ressourcennutzung:

     kubectl top node <node-name>
     

   • Überprüfen Sie den Zustand des Datenträgers. Sie müssen eine SSH-Verbindung in den Knoten herstellen unddf -h und dmesg ausführen, um Festplattenfehler zu überprüfen.

4. Starten Sie den OSD-Pod neu. Wenn das Problem nur vorübergehend ist, müssen Sie den wechselnden OSD-Pod neu starten:

   kubectl -n rook-ceph delete pod <osd-pod>
   

5. Stellen Sie sicher, dass es keine Netzwerkkonnektivitätsprobleme zwischen OSDs und Ceph-Monitoren gibt.

6. Markieren Sie bei Bedarf das wechselnde OSD vorübergehend als out:

   ceph osd out <osd-id>
   

7. Überwachen Sie den Cluster weiterhin, um sicherzustellen, dass das Problem nicht erneut auftritt.

CephOSDDiskReagiert nicht

Diese Warnung zeigt an, dass das Host-Datenträgergerät nicht reagiert.

Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:

1. Überprüfen Sie den Status des Ceph-Clusters. Sie müssen den allgemeinen Zustand des Ceph-Clusters bestätigen und weitere Details zum OSD-Status erhalten:

   • Führen Sie den folgenden Befehl innerhalb des Ceph-Toolbox-Pods aus:

     kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
     

   • Identifizieren Sie den Pod der Ceph-Tools, indem Sie die Pods im Namespace auflisten:

     kubectl -n rook-ceph get pod | grep tools
     

2. Überprüfen Sie den OSD-Pod-Status. Sie müssen überprüfen, ob die OSD-Pods ausgeführt werden. Führen Sie den folgenden Befehl aus, um alle OSD-Pod-Status zu überprüfen:

   kubectl -n rook-ceph get pods | grep osd
   

   Wenn sich ein OSD-Pod im Status CrashLoopBackOff oder Pending befindet, könnte dies auf ein Problem mit dem OSD-Datenträger oder dem zugrunde liegenden Knoten hinweisen.

3. Starten Sie den betroffenen OSD-Pod neu. Wenn sich ein OSD-Pod in einem schlechten Zustand befindet (CrashLoopBackOff, Error usw.), müssen Sie den Pod neu starten, um zu sehen, ob sich das Problem von selbst löst. Kubernetes versucht automatisch, den Pod umzuplanen.

   kubectl -n rook-ceph delete pod <osd-pod>
   

   Der OSD-Pod wird neu gestartet, und wenn es sich um ein vorübergehendes Problem handelt, kann es dadurch behoben werden.

4. Überprüfen Sie die OSD-Protokolle. Wenn der Neustart das Problem nicht behoben hat, überprüfen Sie die OSD-Pod-Protokolle auf weitere Informationen darüber, warum der Datenträger nicht reagiert:

   kubectl -n rook-ceph logs <osd-pod>
   

   Suchen Sie nach Fehlern im Zusammenhang mit dem Datenträger oder anderen Problemen (z. B. E/A-Fehler, fehlgeschlagene Bereitstellungen).

5. Identifizieren Sie Probleme auf Knotenebene. Wenn der OSD-Datenträger nicht ordnungsgemäß bereitgestellt oder getrennt wurde, können Sie sich beim betroffenen Knoten anmelden und den Status der Datenträgerbereitstellung überprüfen:

   ssh <node> df -h
   

Suchen Sie nach fehlenden oder nicht bereitgestellten Datenträgern, die Ceph erwartet. Binden Sie den Datenträger ggf. erneut ein oder ersetzen Sie ihn, wenn er fehlgeschlagen ist.

CephOSDDiskUnavailable

Diese Warnung weist darauf hin, dass der Ceph OSD-Datenträger auf dem Host nicht zugänglich ist.

Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:

1. Überprüfen Sie den Status des Ceph-Clusters. Sie müssen den allgemeinen Zustand des Ceph-Clusters bestätigen und weitere Details zum OSD-Status erhalten:

   • Führen Sie den folgenden Befehl innerhalb des Ceph-Toolbox-Pods aus:

     kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
     

   • Identifizieren Sie den Pod der Ceph-Tools, indem Sie die Pods im Namespace auflisten:

     kubectl -n rook-ceph get pod | grep tools
     

2. Überprüfen Sie den OSD-Pod-Status. Sie müssen überprüfen, ob die OSD-Pods ausgeführt werden. Führen Sie den folgenden Befehl aus, um alle OSD-Pod-Status zu überprüfen:

   kubectl -n rook-ceph get pods | grep osd
   

   Wenn sich ein OSD-Pod im Status CrashLoopBackOff oder Pending befindet, könnte dies auf ein Problem mit dem OSD-Datenträger oder dem zugrunde liegenden Knoten hinweisen.

3. Starten Sie den betroffenen OSD-Pod neu. Wenn sich ein OSD-Pod in einem schlechten Zustand befindet (CrashLoopBackOff, Error usw.), müssen Sie den Pod neu starten, um zu sehen, ob sich das Problem von selbst löst. Kubernetes versucht automatisch, den Pod umzuplanen.

   kubectl -n rook-ceph delete pod <osd-pod>
   

Der OSD-Pod wird neu gestartet. Wenn es sich um ein vorübergehendes Problem handelt, kann es dadurch behoben werden. 4. Überprüfen Sie die OSD-Protokolle. Wenn der Neustart das Problem nicht behoben hat, finden Sie in den OSD-Pod-Protokollen weitere Informationen dazu, warum der Datenträger nicht reagiert:

kubectl -n rook-ceph logs <osd-pod>

Suchen Sie nach Fehlern im Zusammenhang mit dem Datenträger oder anderen Problemen (z. B. E/A-Fehler, fehlgeschlagene Bereitstellungen).

persistent-volume-alert.rules

PersistentVolumeUsageCritical

Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets im AI Center löschen, oder erweitern Sie den für Ceph-PVC verfügbaren Speicherplatz.

Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen.

Server-TLS-Zertifikatwarnungen

SecretCertificateExpiry7Days

Diese Warnung gibt an, dass das TLS-Zertifikat des Servers in den folgenden 7 Tagen abläuft.

Um dieses Problem zu beheben, aktualisieren Sie das TLS-Zertifikat. Anweisungen finden Sie unter Verwalten von Serverzertifikaten.

RKE2Zertifikatablauflauf7Tage

Diese Warnung gibt an, dass das RKE2-Serverzertifikat in den folgenden 7 Tagen abläuft.

Warnungen zu Identitätstokensignaturzertifikaten

IdentityCertificateExpiry30Days

Diese Warnung gibt an, dass das Identitätstoken-Signaturzertifikat in den folgenden 30 Tagen abläuft.

Um dieses Problem zu beheben, aktualisieren Sie das Signaturzertifikat für das Identitäts-Token. Anweisungen finden Sie unter Verwalten von Serverzertifikaten.

IdentityCertificateExpiry7Days

Diese Warnung gibt an, dass das Identitätstoken-Signaturzertifikat in den folgenden 7 Tagen abläuft.

Um dieses Problem zu beheben, aktualisieren Sie das Signaturzertifikat für das Identitäts-Token. Anweisungen finden Sie unter Verwalten von Serverzertifikaten.

Etdc-Warnungen

EtcdGrpcRequestsSlow

Diese Warnung gibt an, dass etcd-GRPC-Anforderungen langsam sind. Dies ist eine Warnung.

Wenn diese Warnung weiterhin auftritt, wenden Sie sich an den UiPath®-Support.

EtcdHttpRequestsSlow

Diese Warnung weist darauf hin, dass HTTP-Anforderungen langsamer werden. Dies ist eine Warnung.

Warnungen zur Datenträgergröße

LowDiskForRancherPartition

Diese Warnung gibt an, dass der freie Speicherplatz für die Partition /var/lib/rancher kleiner ist als:

• 35 % – der Schweregrad der Warnung ist Warnung
• 25 % – Der Schweregrad der Warnung ist kritisch

Wenn diese Warnung ausgelöst wird, erhöhen Sie die Größe des Datenträgers.

LowDiskForKubeletPartition

Diese Warnung gibt an, dass der freie Speicherplatz für die Partition /var/lib/kubelet kleiner ist als:

• 35 % – der Schweregrad der Warnung ist Warnung
• 25 % – Der Schweregrad der Warnung ist kritisch Wenn diese Warnung ausgelöst wird, erhöhen Sie die Größe des Datenträgers.

LowDiskForVarPartition

Diese Warnung gibt an, dass der freie Speicherplatz für die Partition /var kleiner ist als:

• 35 % – der Schweregrad der Warnung ist Warnung
• 25 % – Der Schweregrad der Warnung ist kritisch

Hinweis:

Die Speicheranforderungen für ML-Fähigkeiten können die Datenträgernutzung erheblich erhöhen.

Wenn diese Warnung ausgelöst wird, erhöhen Sie die Größe des Datenträgers.

LowDiskForVarLogPartition

Diese Warnung gibt an, dass der freie Speicherplatz für die Partition /var/lib/var kleiner ist als:

• 25 % – Der Schweregrad der Warnung ist kritisch

Wenn diese Warnung ausgelöst wird, erhöhen Sie die Größe des Datenträgers.

Sicherungswarnungen

NFSServerDisconnected

Diese Warnung weist darauf hin, dass die NFS-Serververbindung unterbrochen wurde.

Sie müssen die NFS-Serververbindung und den Mount-Pfad überprüfen.

VolumeBackupFailed

Diese Warnung gibt an, dass die Sicherung für einen PVC fehlgeschlagen ist.

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

1. Überprüfen Sie den Status des PVC, um sicherzustellen, dass es sich um Bound um ein persistentes Volume (PV) handelt.

   kubectl get pvc --namespace <namespace>
   

   Der Befehl listet alle PVCs und deren aktuellen Status auf. Das PVC muss den Status Bound haben, um anzugeben, dass es erfolgreich ein PV angefordert hat.

   Wenn der Status Pending ist, wartet der PVC immer noch auf ein geeignetes PV und weitere Untersuchung ist erforderlich.

2. Wenn sich der PVC nicht im Zustand Bound befindet oder wenn Sie detailliertere Informationen benötigen, verwenden Sie den Befehl describe:

   kubectl describe pvc <pvc-name> --namespace <namespace>
   

   Suchen Sie nach Informationen zum Status, zu Ereignissen und zu Fehlermeldungen. Ein Problem könnte z. B. mit Fehlkonfigurationen von Speicherklassen oder Kontingentbeschränkungen zusammenhängen.

3. Überprüfen Sie den Zustand des persistenten Volumes (PV), das an den PVC gebunden ist:

   kubectl get pv <pv-name>
   

   Der Status sollte Bound sein. Wenn sich das PV im Zustand Released oder Failed befindet, kann dies auf Probleme mit dem zugrunde liegenden Speicher hinweisen.

4. Wenn der PVC von einem Pod verwendet wird, überprüfen Sie, ob der Pod das Volume erfolgreich bereitgestellt hat:

   kubectl get pod <pod-name> --namespace <namespace>
   

   Wenn sich der Pod im Status Running befindet, wird angegeben, dass der PVC erfolgreich bereitgestellt wurde. Wenn sich der Pod in einem Fehlerstatus befindet (z. B. InitBackOff), kann dies auf Probleme beim Mounten des Volumes hinweisen.

5. Wenn es Probleme beim Anbringen des PVC gibt, beschreiben Sie den Pod, um auf Installationsfehler zu überprüfen:

   kubectl describe pod <pod-name> --namespace <namespace>
   

SicherungDeaktiviert

Diese Warnung gibt an, dass die Sicherung deaktiviert ist.

Sie müssen die Sicherung aktivieren.

SicherungTeilweiseFehlgeschlagen

Diese Warnung zeigt an, dass die Velero-Sicherung fehlgeschlagen ist.

Sie müssen sich an den UiPath®-Support wenden.