- Überblick
- Anforderungen
- Installation
- Fragen und Antworten: Bereitstellungsvorlagen
- Herunterladen von Installationspaketen
- 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
- Verbinden einer Task Mining-Anwendung
- Hinzufügen eines dedizierten Agent-Knotens für Task Mining
- Nach der Installation
- Clusterverwaltung
- Überwachung und Warnungen
- Verwendung des Überwachungs-Stacks
- Warnungs-Runbooks
- Migration und Upgrade
- Online-Auswertungsmodus mit einem einzelnen Knoten
- Offline-Auswertungsmodus mit einem einzelnen Knoten
- HA-fähiger Online-Produktionsmodus mit mehreren Knoten
- HA-fähiger Offline-Produktionsmodus mit mehreren Knoten
- Migrieren einer physischen Longhorn-Festplatte zum LVM
- Herabstufen von Ceph von 16.2.6 auf 15.2.9
- Migrationsoptionen
- 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 deaktivieren Sie TLS 1.0 und 1.1
- 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
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- Deaktivieren von TX-Prüfsummen-Offloading
- 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
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Fehler nach der Zertifikatsaktualisierung
- Für die Automation Suite muss Backlog_wait_time festgelegt werden 1
- Anmeldung nach der Migration nicht mehr möglich
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- 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
- Der GSSAPI-Vorgang ist mit Fehler fehlgeschlagen: Es wurde ein ungültiger Statuscode übermittelt (Die Anmeldeinformationen des Clients wurden widerrufen).
- Die Anmeldung ist für den Benutzer <ADDOMAIN><aduser> fehlgeschlagen. Grund: Das Konto ist deaktiviert.
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag empfangen
- SSPI-Anbieter: Server nicht in Kerberos-Datenbank gefunden
- 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“.
- UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN
- Self-heal-operator und Sf-k8-utils-Repository fehlen
- Herabgestufte MongoDB- oder Geschäftsanwendungen nach der Clusterwiederherstellung
- Fehlerhafte Dienste nach Clusterwiederherstellung oder Rollback
- 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
Verwendung des Überwachungs-Stacks
Der Überwachungs-Stack für Automation Suite-Cluster umfasst Prometheus, Grafana und Alertmanager, die in der Benutzeroberfläche von Rancher Cluster Explorer integriert sind.
Knotenfehler können zu einem Herunterfahren von Kubernetes führen, wodurch Prometheus-Warnungen unterbrochen werden. Um das zu verhindern, empfehlen wir die Einrichtung einer separaten Warnung auf dem RKE2-Server.
Auf dieser Seite wird eine Reihe von Überwachungsszenarien beschrieben. Weitere Informationen finden Sie in der offiziellen Rancher-Dokumentation zur Verwendung von Rancher Monitoring.
Wenn Sie Sammler zum Exportieren von Metriken in Tools von Drittanbietern verwenden, kann die Aktivierung der Anwendungsüberwachung die Funktionalität der Automation Suite beeinträchtigen.
Überprüfen Sie im Dashboard Monitoring den unteren Bereich auf aktuelle Warnungen. Die folgenden Screenshots zeigen mehrere aktuell ausgelöste Warnungen.
Wenn Warnungen zu laut sind, können Sie sie stumm schalten. Führen Sie dazu die folgenden Schritte aus:
Es wird dringend empfohlen, einen externen Empfänger für Warnungen einzurichten. Auf diese Weise werden Warnungen während ihrer Ausführung gepusht, ohne dass Dashboard Monitoring aktualisiert werden muss, um die neuesten Warnungen anzuzeigen.
Weitere Informationen zum Senden von Warnungen an einen externen Empfänger finden Sie in der Rancher-Dokumentation unter Alertmanager Receiver Configuration.
Zusätzlich zu einem Empfänger müssen Sie mindestens einen Weg konfigurieren, der den Empfänger verwendet. Eine Route definiert, wie Warnungen gruppiert werden und welche Warnungen an den Empfänger gesendet werden. Weitere Informationen finden Sie in der Rancher-Dokumentation zur Alertmanager Route Configuration.
Nachfolgend finden Sie ein Beispiel dafür, wie die Warnungen angezeigt werden, wenn der Slack-Empfänger verwendet wird. Wenn Sie auf den Link zu AlertManager klicken, gelangen Sie zur AlertManager-Konsole, auf der Warnungen stumm geschaltet werden können und es weitere Links zum Prometheus-Ausdruck gibt, der die Warnung ausgelöst hat. Wenn Sie auf die Runbook-URL klicken, gelangen Sie auf diese Seite mit speziellen Lösungsschritten. Diese Links sind auch dann vorhanden, wenn Warnungen an andere externe Empfänger gesendet werden.
Klicken Sie im Dashboard Monitoring auf die Grafana-Kachel. Das Dashboard Grafana wird nun angezeigt.
Sie können das Istio Service Mesh über die folgenden Grafana-Dashboards überwachen: Istio Mesh und Istio Workload.
Dieses Dashboard zeigt das gesamte Anforderungsvolumen sowie die Häufigkeit von 400er und 500er Fehlern im gesamten Dienstgeflecht für den ausgewählten Zeitraum an. Die Daten werden in der oberen rechten Ecke des Fensters angezeigt. Diese Informationen finden Sie in den 4 Diagrammen oben.
Es zeigt auch die sofortige Erfolgsquote („Success Rate“) in den letzten Minuten für jeden einzelnen Dienst an. Beachten Sie, dass eine Success Rate von NaN angibt, dass der Dienst derzeit keinen Datenverkehr leistet.
Dieses Dashboard zeigt die Datenverkehrsmetriken über den ausgewählten Zeitbereich in der oberen rechten Ecke des Fensters an.
Verwenden Sie die Selektoren oben im Dashboard, um bei bestimmten Workloads einen Drilldown durchzuführen. Von besonderem Interesse ist der Namespace uipath.
Im oberen Abschnitt werden die Gesamtmetriken angezeigt, im Abschnitt Inbound Workloads wird der Datenverkehr basierend auf der Herkunft dargestellt und im Abschnitt Outbound Services wird Datenverkehr basierend auf dem Ziel dargestellt.
Sie können persistente Volumes über das Dashboard Kubernetes/Persistent Volumes überwachen. Sie können den freien und genutzten Platz für jedes Volume nachverfolgen.
Sie können auch den Status jedes Volumes überprüfen, indem Sie im Menü Storage des Cluster Explorer auf das Element PersistentVolumes klicken.
Um die Hardwarenutzung pro Knoten zu überprüfen, können Sie das Dashboard Nodes verwenden. Angaben zu CPU, Arbeitsspeicher, Datenträger und Netzwerk können angezeigt werden.
Sie können die Hardwarenutzung für bestimmte Workloads mithilfe des Dashboards Kubernetes / Compute Resources / Namespace (Workloads) überwachen. Wählen Sie den Namespace uipath aus, um die erforderlichen Daten abzurufen.
- Klicken Sie auf den abwärts zeigenden Pfeil neben dem Diagrammtitel und wählen Sie dann Share aus.
- Klicken Sie auf die Registerkarte Snapshot und legen Sie den Namen für Momentaufnahme Snapshot name, das Ablaufdatum Expire und Timeout fest.
- Klicken Sie zum Veröffentlichen auf Publish in snapshot.raintank.io.
Weitere Informationen finden Sie in der Grafana-Dokumentation zum Freigeben von Dashboards.
Weitere Informationen zum Erstellen benutzerdefinierter persistenter Grafana-Dashboards finden Sie in der Rancher-Dokumentation.
Administratorzugriff auf Grafana wird in der Regel nicht in Automation Suite-Clustern benötigt, da anonyme Benutzer standardmäßig Lesezugriff auf Dashboards haben und benutzerdefinierte persistente Dashboards anhand der oben in diesem Dokument verknüpften speziellen Kubernetes-Anweisungen erstellt werden müssen.
Dennoch ist der Administratorzugriff auf Grafana mit den nachfolgenden Schritten möglich.
Der Standardbenutzername und das Kennwort für den Grafana-Administratorzugriff können wie folgt abgerufen werden:
kubectl get secret -n cattle-monitoring-system rancher-monitoring-grafana -o jsonpath='{.data.admin-user}' | base64 -d && echo
kubectl get secret -n cattle-monitoring-system rancher-monitoring-grafana -o jsonpath='{.data.admin-password}' | base64 -d && echo
kubectl get secret -n cattle-monitoring-system rancher-monitoring-grafana -o jsonpath='{.data.admin-user}' | base64 -d && echo
kubectl get secret -n cattle-monitoring-system rancher-monitoring-grafana -o jsonpath='{.data.admin-password}' | base64 -d && echo
Beachten Sie, dass in Automation Suite-Clustern mit Hochverfügbarkeit mehrere Grafana-Pods vorhanden sind, um im Falle eines Knotenfehlers einen unterbrechungsfreien Lesezugriff sowie mehr Leseabfragen zu ermöglichen. Dies ist nicht mit dem Administratorzugriff kompatibel, da die Pods den Sitzungsstatus nicht freigeben und die Anmeldung dies erfordert. Um dies zu umgehen, muss die Anzahl der Grafana-Replikate vorübergehend auf 1 skaliert werden, solange der Administratorzugriff gewünscht wird. Nachfolgend finden Sie Anweisungen zum Skalieren der Anzahl der Grafana-Replikate:
# scale down
kubectl scale -n cattle-monitoring-system deployment/rancher-monitoring-grafana --replicas=1
# scale up
kubectl scale -n cattle-monitoring-system deployment/rancher-monitoring-grafana --replicas=2
# scale down
kubectl scale -n cattle-monitoring-system deployment/rancher-monitoring-grafana --replicas=1
# scale up
kubectl scale -n cattle-monitoring-system deployment/rancher-monitoring-grafana --replicas=2
Die Dokumentation zu den verfügbaren Metriken finden Sie hier:
Sie können benutzerdefinierte Warnungen mithilfe einer Prometheus-Abfrage mit einem booleschen Ausdruck erstellen.
Um den Status von Pods, Bereitstellungen, StatefulSets usw. zu sehen, können Sie die Benutzeroberfläche des Cluster Explorers verwenden. Dies ist die gleiche Landing-Page wie die, die nach der Anmeldung beim Rancher-Server-Endpunkt aufgerufen wird. Die Startseite zeigt eine Zusammenfassung mit Drilldowns in bestimmte Details für jeden Ressourcentyp auf der linken Seite. Beachten Sie den Namespace-Selektor oben auf der Seite. Dieses Dashboard kann auch durch das Tool „Lens“ ersetzt werden.
Prometheus verwendet die Remote-Write-Funktion von Prometheus, um Prometheus-Metriken zu sammeln und in ein externes System zu exportieren.
remote_write
in einem Automation Suite-Cluster:
- Zugriff auf das Rancher-Überwachungsdashboard
- Überprüfen aktuell ausgelöster Warnungen
- Stummschalten von Warnungen
- Senden von Warnungen an einen externen Empfänger
- Zugriff auf das Grafana-Dashboard
- Überwachen des Dienstgeflechts
- Istio Mesh-Dashboard
- Istio-Workload-Dashboard
- Überwachung persistenter Volumes
- Überwachung der Hardwarenutzung
- Erstellen einer gemeinsam nutzbaren visuellen Momentaufnahme eines Grafana-Diagramms
- Erstellen benutzerdefinierter persistenter Grafana-Dashboards
- Administratorzugriff auf Grafana
- Abfragen von Prometheus
- Erstellen benutzerdefinierter Warnungen
- Überwachung des Kubernetes-Ressourcenstatus
- Exportieren von Prometheus-Metriken in ein externes System