Risorse per la risoluzione dei problemi

Questo articolo identifica le risorse per la risoluzione dei problemi relativi ai servizi dati abilitati per Azure Arc.

Carica

Log Errori correlati al caricamento

Se il controller dati di Azure Arc è stato distribuito nella direct modalità di connettività usando kubectle non è stato creato un segreto per le credenziali dell'area di lavoro Log Analytics, è possibile che vengano visualizzati i messaggi di errore seguenti nel controller di dati CR (risorsa personalizzata):

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."
                    },

Per risolvere l'errore precedente, creare un segreto con le credenziali dell'area di lavoro Log Analytics contenenti WorkspaceID e SharedAccessKey come indicato di seguito:

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

Metriche caricano gli errori correlati in modalità connessa diretta

Se è stato configurato il caricamento automatico delle metriche, nella modalità connessa diretta e le autorizzazioni necessarie per l'identità del servizio gestito non sono state concesse correttamente (come descritto in Caricare le metriche), è possibile che venga visualizzato un errore nei log come indicato di seguito:

'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."}}

Per risolvere l'errore precedente, recuperare l'identità del servizio gestito per l'estensione del controller dati di Azure Arc e concedere i ruoli necessari come descritto in Caricare le metriche.

Errori correlati al caricamento dell'utilizzo in modalità connessa diretta

Se il controller dati di Azure Arc è stato distribuito nella modalità connessa diretta, vengono concesse automaticamente le autorizzazioni necessarie per caricare le informazioni di utilizzo per l'estensione del controller dati di Azure Arc. Se il processo di caricamento automatico si verifica in problemi correlati alle autorizzazioni, è possibile che venga visualizzato un errore nei log come indicato di seguito:

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.\"}}"}

Per risolvere il problema delle autorizzazioni, recuperare l'identità del servizio gestito e concedere i ruoli necessari come descritto in Caricare le metriche.

Aggiornamenti

Tag immagine non corretto

Se si usa l'interfaccia della riga di comando az per eseguire l'aggiornamento e si passa un tag di immagine non corretto, verrà visualizzato un errore entro due minuti.

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).

Quando si visualizzano i pod, lo stato del processo bootstrap viene visualizzato come ErrImagePull.

STATUS
ErrImagePull

Quando si descrive il pod, verrà visualizzato

Failed to pull image "<registry>/<repository>/arc-bootstrapper:<incorrect image tag>": [rpc error: code = NotFound desc = failed to pull and unpack image 

Per risolvere il problema, fare riferimento al log della versione per il tag immagine corretto. Eseguire di nuovo il comando di aggiornamento con il tag di immagine corretto.

Impossibile connettersi al Registro di sistema o al repository

Se si sta tentando di eseguire l'aggiornamento e il processo di aggiornamento non ha generato un errore ma viene eseguito per più di quindici minuti, è possibile visualizzare lo stato di avanzamento dell'aggiornamento osservando i pod. Esegui

kubectl get pods -n <namespace>

Quando si visualizzano i pod, lo stato del processo bootstrap viene visualizzato come ErrImagePull.

STATUS
ErrImagePull

Descrivere il pod del processo bootstrap per visualizzare gli eventi.

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

Quando si descrive il pod, verrà visualizzato un errore

failed to resolve reference "<registry>/<repository>/arc-bootstrapper:<image tag>"

Questa operazione è comune se l'immagine è stata distribuita da un registro privato, si usa Kubernetes per eseguire l'aggiornamento tramite un file yaml e i riferimenti al file yaml mcr.microsoft.com anziché al Registro di sistema privato. Per risolvere il problema, annullare il processo di aggiornamento. Per trovare il Registro di sistema da cui è stata distribuita, eseguire

kubectl describe pod <controller in format control-XXXXX> -n <namespace>

Cercare Containers.controller.Image, in cui verrà visualizzato il Registro di sistema e il repository. Acquisire questi valori, immettere nel file yaml ed eseguire di nuovo l'aggiornamento.

Risorse non sufficienti

Se si sta tentando di eseguire l'aggiornamento e il processo di aggiornamento non ha generato un errore ma viene eseguito per più di quindici minuti, è possibile visualizzare lo stato di avanzamento dell'aggiornamento osservando i pod. Esegui

kubectl get pods -n <namespace>

Cercare un pod che mostra alcuni contenitori pronti, ma non , ad esempio, questo pod metricsdb-0 ha solo uno dei due contenitori:

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

Descrivere il pod per visualizzare gli eventi.

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

Se non sono presenti eventi, ottenere i nomi dei contenitori e visualizzare i log per i contenitori.

kubectl get pods <pod name> -n <namespace> -o jsonpath='{.spec.containers[*].name}*'

kubectl logs <pod name> <container name> -n <namespace>

Se viene visualizzato un messaggio relativo a CPU o memoria insufficiente, è consigliabile aggiungere altri nodi al cluster Kubernetes o aggiungere altre risorse ai nodi esistenti.

Risorse per tipo

Scenario: Risoluzione dei problemi dei server PostgreSQL

Visualizzare log e metriche con Kibana e Grafana

Contenuto correlato

Scenario: visualizzare l'inventario delle istanze nel portale di Azure