Compartilhar via


Solução de problemas de recursos

Este artigo identifica recursos de solução de problemas para os serviços de dados habilitados para Azure Arc.

Uploads

Se você implantou o controlador de dados do Azure Arc no modo de conectividade direct usando kubectl e não criou um segredo para as credenciais do workspace do Log Analytics, você pode receber as seguintes mensagens de erro no CR do Controlador de Dados (Recurso Personalizado):

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

Para resolver o erro acima, crie um segredo com as credenciais do workspace do Log Analytics contendo WorkspaceID e SharedAccessKey conforme a seguir:

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 você configurou o carregamento automático de métricas, no modo de conexão direta e as permissões necessárias para o MSI não foram concedidas corretamente (conforme descrito em Carregar métricas), você pode receber um erro em seus logs conforme a seguir:

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

Para resolver o erro acima, recupere a MSI para a extensão do controlador de dados do Azure Arc e conceda as funções necessárias, conforme descrito no Carregar métricas.

Se você implantou o controlador de dados do Azure Arc no modo de conexão direta, as permissões necessárias para fazer o carregamento das informações de uso serão concedidas automaticamente para a MSI da extensão do controlador de dados do Azure Arc. Se o processo de carregamento automático encontrar problemas relacionados a permissões, você pode receber um erro em seus logs conforme a seguir:

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

Para resolver o problema de permissões, recupere a MSI e conceda as funções necessárias conforme descrito em Carregar métricas).

Atualizações

Marca de imagem incorreta

Se você estiver usando a CLI az para a atualização e transmitir uma marca de imagem incorreta, verá um erro em dois minutos.

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

Ao exibir os pods, você verá o status do trabalho de inicialização como ErrImagePull.

STATUS
ErrImagePull

Quando você descrever o pod, verá

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

Para resolver, confira o Log de versão e busque a marca de imagem correta. Execute novamente o comando de atualização com a marca de imagem correta.

Não foi possível conectar-se ao registro ou repositório

Se você estiver realizando a atualização e o trabalho de atualização não tiver gerado um erro, mas estiver sendo executado por mais de quinze minutos, veja o progresso da atualização nos pods. Executar

kubectl get pods -n <namespace>

Ao exibir os pods, você verá o status do trabalho de inicialização como ErrImagePull.

STATUS
ErrImagePull

Descreva o pod do trabalho de inicialização para exibir os eventos.

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

Ao descrever o pod, você verá um erro que diz

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

Isso é comum quando sua imagem foi implantada por meio de um registro privado, você está usando o Kubernetes para a atualização por meio de um arquivo yaml e o arquivo yaml faz referência a mcr.microsoft.com em vez de ao registro privado. Para resolver o problema, cancele o trabalho de atualização. Para encontrar o registro de origem da implantação, execute

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

Procure Containers.controller.Image, onde você verá o registro e o repositório. Capture esses valores, insira-os no arquivo yaml e execute novamente a atualização.

Não há recursos suficientes

Se você estiver realizando a atualização e o trabalho de atualização não tiver gerado um erro, mas estiver sendo executado por mais de quinze minutos, veja o progresso da atualização nos pods. Executar

kubectl get pods -n <namespace>

Procure um pod que mostre que alguns dos contêineres estão prontos, o que não é verdade, Por exemplo, o pod metricsdb-0 tem apenas um dos dois seguintes contêineres:

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

Descreva o pod para ver os eventos.

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

Se não houver eventos, obtenha os nomes dos contêineres e exiba os logs deles.

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

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

Se você vir uma mensagem sobre CPU ou memória insuficiente, adicione mais nós ao cluster do Kubernetes ou mais recursos aos nós existentes.

Recursos por tipo

Cenário: solução de problemas de servidores PostgreSQL

Exibir logs e métricas usando Kibana e Grafana

Cenário: exibir o estoque das instâncias no portal do Azure