- Überblick
- Anforderungen
- Installation
- Fragen und Antworten: Bereitstellungsvorlagen
- Konfigurieren der Maschinen
- Konfigurieren des externen Objektspeichers
- Konfigurieren einer externen Docker-Registrierung
- Konfigurieren des DNS
- Konfigurieren von Microsoft SQL-Servern
- Konfigurieren der Zertifikate
- Online-Auswertungsinstallation mit einem Knoten
- Offline-Auswertungsinstallation mit einem Knoten
- Konfigurieren der Maschinen
- Konfigurieren des externen Objektspeichers
- Konfigurieren einer externen Docker-Registrierung
- Konfigurieren des Lastausgleichs
- Konfigurieren des DNS
- Konfigurieren von Microsoft SQL-Servern
- Konfigurieren der Zertifikate
- HA-fähige Online-Produktionsinstallation mit mehreren Knoten
- HA-fähige Offline-Produktionsinstallation mit mehreren Knoten
- Disaster Recovery – Installieren des sekundären Clusters
- Herunterladen der Installationspakete
- install-uipath.sh-Parameter
- Aktivieren eines High Availability Add-ons für den Cluster
- Document Understanding-Konfigurationsdatei
- Hinzufügen eines dedizierten Agent-Knotens mit GPU-Unterstützung
- Hinzufügen eines dedizierten Agent-Knotens für Task Mining
- Verbinden einer Task Mining-Anwendung
- Hinzufügen eines dedizierten Agentenknotens für Automation Suite-Roboter
- Nach der Installation
- Clusterverwaltung
- Verwalten von Produkten
- Erste Schritte mit dem Clusterverwaltungsportal
- Migrieren von Objectstore von persistentem Volume zu Raw-Festplatten
- Migrieren von Daten zwischen Objectstores
- Clusterinterner Objectstore zu einem externen Objectstore migrieren
- Wechsel zum sekundären Cluster
- Disaster Recovery: Durchführen von Vorgängen nach der Installation
- Umwandlung einer bestehenden Installation in eine Multi-Site-Einrichtung
- Richtlinien zum Upgrade einer Aktiv-/Passiv-Bereitstellung
- Leitlinien zum Sichern und Wiederherstellen einer Aktiv-/Passiv-Bereitstellung
- Überwachung und Warnungen
- Verwendung des Überwachungs-Stacks
- Warnungs-Runbooks
- Migration und Upgrade
- Migrationsoptionen
- Schritt 1: Verschieben der Identitätsorganisationsdaten von einer eigenständigen in die Automation Suite
- Schritt 2: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 3: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 4: Zusammenführen von Organisationen in der Automation Suite
- Schritt 5: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Step 6: Migrating standalone Insights
- Schritt 7: Löschen des Standardmandanten
- B) Migration von einzelnen Mandanten
- Produktspezifische Konfiguration
- Best Practices und Wartung
- Fehlersuche und ‑behebung
- Fehlerbehebung bei Diensten während der Installation
- Deinstallieren des Clusters
- Löschen von Offline-Artefakten für mehr Speicherplatz
- So löschen Sie Redis-Daten
- So können Sie die Istio-Protokollierung aktivieren
- So werden Protokolle manuell bereinigt
- So löschen Sie alte Protokolle, die im sf-logs-Paket gespeichert sind
- So deaktivieren Sie Streaming-Protokolle für das AI Center
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- So löschen Sie Bilder aus dem alten Installationsprogramm nach dem Upgrade
- Automatisches Bereinigen von Longhorn-Snapshots
- Deaktivieren von NIC-Prüfsummen-Offloading
- So legen Sie die ArgoCD-Protokollebene manuell auf Info fest
- Es kann keine Offlineinstallation auf RHEL 8.4 OS ausgeführt werden.
- Fehler beim Herunterladen des Pakets
- Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl
- Zertifikatproblem bei der Offlineinstallation
- Die erste Installation schlägt während des Longhorn-Setups fehl
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Voraussetzungsprüfung für das Selinux-iscsid-Modul schlägt fehl
- Azure-Datenträger nicht als SSD markiert
- Fehler nach der Zertifikatsaktualisierung
- Virenschutz verursacht Probleme bei der Installation
- Automation Suite funktioniert nach Betriebssystem-Upgrade nicht
- Bei der Automation Suite muss „backlog_wait_time“ auf 0 gesetzt werden.
- GPU-Knoten von Nichtverfügbarkeit von Ressourcen betroffen
- Volume nicht bereitstellbar, da es nicht für Workloads bereit ist
- Fehler beim Hoch- oder Herunterladen von Daten im Objektspeicher
- Die Größenänderung eines PVC bewirkt keine Korrektur von Ceph
- Fehler beim Ändern der PVC-Größe
- Fehler beim Ändern der Größe von objectstore PVC
- Rook Ceph oder Looker-Pod hängen im Init-Status fest
- Fehler beim Anhängen eines StatefulSet-Volumes
- Fehler beim Erstellen persistenter Volumes
- Patch zur Rückgewinnung von Speicherplatz
- Sicherung aufgrund des Fehlers „TooManySnapshots“ fehlgeschlagen
- Alle Longhorn-Replikate sind fehlerhaft
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- Die Authentifizierung funktioniert nach der Migration nicht
- Kinit: KDC kann für Realm <AD Domain> beim Abrufen der ersten Anmeldeinformationen nicht gefunden werden.
- Kinit: Keytab enthält keine geeigneten Schlüssel für *** beim Abrufen der ersten Anmeldeinformationen
- GSSAPI-Vorgang aufgrund eines ungültigen Statuscodes fehlgeschlagen
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag erhalten
- SSPI-Anbieter: Server in Kerberos-Datenbank nicht gefunden
- Anmeldung eines AD-Benutzers aufgrund eines deaktivierten Kontos fehlgeschlagen
- ArgoCD-Anmeldung fehlgeschlagen
- Fehler beim Abrufen des Sandbox-Abbilds
- Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt
- Redis-Testfehler
- RKE2-Server kann nicht gestartet werden
- Secret nicht im UiPath-Namespace gefunden
- ArgoCD wechselt nach der ersten Installation in den Status „In Bearbeitung“.
- Probleme beim Zugriff auf das schreibgeschützte ArgoCD-Konto
- MongoDB-Pods in „CrashLoopBackOff“ oder ausstehende PVC-Bereitstellung nach Löschung
- Fehlerhafte Dienste nach Clusterwiederherstellung oder Rollback
- Pods stecken in Init:0/X
- Prometheus im Zustand „CrashloopBackoff“ mit OOM-Fehler (Out-of-Memory)
- Fehlende Ceph-rook-Metriken in Überwachungs-Dashboards
- Document Understanding erscheint nicht auf der linken Leiste der Automation Suite
- Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung
- Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen
- Migrationsauftrag schlägt in ArgoCD fehl
- Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam
- Verwenden des Automation Suite-Diagnosetools
- Verwenden des Automation Suite Support Bundle-Tools
- Erkunden von Protokollen
Warnungs-Runbooks
- Allgemeine Anweisungen zur Verwendung der verfügbaren Tools für Warnungen, Metriken und Visualisierungen finden Sie unter Verwenden des Überwachungs-Stacks.
- Weitere Informationen zum Beheben von Problemen und zum Erstellen eines Supportpakets für UiPath®-Supporttechniker finden Sie unter Fehlerbehebung.
- Wenn Sie sich an den UiPath®-Support wenden, geben Sie bitte alle Warnungen an, die derzeit ausgelöst werden.
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. |
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.
Diese Warnung soll sicherstellen, dass die gesamte Warnungspipeline funktionsfähig ist. Diese Warnung wird immer ausgelöst. Daher sollte sie immer in AlertManager und gegen einen Receiver ausgelöst werden. Es gibt Integrationen mit verschiedenen Benachrichtigungsmechanismen, die Sie benachrichtigen, wenn diese Warnung nicht ausgelöst wird. Zum Beispiel die DeadMansSnitch-Integration in PagerDuty.
kubectl describe
und die Protokolle mit kubectl logs
, um Details zu möglichen Abstürzen zu sehen. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
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.
Es wurde versucht, eine Bereitstellung oder ein StatefulSet zu aktualisieren, was jedoch fehlgeschlagen ist und noch nicht rückgängig gemacht werden konnte. Wenden Sie sich an den UiPath®-Support.
In Hochverfügbarkeitsclustern mit mehreren Replikaten wird diese Warnung ausgelöst, wenn die Anzahl der Replikate nicht optimal ist. Das kann auftreten, wenn im Cluster nicht genügend Ressourcen für die Planung vorhanden sind. Überprüfen Sie die Ressourcennutzung und fügen Sie bei Bedarf Kapazitäten hinzu. Wenden Sie sich andernfalls an den UiPath®-Support.
Eine Aktualisierung eines StatefulSets ist fehlgeschlagen. Wenden Sie sich an den UiPath®-Support.
Siehe auch: StatefulSets.
Daemonset-Rollout ist fehlgeschlagen. Wenden Sie sich an den UiPath®-Support.
Siehe auch: DaemonSet.
kubectl describe
des Pods. Die häufigste Ursache für wartende Container ist, dass das Abrufen des Images fehlschlägt. Für Cluster mit Air Gap kann das bedeuten, dass die lokale Registrierung nicht verfügbar ist. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
Das kann auf ein Problem mit einem der Knoten hinweisen. Überprüfen Sie den Zustand jedes Knotens und beheben Sie alle bekannten Probleme. Wenden Sie sich andernfalls an den UiPath®-Support.
Die Ausführung eines Auftrags dauert mehr als 12 Stunden. Das ist nicht zu erwarten. Wenden Sie sich an den UiPath®-Support.
Ein Auftrag ist fehlgeschlagen; die meisten Aufträge werden jedoch automatisch wiederholt. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
Der Autoscaler kann die Zielressource nicht wie konfiguriert skalieren. Wenn der Sollwert höher als der Istwert ist, kann ein Ressourcenmangel vorliegen. Wenn der Sollwert niedriger als der Istwert ist, können Pods beim Herunterfahren hängen bleiben. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
Siehe auch: Horizontales Pod-Autoscaling
Die Anzahl der Replikate für einen bestimmten Dienst hat das Maximum erreicht. Dies ist der Fall, wenn die Anzahl der Anforderungen an den Cluster sehr hoch ist. Wenn ein hoher Datenverkehr zu erwarten ist und nur vorübergehend auftritt, können Sie diese Warnung stummschalten. Diese Warnung ist jedoch ein Zeichen dafür, dass der Cluster an seiner Kapazitätsgrenze angelangt ist und keinen weiteren Datenverkehr mehr bewältigen kann. Wenn im Cluster mehr Ressourcenkapazität verfügbar ist, können Sie die Anzahl der maximalen Replikate für den Dienst erhöhen, indem Sie diese Anweisungen befolgen:
# Find the horizontal autoscaler that controls the replicas of the desired resource
kubectl get hpa -A
# Increase the number of max replicas of the desired resource, replacing <namespace> <resource> and <maxReplicas>
kubectl -n <namespace> patch hpa <resource> --patch '{"spec":{"maxReplicas":<maxReplicas>}}'
# Find the horizontal autoscaler that controls the replicas of the desired resource
kubectl get hpa -A
# Increase the number of max replicas of the desired resource, replacing <namespace> <resource> and <maxReplicas>
kubectl -n <namespace> patch hpa <resource> --patch '{"spec":{"maxReplicas":<maxReplicas>}}'
Siehe auch: Horizontales Pod-Autoscaling.
Diese Warnungen weisen darauf hin, dass der Cluster keinen Knotenfehler tolerieren kann. Bei Auswertungsclustern mit einem einzelnen Knoten ist dies bekannt und diese Warnungen können stummgeschaltet werden. Bei HA-fähigen Produktionseinrichtungen mit mehreren Knoten werden diese Warnungen ausgelöst, wenn zu viele Knoten nicht mehr funktionsfähig sind, um die hohe Verfügbarkeit zu unterstützen. Sie zeigen an, dass die Knoten wiederhergestellt oder ersetzt werden sollten.
KubeCPUQuotaOvercommit, KubeMemoryQuotaOvercommit, KubeQuotaAlmostFull, KubeQuotaFullyUsed, KubeQuotaExceeded
Diese Warnungen beziehen sich auf Namespace-Ressourcenkontingente, die nur im Cluster vorhanden sind, wenn sie durch Anpassung hinzugefügt wurden. Namespace-Ressourcenkontingente werden nicht im Rahmen der Automation Suite-Installation hinzugefügt.
Siehe auch: Ressourcenkontingente.
Bei Warnend: Der verfügbare Speicherplatz beträgt weniger als 30 % und wird wahrscheinlich innerhalb von vier Tagen ausgefüllt.
Bei Kritisch: Der verfügbare Speicherplatz ist 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.
Anweisungen finden Sie unter Konfigurieren des Clusters.
Weitere Informationen und Anweisungen zu Prometheus-spezifischen Warnungen finden Sie unter PrometheusStorageUsage .
Der Sammler der Kube-State-Metrics kann keine Metriken aus dem Cluster ohne Fehler sammeln. Das bedeutet, dass wichtige Warnungen möglicherweise nicht ausgelöst werden. Wenden Sie sich an den UiPath®-Support.
Siehe auch: Kube-State-Metrics beim Release.
Bei Warnend: Ein Clientzertifikat, das zur Authentifizierung beim Kubernetes API-Server verwendet wird, läuft in weniger als sieben Tagen ab.
Bei Kritisch: Ein Clientzertifikat, das zur Authentifizierung beim Kubernetes API-Server verwendet wird, läuft in weniger als einem Tag ab.
Sie müssen das Zertifikat erneuern.
Zeigt Probleme mit der Kubernetes-Kontrollebene an. Überprüfen Sie den Zustand der Master-Knoten, beheben Sie alle offenen Probleme und wenden Sie sich an den UiPath®-Support, wenn die Probleme weiterhin bestehen.
Siehe auch:
Diese Warnung weist darauf hin, dass beim Kubernetes API-Server eine hohe Fehlerrate auftritt. Dieses Problem kann zu anderen Fehlern führen, daher wird empfohlen, das Problem proaktiv zu untersuchen.
api-server
, um die Ursache des Problems mit dem Befehl kubectl logs <pod-name> -n kube-system
herauszufinden.
KubeNodeNotReady, KubeNodeUnreachable, KubeNodeReadinessFlapping, KubeletPlegDurationHigh, KubeletPodStartUpLatencyHigh, 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.
Auf dem angegebenen Knoten werden zu viele Pods ausgeführt.
Verbinden Sie einen anderen Knoten mit dem Cluster.
Bei Warnend: Ein Client- oder Serverzertifikat für Kubelet läuft in weniger als sieben Tagen ab.
Bei Kritisch: Ein Client- oder Serverzertifikat für Kubelet läuft in weniger als einem Tag ab.
Sie müssen das Zertifikat erneuern.
Es gibt verschiedene semantische Versionen von Kubernetes-Komponenten. Dies kann als Folge eines fehlgeschlagenen Kubernetes-Upgrades auftreten.
Der Kubernetes API Server-Client weist mehr als 1 % an Fehlern auf. Möglicherweise gibt es ein Problem mit dem Knoten, auf dem dieser Client läuft, oder mit dem Kubernetes API-Server selbst.
Diese Warnung weist darauf hin, dass die Speicherauslastung auf dem Kubernetes-Knoten sehr hoch ist.
Wenn diese Warnung ausgelöst wird, versuchen Sie herauszufinden, welcher Pod mehr Speicher verbraucht.
Das Dateisystem auf einem bestimmten Knoten füllt sich. Stellen Sie mehr Speicherplatz zur Verfügung, indem Sie eine Festplatte hinzufügen oder nicht verwendete Datenträger einhängen.
Das RAID-Array ist aufgrund eines oder mehrerer Festplattenausfälle in einem schlechten Zustand. Die Anzahl der Ersatzlaufwerke
reicht nicht aus, um das Problem automatisch zu beheben.
Es liegt ein Problem mit der physischen Netzwerkschnittstelle auf dem Knoten vor. Wenn das Problem weiterhin besteht, muss sie möglicherweise ersetzt werden.
Der Knoten reagiert aufgrund eines Problems nicht mehr, das zu einer Unterbrechung der Kommunikation zwischen Knoten im Cluster führte.
Um dieses Problem zu beheben, starten Sie den betroffenen Knoten neu. Wenn das Problem weiterhin besteht, wenden Sie sich mit dem Supportpakettool an den UiPath®-Support.
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.
Die höhere Speichernutzungsrate ist im Dashboard Kubernetes/Persistent Volumes zu sehen:
Sie können es anpassen, indem Sie die Größe des PVC wie hier beschrieben ändern: Konfigurieren des Clusters.
Die Rate der erhöhten Speichernutzung ist im „Kubernetes/Computeressourcen/Pod“-Dashboard zu sehen.
Sie können sie anpassen, indem Sie die Prometheus-Speicherressourcenlimits in der Rancher-Monitoring-App über ArgoCD bearbeiten. Die Rancher-Monitoring-App wird nach dem Klicken auf Speichernautomatisch erneut synchronisiert.
Beachten Sie, dass Prometheus einige Zeit benötigt, um neu zu starten und wieder Metriken in Grafana anzuzeigen. Selbst bei großen Clustern dauert es in der Regel weniger als 10 Minuten.
Dies sind interne Alertmanager-Fehler für HA-Cluster mit mehreren Alertmanager-Replikaten. Warnungen können in unregelmäßigen Abständen erscheinen und wieder verschwinden. Eine vorübergehende Verkleinerung und dann eine Vergrößerung der Alertmanager-Replikate kann das Problem beheben.
Führen Sie die folgenden Schritte aus, um das Problem zu beheben:
-
Skalieren Sie auf Null. Beachten Sie, dass es einen Moment dauert, bis die Pods heruntergefahren werden:
kubectl scale statefulset -n cattle-monitoring-system alertmanager-rancher-monitoring-alertmanager --replicas=0
kubectl scale statefulset -n cattle-monitoring-system alertmanager-rancher-monitoring-alertmanager --replicas=0 -
Skalieren Sie zurück auf zwei:
kubectl scale statefulset -n cattle-monitoring-system alertmanager-rancher-monitoring-alertmanager --replicas=2
kubectl scale statefulset -n cattle-monitoring-system alertmanager-rancher-monitoring-alertmanager --replicas=2 -
Überprüfen Sie, ob die Alertmanager-Pods gestartet wurden und ob sie ausgeführt werden:
kubectl get po -n cattle-monitoring-system
kubectl get po -n cattle-monitoring-system
Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
PrometheusOperatorListErrors, PrometheusOperatorWatchErrors, PrometheusOperatorSyncFailed, PrometheusOperatorReconcileErrors, PrometheusOperatorNodeLookupErrors, PrometheusOperatorNotReady, PrometheusOperatorRejectedResources
Interne Fehler des Prometheus-Betreibers, der die Prometheus-Ressourcen kontrolliert. Prometheus selbst kann noch funktionsfähig sein, während diese Fehler vorhanden sind; dieser Fehler zeigt jedoch an, dass die Konfigurierbarkeit der Überwachung beeinträchtigt ist. Wenden Sie sich an den UiPath®-Support.
Prometheus konnte die Konfiguration nicht laden oder neu laden. Bitte überprüfen Sie alle benutzerdefinierten Prometheus-Konfigurationen auf Eingabefehler. Wenden Sie sich andernfalls an den UiPath®-Support.
PrometheusErrorSendingAlertsToSomeAlertmanagers, PrometheusErrorSendingAlertsToAnyAlertmanager, PrometheusNotConnectedToAlertmanagers
Die Verbindung von Prometheus zu AlertManager ist nicht fehlerfrei. Metriken können immer noch abgefragt werden und Grafana-Dashboards können sie immer noch anzeigen, aber es werden keine Warnungen ausgelöst. Überprüfen Sie jede benutzerdefinierte Konfiguration von AlertManager auf Eingabefehler und wenden Sie sich andernfalls an den UiPath®-Support.
PrometheusNotificationQueueRunningFull, PrometheusTSDBReloadsFailing, PrometheusTSDBCompactionsFailing, PrometheusNotIngestingSamples, PrometheusDuplicateTimestamps, PrometheusOutOfOrderTimestamps, PrometheusRemoteStorageFailures, PrometheusRemoteWriteBehind, PrometheusRemoteWriteDesiredShards
Interne Prometheus-Fehler, die Metriken angeben, werden möglicherweise nicht wie erwartet gesammelt. Wenden Sie sich bitte an den UiPath®-Support.
Das kann passieren, wenn es fehlerhafte Warnmeldungen gibt, die auf nicht vorhandenen Metriken oder einer falschen PromQL-Syntax basieren. Wenden Sie sich an den UiPath®-Support, wenn keine benutzerdefinierten Warnungen hinzugefügt wurden.
Prometheus kann nicht evaluieren, ob Warnungen ausgelöst werden sollten. Das kann passieren, wenn zu viele Warnungen vorhanden sind. Bitte entfernen Sie teure benutzerdefinierte Warnungsevaluierungen und/oder lesen Sie die Dokumentation zur Erhöhung des CPU-Limits für Prometheus. Wenden Sie sich an den UiPath®-Support, wenn keine benutzerdefinierten Warnungen hinzugefügt wurden.
UiPathAvailabilityHighTrafficUserFacing, UiPathAvailabilityHighTrafficBackend, UiPathAvailabilityMediumTrafficUserFacing, UiPathAvailabilityMediumTrafficBackend, UiPathAvailabilityLowTrafficUserFacing, UiPathAvailabilityLowTrafficBackend
Die Anzahl der http 500-Antworten von UiPath®-Diensten überschreitet einen bestimmten Schwellenwert.
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-infra/istio-configure-script-cronjob
befindet sich im Status „Angehalten“.
Um dieses Problem zu beheben, aktivieren Sie den Cronjob, indem Sie die folgenden Schritte ausführen:
export KUBECONFIG="/etc/rancher/rke2/rke2.yaml" && export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"
kubectl -n uipath-infra patch cronjob istio-configure-script-cronjob -p '{"spec":{"suspend":false}}'
epoch=$(date +"%s")
kubectl -n uipath-infra create job istio-configure-script-cronjob-manual-$epoch --from=cronjob/istio-configure-script-cronjob
kubectl -n uipath-infra wait --for=condition=complete --timeout=300s job/istio-configure-script-cronjob-manual-$epoch
kubectl get node -o wide
#Verify if all the IP's listed by the above command are part of output of below command
kubectl -n istio-system get svc istio-ingressgateway -o json | jq '.spec.externalIPs'
export KUBECONFIG="/etc/rancher/rke2/rke2.yaml" && export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"
kubectl -n uipath-infra patch cronjob istio-configure-script-cronjob -p '{"spec":{"suspend":false}}'
epoch=$(date +"%s")
kubectl -n uipath-infra create job istio-configure-script-cronjob-manual-$epoch --from=cronjob/istio-configure-script-cronjob
kubectl -n uipath-infra wait --for=condition=complete --timeout=300s job/istio-configure-script-cronjob-manual-$epoch
kubectl get node -o wide
#Verify if all the IP's listed by the above command are part of output of below command
kubectl -n istio-system get svc istio-ingressgateway -o json | jq '.spec.externalIPs'
Dieser Auftrag erhält das neueste Kerberos-Ticket vom AD-Server für die SQL-integrierte Authentifizierung. Fehler in diesem Auftrag würden dazu führen, dass die SQL Server-Authentifizierung fehlschlägt. Wenden Sie sich bitte an den UiPath®-Support.
Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 75 % überschritten hat und bei 85 % schreibgeschützt ist.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in CEPH, indem Sie einige ungenutzte Dataset in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz, indem Sie die Anweisungen in Ändern der PVC-Größe befolgen.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
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 ungenutzte Dataset in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz, indem Sie die Anweisungen in Ändern der PVC-Größe befolgen.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
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 ungenutzte Dataset in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz, indem Sie die Anweisungen in Ändern der PVC-Größe befolgen.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
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 oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz, indem Sie die Anweisungen in Ändern der PVC-Größe befolgen.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung gibt an, dass sich der Ceph-Speichercluster seit mehr als 10 Minuten im Fehlerzustand befindet.
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.
Diese Warnung gibt an, dass das Quorum des Speicherclusters niedrig ist.
Mehrere Mons arbeiten zusammen, um Redundanz bereitzustellen. Dies ist möglich, da jeder eine Kopie der Metadaten behält. Der Cluster wird mit 3 Mons bereitgestellt und erfordert, dass 2 oder mehr Mons aktiv sind, damit das Quorum und die Speichervorgänge ausgeführt werden können. Wenn das Quorum verloren geht, ist der Zugriff auf die Daten gefährdet.
Wenn diese Warnung ausgelöst wird, überprüfen Sie, ob sich OSDs im Beendigungsstatus befinden. Wenn das zutrifft, erzwingen Sie die Löschung dieser Pods und warten Sie einige Zeit, bis der Operator abgestimmt ist. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
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: Konfigurieren des Clusters.
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.
kubectl logs
im Istio-Ingress-Gateway-Pod ausführen. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den UiPath®-Support.
Diese Warnung gibt an, dass weniger als 3 Knoten im RabbitMQ-Cluster ausgeführt werden.
kubectl logs <pod-name> -n <namespace>
, welcher RabbitMQ-Pod inaktiv ist. Um das Problem zu beheben, löschen Sie den Pod mit dem Befehl kubectl delete pod <pod-name> -n <namespace>
und überprüfen Sie erneut, sobald der neue Pod erscheint.
Diese Warnung gibt an, dass das TLS-Zertifikat des Servers in den folgenden 30 Tagen abläuft.
Um dieses Problem zu beheben, aktualisieren Sie das TLS-Zertifikat des Servers. Anweisungen finden Sie unter Verwalten von Serverzertifikaten.
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.
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.
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.
Diese Warnung weist darauf hin, dass der etcd-Cluster nicht genügend Mitglieder hat. Beachten Sie, dass der Cluster eine ungerade Anzahl von Mitgliedern haben muss. Der Schweregrad dieser Warnung ist kritisch.
Stellen Sie sicher, dass es eine ungerade Anzahl von Serverknoten im Cluster gibt und alle betriebsbereit und fehlerfrei sind.
Diese Warnung zeigt an, dass der etcd-Cluster keinen Leader hat. Der Schweregrad dieser Warnung ist kritisch.
Diese Warnung gibt an, dass sich der etcd-Anführer innerhalb von 10 Minuten mehr als zweimal ändert. Dies ist eine Warnung.
Diese Warnung gibt an, dass ein bestimmter Prozentsatz der GRPC-Anforderungsfehler in etcd erkannt wurde.
Diese Warnung gibt an, dass etcd-GRPC-Anforderungen langsam sind. Dies ist eine Warnung.
Diese Warnung gibt an, dass ein bestimmter Prozentsatz der HTTP-Fehler in etcd erkannt wurde.
Diese Warnung weist darauf hin, dass HTTP-Anforderungen langsamer werden. Dies ist eine Warnung.
Diese Warnung weist darauf hin, dass sich die Kommunikation mit etcd-Mitgliedern verlangsamt. Dies ist eine Warnung.
Diese Warnung gibt an, dass der etcd-Server in der letzten Stunde mehr als 5 fehlgeschlagene Vorschläge erhalten hat. Dies ist eine Warnung.
Diese Warnung gibt an, dass die fsync-Dauer der etcd-WAL zunimmt. Dies ist eine Warnung.
/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.
/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.
Diese Warnung gibt an, dass der freie Speicherplatz für die Longhorn-Festplatte 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.
Diese Warnung weist darauf hin, dass die NFS-Serververbindung unterbrochen wurde.
Sie müssen die NFS-Serververbindung und den Mount-Pfad überprüfen.
Wenn die kumulierte Anzahl der von Longhorn erstellten Sicherungs- oder Snapshot-Objekte zu hoch ist, kann eine der folgenden Warnungen auftreten:
Um die Ursache dieser Warnungen zu beheben, führen Sie das folgende Skript aus:
#!/bin/bash
set -e
# longhorn backend URL
url=
# By default, snapshot older than 10 days will be deleted
days=-1
function display_usage() {
echo "usage: $(basename "$0") [-h] -u longhorn-url -d days"
echo " -u Longhorn URL"
echo " -d Number of days(should be >0). By default, script will delete snapshot older than 10 days."
echo " -h Print help"
}
while getopts 'hd:u:' flag "$@"; do
case "${flag}" in
u)
url=${OPTARG}
;;
d)
days=${OPTARG}
[ "$days" ] && [ -z "${days//[0-9]}" ] || { echo "Invalid number of days=$days"; exit 1; }
;;
h)
display_usage
exit 0
;;
:)
echo "Invalid option: ${OPTARG} requires an argument."
exit 1
;;
*)
echo "Unexpected option ${flag}"
exit 1
;;
esac
done
[[ -z "$url" ]] && echo "Missing longhorn URL" && exit 1
# check if URL is valid
curl -s --connect-timeout 30 ${url}/v1 >> /dev/null || { echo "Unable to connect to longhorn backend"; exit 1; }
echo "Deleting snapshots older than $days days"
# Fetch list of longhorn volumes
vols=$( (curl -s -X GET ${url}/v1/volumes |jq -r '.data[].name') )
#delete given snapshot for given volume
function delete_snapshot() {
local vol=$1
local snap=$2
[[ -z "$vol" || -z "$snap" ]] && echo "Error: delete_snapshot: Empty argument" && return 1
curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotDelete -d '{"name": "'$snap'"}' >> /dev/null
echo "Snapshot=$snap deleted for volume=$vol"
}
#perform cleanup for given volume
function cleanup_volume() {
local vol=$1
local deleted_snap=0
[[ -z "$vol" ]] && echo "Error: cleanup_volume: Empty argument" && return 1
# fetch list of snapshot
snaps=$( (curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotList | jq -r '.data[] | select(.usercreated==true) | .name' ) )
for i in ${snaps[@]}; do
echo $i
if [[ $i == "volume-head" ]]; then
continue
fi
# calculate date difference for snapshot
snapTime=$(curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotGet -d '{"name":"'$i'"}' |jq -r '.created')
currentTime=$(date "+%s")
timeDiff=$((($(date -d $snapTime "+%s") - $currentTime) / 86400))
if [[ $timeDiff -lt $days ]]; then
echo "Ignoring snapshot $i, since it is older than $timeDiff days"
continue
fi
#trigger deletion for snapshot
delete_snapshot $vol $i
deleted_snap=$((deleted_snap+1))
done
if [[ "$deleted_snap" -gt 0 ]]; then
#trigger purge for volume
curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotPurge >> /dev/null
fi
}
for i in ${vols[@]}; do
cleanup_volume $i
done
#!/bin/bash
set -e
# longhorn backend URL
url=
# By default, snapshot older than 10 days will be deleted
days=-1
function display_usage() {
echo "usage: $(basename "$0") [-h] -u longhorn-url -d days"
echo " -u Longhorn URL"
echo " -d Number of days(should be >0). By default, script will delete snapshot older than 10 days."
echo " -h Print help"
}
while getopts 'hd:u:' flag "$@"; do
case "${flag}" in
u)
url=${OPTARG}
;;
d)
days=${OPTARG}
[ "$days" ] && [ -z "${days//[0-9]}" ] || { echo "Invalid number of days=$days"; exit 1; }
;;
h)
display_usage
exit 0
;;
:)
echo "Invalid option: ${OPTARG} requires an argument."
exit 1
;;
*)
echo "Unexpected option ${flag}"
exit 1
;;
esac
done
[[ -z "$url" ]] && echo "Missing longhorn URL" && exit 1
# check if URL is valid
curl -s --connect-timeout 30 ${url}/v1 >> /dev/null || { echo "Unable to connect to longhorn backend"; exit 1; }
echo "Deleting snapshots older than $days days"
# Fetch list of longhorn volumes
vols=$( (curl -s -X GET ${url}/v1/volumes |jq -r '.data[].name') )
#delete given snapshot for given volume
function delete_snapshot() {
local vol=$1
local snap=$2
[[ -z "$vol" || -z "$snap" ]] && echo "Error: delete_snapshot: Empty argument" && return 1
curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotDelete -d '{"name": "'$snap'"}' >> /dev/null
echo "Snapshot=$snap deleted for volume=$vol"
}
#perform cleanup for given volume
function cleanup_volume() {
local vol=$1
local deleted_snap=0
[[ -z "$vol" ]] && echo "Error: cleanup_volume: Empty argument" && return 1
# fetch list of snapshot
snaps=$( (curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotList | jq -r '.data[] | select(.usercreated==true) | .name' ) )
for i in ${snaps[@]}; do
echo $i
if [[ $i == "volume-head" ]]; then
continue
fi
# calculate date difference for snapshot
snapTime=$(curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotGet -d '{"name":"'$i'"}' |jq -r '.created')
currentTime=$(date "+%s")
timeDiff=$((($(date -d $snapTime "+%s") - $currentTime) / 86400))
if [[ $timeDiff -lt $days ]]; then
echo "Ignoring snapshot $i, since it is older than $timeDiff days"
continue
fi
#trigger deletion for snapshot
delete_snapshot $vol $i
deleted_snap=$((deleted_snap+1))
done
if [[ "$deleted_snap" -gt 0 ]]; then
#trigger purge for volume
curl -s -X POST ${url}/v1/volumes/${vol}?action=snapshotPurge >> /dev/null
fi
}
for i in ${vols[@]}; do
cleanup_volume $i
done
Diese Warnung weist darauf hin, dass die kumulative Anzahl der von Longhorn im System erstellten Sicherungsobjekte zunimmt, was zu potenziellen Ausfallzeiten führen kann. Dies ist eine Warnung.
Diese Warnung wird ausgelöst, wenn die Anzahl der Longhorn-Sicherungen größer oder gleich 150 und kleiner als 200 ist.
Diese Warnung weist darauf hin, dass die kumulative Anzahl der von Longhorn im System erstellten Sicherungsobjekte zunimmt, was zu potenziellen Ausfallzeiten führen kann. Dies ist eine kritische Warnung.
Diese Warnung wird ausgelöst, wenn die Anzahl der Longhorn-Sicherungen größer oder gleich 200 und kleiner als 240 ist.
Diese Warnung weist darauf hin, dass die kumulative Anzahl der von Longhorn im System erstellten Snapshot-Objekte zunimmt, was zu potenziellen Ausfallzeiten führen kann. Dies ist eine Warnung.
Diese Warnung wird ausgelöst, wenn die Anzahl der Snapshots größer oder gleich 150 und kleiner als 200 ist.
Diese Warnung weist darauf hin, dass die kumulative Anzahl der von Longhorn im System erstellten Snapshot-Objekte zunimmt, was zu potenziellen Ausfallzeiten führen kann. Diese Warnung ist kritisch.
Diese Warnung wird ausgelöst, wenn die Anzahl der Snapshots größer oder gleich 200 und kleiner als 240 ist.
- Schlüssel zum Schweregrad der Warnung
- allgemeine.regeln
- TargetDown
- Watchdog
- kubernetes-apps
- KubePodCrashLooping
- KubePodNotReady
- KubeDeploymentGenerationMismatch, KubeStatefulSetGenerationMismatch
- KubeDeploymentReplicasMismatch, KubeStatefulSetReplicasMismatch
- KubeStatefulSetUpdateNotRolledOut
- KubeDaemonSetRolloutStuck
- KubeContainerWaiting
- KubeDaemonSetNotScheduled, KubeDaemonSetMisScheduled
- KubeJobCompletion
- KubeJobFailed
- KubeHpaReplicasMismatch
- KubeHpaMaxedOut
- kubernetes-resources
- KubeCPUOvercommit, KubeMemoryOvercommit
- KubeCPUQuotaOvercommit, KubeMemoryQuotaOvercommit, KubeQuotaAlmostFull, KubeQuotaFullyUsed, KubeQuotaExceeded
- CPUThrottlingHigh
- Kubernetes-storage
- KubePersistentVolumeFillingUp
- KubePersistentVolumeErrors
- kube-state-metrics
- KubeStateMetricsListErrors, KubeStateMetricsWatchErrors
- kubernetes-system-apiserver
- KubeClientCertificateExpiration
- AggregatedAPIErrors, AggregatedAPIDown, KubeAPIDown, KubeAPITerminatedRequests
- KubernetesApiServerErrors
- kubernetes-system-kubelet
- KubeNodeNotReady, KubeNodeUnreachable, KubeNodeReadinessFlapping, KubeletPlegDurationHigh, KubeletPodStartUpLatencyHigh, KubeletDown
- KubeletTooManyPods
- KubeletClientCertificateExpiration, KubeletServerCertificateExpiration
- KubeletClientCertificateRenewalErrors, KubeletServerCertificateRenewalErrors
- kubernetes-system
- KubeVersionMismatch
- KubeClientErrors
- KubernetesMemoryPressure
- KubernetesDiskPressure
- Kube-apiserver-slos
- KubeAPIErrorBudgetBurn
- node-exporter
- NodeFilesystemSpaceFillingUp, NodeFilesystemAlmostOutOfSpace, NodeFilesystemFilesFillingUp
- NodeRAIDDegraded
- NodeRAIDDiskFailure
- NodeNetworkReceiveErrs, NodeNetworkTransmitErrs, NodeHighNumberConntrackEntriesUsed
- NodeClockSkewDetected, NodeClockNotSynchronising
- node-network
- NodeNetworkInterfaceFlapping
- InternodeCommunicationBroken
- uipath.prometheus.resource.provisioning.alerts
- PrometheusMemoryUsage, PrometheusStorageUsage
- alertmanager.rules
- AlertmanagerConfigInconsistent
- AlertmanagerFailedReload
- prometheus-operator
- PrometheusOperatorListErrors, PrometheusOperatorWatchErrors, PrometheusOperatorSyncFailed, PrometheusOperatorReconcileErrors, PrometheusOperatorNodeLookupErrors, PrometheusOperatorNotReady, PrometheusOperatorRejectedResources
- Prometheus
- PrometheusBadConfig
- PrometheusErrorSendingAlertsToSomeAlertmanagers, PrometheusErrorSendingAlertsToAnyAlertmanager, PrometheusNotConnectedToAlertmanagers
- PrometheusNotificationQueueRunningFull, PrometheusTSDBReloadsFailing, PrometheusTSDBCompactionsFailing, PrometheusNotIngestingSamples, PrometheusDuplicateTimestamps, PrometheusOutOfOrderTimestamps, PrometheusRemoteStorageFailures, PrometheusRemoteWriteBehind, PrometheusRemoteWriteDesiredShards
- PrometheusRuleFailures
- PrometheusMissingRuleEvaluations
- PrometheusTargetLimitHit
- uipath.availability.alerts
- UiPathAvailabilityHighTrafficUserFacing, UiPathAvailabilityHighTrafficBackend, UiPathAvailabilityMediumTrafficUserFacing, UiPathAvailabilityMediumTrafficBackend, UiPathAvailabilityLowTrafficUserFacing, UiPathAvailabilityLowTrafficBackend
- uipath.cronjob.alerts.rules
- CronJobSuspended
- UiPath CronJob „kerberos-tgt-refresh“ fehlgeschlagen
- IdentityKerberosTgtUpdateFailed
- Ceph-Warnungen
- CephClusterNearFull
- CephClusterCriticallyFull
- CephClusterReadOnly
- CephPoolQuotaBytesCriticallyExhausted
- CephClusterErrorState
- CephMonQuorumAtRisk
- CephOSDCriticallyFull
- uipath.requestrouting.alerts
- UiPathRequestRouting
- RabbitmqNodeDown
- Server-TLS-Zertifikatwarnungen
- SecretCertificateExpiry30Days
- SecretCertificateExpiry7Days
- Warnungen zu Identitätstokensignaturzertifikaten
- IdentityCertificateExpiry30Days
- IdentityCertificateExpiry7Days
- Etdc-Warnungen
- EtcdInsufficientMembers
- EtcdNoLeader
- EtcdHighNumberOfLeaderChanges
- EtcdHighNumberOfFailedGrpcRequests
- EtcdGrpcRequestsSlow
- EtcdHighNumberOfFailedHttpRequests
- EtcdHttpRequestsSlow
- EtcdMemberCommunicationSlow
- EtcdHighNumberOfFailedProposals
- EtcdHighFsyncDurations
- EtcdHighCommitDurations
- Warnungen zur Datenträgergröße
- LowDiskForRancherPartition
- LowDiskForKubeletPartition
- LowDiskForLonghornPartition
- LowDiskForVarPartition
- Sicherungswarnungen
- NFSServerDisconnected
- VolumeBackupFailed
- BackupDisabled
- longhorn-snapshot-alert
- LonghornBackupObjectThresholdExceededWarn
- LonghornBackupObjectThresholdExceededCritical
- LonghornSnapshotObjectThresholdExceededWarn
- LonghornSnapshotObjectThresholdExceededCritical