Problembehandlung bei Ressourcen
In diesem Artikel werden Ressourcen für die Problembehandlung bei Azure Arc-fähigen Datendiensten beschrieben.
Uploads
Fehler im Zusammenhang mit dem Protokollupload
Wenn Sie Azure Arc-Datencontroller im Konnektivitätsmodus direct
mithilfe von kubectl
bereitgestellt und kein Geheimnis für die Anmeldeinformationen des Log Analytics-Arbeitsbereichs erstellt haben, werden in der benutzerdefinierten Ressource des Datencontrollers möglicherweise die folgenden Fehlermeldungen angezeigt:
status": {
"azure": {
"uploadStatus": {
"logs": {
"lastUploadTime": "YYYY-MM-HHTMM:SS:MS.SSSSSSZ",
"message": "spec.settings.azure.autoUploadLogs is true, but failed to get log-workspace-secret secret."
},
Erstellen Sie zum Beheben des obigen Fehlers wie folgt ein Geheimnis mit den Anmeldeinformationen des Log Analytics-Arbeitsbereichs, die WorkspaceID
und SharedAccessKey
enthalten:
apiVersion: v1
data:
primaryKey: <base64 encoding of Azure Log Analytics workspace primary key>
workspaceId: <base64 encoding of Azure Log Analytics workspace Id>
kind: Secret
metadata:
name: log-workspace-secret
namespace: <your datacontroller namespace>
type: Opaque
Fehler im Zusammenhang mit dem Metrikupload im direkten Verbindungsmodus
Wenn Sie den automatischen Upload von Metriken im direkten Verbindungsmodus konfiguriert haben und die für die MSI erforderlichen Berechtigungen nicht ordnungsgemäß gewährt wurden (wie unter Hochladen von Metriken in Azure Monitor beschrieben), wird möglicherweise der folgende Fehler in Ihren Protokollen angezeigt:
'Metric upload response: {"error":{"code":"AuthorizationFailed","message":"Check Access Denied Authorization for AD object XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX over scope /subscriptions/XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX/resourcegroups/my-resource-group/providers/microsoft.azurearcdata/sqlmanagedinstances/arc-dc, User Tenant Id: XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX. Microsoft.Insights/Metrics/write was not allowed, Microsoft.Insights/Telemetry/write was notallowed. Warning: Principal will be blocklisted if the service principal is not granted proper access while it hits the GIG endpoint continuously."}}
Rufen Sie zum Beheben des obigen Fehlers die MSI für die Azure Arc-Datencontrollererweiterung ab, und gewähren Sie die erforderlichen Rollen wie unter Hochladen von Metriken in Azure Monitor beschrieben.
Fehler im Zusammenhang mit dem Nutzungsupload im direkten Verbindungsmodus
Wenn Sie Ihren Azure Arc-Datencontroller im direkten Verbindungsmodus bereitgestellt haben, werden die erforderlichen Berechtigungen zum Hochladen Ihrer Nutzungsinformationen automatisch für die Erweiterungs-MSI des Azure Arc-Datencontrollers gewährt. Wenn beim automatischen Hochladen Probleme im Zusammenhang mit Berechtigungen auftreten, wird in den Protokollen eine Fehlermeldung wie die folgende angezeigt:
identified that your data controller stopped uploading usage data to Azure. The error was:
{"lastUploadTime":"2022-05-05T20:10:47.6746860Z","message":"Data controller upload response: {\"error\":{\"code\":\"AuthorizationFailed\",\"message\":\"The client 'XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX' with object id 'XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX' does not have authorization to perform action 'microsoft.azurearcdata/datacontrollers/write' over scope '/subscriptions/XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX/resourcegroups/my-resource-group/providers/microsoft.azurearcdata/datacontrollers/arc-dc' or the scope is invalid. If access was recently granted, please refresh your credentials.\"}}"}
Um das Problem mit den Berechtigungen zu beheben, rufen Sie die MSI ab, und weisen Sie die erforderlichen Rollen zu wie unter Hochladen von Metriken in Azure Monitor beschrieben.
Upgrades
Falsches Imagetag
Wenn Sie az
CLI zum Upgraden verwenden und ein falsches Imagetag übergeben, wird innerhalb von zwei Minuten ein Fehler angezeigt.
Job Still Active : Failed to await bootstrap job complete after retrying for 2 minute(s).
Failed to await bootstrap job complete after retrying for 2 minute(s).
Wenn Sie die Pods anzeigen, wird der Status des Bootstrapauftrags als ErrImagePull
angezeigt.
STATUS
ErrImagePull
Wenn Sie den Pod beschreiben, sehen Sie
Failed to pull image "<registry>/<repository>/arc-bootstrapper:<incorrect image tag>": [rpc error: code = NotFound desc = failed to pull and unpack image
Um das Problem zu beheben, suchen Sie im Versionsprotokoll das richtige Imagetag. Führen Sie den Upgradebefehl erneut mit dem richtigen Imagetag aus.
Eine Verbindung mit der Registrierung oder dem Repository kann nicht hergestellt werden.
Wenn Sie versuchen, ein Upgrade auszuführen, wobei der Upgradeauftrag keinen Fehler erzeugt hat, aber länger als fünfzehn Minuten ausgeführt wird, können Sie den Fortschritt des Upgrades anzeigen, indem Sie die Pods beobachten. Ausführung
kubectl get pods -n <namespace>
Wenn Sie die Pods anzeigen, wird der Status des Bootstrapauftrags als ErrImagePull
angezeigt.
STATUS
ErrImagePull
Beschreiben Sie den Pod des Bootstrapauftrags zum Anzeigen der Ereignisse.
kubectl describe pod <pod name> -n <namespace>
Wenn Sie den Pod beschreiben, wird ein Fehler angezeigt, der besagt
failed to resolve reference "<registry>/<repository>/arc-bootstrapper:<image tag>"
Dies ist gängig, wenn Ihr Image aus einer privaten Registrierung bereitgestellt wurde, Sie Kubernetes zum Upgraden über eine yaml-Datei verwenden, und die yaml-Datei auf „mcr.microsoft.com“ anstelle der privaten Registrierung verweist. Um das Problem zu beheben, brechen sie den Upgradeauftrag ab. Um die von Ihnen bereitgestellte Registrierung zu finden, führen Sie Folgendes aus
kubectl describe pod <controller in format control-XXXXX> -n <namespace>
Suchen Sie nach „Containers.controller.Image“, worin die Registrierung und das Repository angezeigt werden. Erfassen Sie diese Werte, geben Sie sie in Ihre yaml-Datei ein, und führen Sie das Upgrade erneut aus.
Nicht genügend Ressourcen
Wenn Sie versuchen, ein Upgrade auszuführen, wobei der Upgradeauftrag keinen Fehler erzeugt hat, aber länger als fünfzehn Minuten ausgeführt wird, können Sie den Fortschritt des Upgrades anzeigen, indem Sie die Pods beobachten. Ausführung
kubectl get pods -n <namespace>
Suchen Sie nach einem Pod, der einige der Container als bereit anzeigt, aber nicht z. B. diesen „metricsdb-0“-Pod, der nur einen von zwei Containern enthält:
NAME READY STATUS RESTARTS AGE
bootstrapper-848f8f44b5-7qxbx 1/1 Running 0 16m
control-7qxw8 2/2 Running 0 16m
controldb-0 2/2 Running 0 16m
logsdb-0 3/3 Running 0 18d
logsui-hvsrm 3/3 Running 0 18d
metricsdb-0 1/2 Running 0 18d
Beschreiben Sie den Pod zum Anzeigen von Ereignissen.
kubectl describe pod <pod name> -n <namespace>
Wenn keine Ereignisse vorhanden sind, rufen Sie die Containernamen ab, und zeigen Sie die Protokolle für die Container an.
kubectl get pods <pod name> -n <namespace> -o jsonpath='{.spec.containers[*].name}*'
kubectl logs <pod name> <container name> -n <namespace>
Wenn eine Meldung über unzureichende CPU oder zu wenig Arbeitsspeicher angezeigt wird, sollten Sie Ihrem Kubernetes-Cluster weitere Knoten hinzufügen oder Ihren vorhandenen Knoten weitere Ressourcen hinzufügen.
Ressourcen nach Typ
Szenario: Problembehandlung für PostgreSQL-Server
Anzeigen von Protokollen und Metriken mithilfe von Kibana und Grafana
Zugehöriger Inhalt
Szenario: Anzeigen des Bestands Ihrer Instanzen im Azure-Portal