Condividi tramite

Risorse per la risoluzione dei problemi

  • Articolo

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

Caricamenti

Se il controller dei dati di Azure Arc è stato distribuito con la modalità di connessione direct tramite kubectl e non è stato creato un segreto per le credenziali dell'area di lavoro Log Analytics, è possibile che vengano visualizzati i messaggi di errore seguenti nella risorsa personalizzata (CR) del controller dei dati:

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

Se è stato configurato il caricamento automatico delle metriche nella modalità di connessione diretta e le autorizzazioni necessarie per il certificato MSI non sono state concesse correttamente (come descritto in Caricare le metriche), è possibile che nei log venga visualizzato un errore simile al seguente:

'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 il certificato MSI dell'estensione del controller dei dati di Azure Arc e concedere i ruoli necessari come descritto in Caricare le metriche.

Se il controller dei dati di Azure Arc è stato distribuito con la modalità di connessione diretta, vengono concesse automaticamente le autorizzazioni necessarie per caricare le informazioni di utilizzo per il certificato MSI dell'estensione del controller dei dati di Azure Arc. Se l'esecuzione del processo di caricamento automatico restituisce problemi correlati alle autorizzazioni, nei log è possibile che venga visualizzato un errore simile al seguente:

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 relativo alle autorizzazioni, recuperare il certificato MSI e assegnare 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 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 l'output seguente:

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 immagine corretto.

Impossibile collegarsi al registro o al repository

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

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 l'output seguente:

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

Questo comportamento è comune se l'immagine è stata distribuita da un registro privato, si usa Kubernetes per eseguire l'aggiornamento tramite un file yaml e il file yaml fa riferimento a mcr.microsoft.com anziché al registro privato. Per risolvere il problema, annullare il processo di aggiornamento. Per trovare il registro di sistema da cui è stata eseguita la distribuzione, eseguire:

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

Cercare Containers.controller.Image, dove sono indicati il registro e il repository. Acquisire questi valori, immetterli nel file yaml ed eseguire di nuovo l'aggiornamento.

Risorse insufficienti

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

kubectl get pods -n <namespace>

Cercare un pod con contenitori pronti, ma alcuni dei quali non lo sono, ad esempio il 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 relativi log.

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