Ressources de dépannage

Cet article identifie des ressources de résolution des problèmes pour les services de données avec Azure Arc.

Chargements

Erreurs liées au chargement des journaux

Si vous avez déployé le contrôleur de données Azure Arc en mode de connexion direct en utilisant kubectl, et que vous n’avez pas créé de secret pour les informations d’identification de l’espace de travail Log Analytics, vous pouvez recevoir les messages d’erreur suivants dans la ressource personnalisée (CR) de contrôleur de données :

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

Pour résoudre l’erreur ci-dessus, créez un secret avec les informations d’identification WorkspaceID et SharedAccessKey de l’espace de travail Log Analytics, comme ci-dessous :

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

Erreurs liées au chargement des métriques en mode de connexion directe

Si vous avez configuré le chargement automatique des métriques en mode de connexion directe, et que les autorisations nécessaires pour le MSI n’ont pas été correctement accordées (comme décrit dans Charger les métriques), vous pouvez voir cette erreur dans vos journaux :

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

Pour résoudre l’erreur ci-dessus, récupérez le MSI de l’extension du contrôleur de données Azure Arc, puis accordez les rôles appropriés selon les instructions fournies dans Charger les métriques.

Erreurs liées au chargement des données d’utilisation en mode de connexion directe

Si vous avez déployé votre contrôleur de données Azure Arc en mode de connexion directe, les autorisations nécessaires pour charger vos informations d’utilisation sont automatiquement accordées pour le MSI de l’extension du contrôleur de données Azure Arc. Quand le processus de chargement automatique rencontre des problèmes d’autorisations, vous pouvez voir cette erreur dans vos journaux :

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

Pour résoudre le problème d’autorisations, récupérez le MSI et accordez les rôles appropriés, comme décrit dans Charger les métriques).

Mises à niveau

Étiquette d’image incorrecte

Si vous utilisez l’interface CLI az pour effectuer une mise à niveau et que vous transmettez une étiquette d’image incorrecte, une erreur s’affiche dans les deux minutes.

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

Lorsque vous affichez les pods, vous voyez l’état du travail de démarrage en tant que ErrImagePull.

STATUS
ErrImagePull

Quand vous décrivez le pod, vous voyez

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

Pour résoudre ce problème, référencez le journal des versions pour l’étiquette d’image correcte. Réexécutez la commande de mise à niveau avec l’étiquette d’image correcte.

Impossible de se connecter au registre ou au référentiel

Si vous essayez de mettre à niveau et que le travail de mise à niveau n’a pas généré d’erreur, mais qu’il s’exécute pendant plus de quinze minutes, vous pouvez afficher la progression de la mise à niveau en regardant les pods. Exécuter

kubectl get pods -n <namespace>

Lorsque vous affichez les pods, vous voyez l’état du travail de démarrage en tant que ErrImagePull.

STATUS
ErrImagePull

Décrivez le pod de travail de démarrage pour afficher les événements.

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

Quand vous décrivez le pod, vous voyez une erreur indiquant

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

Cela est courant si votre image a été déployée à partir d’un registre privé, que vous utilisez Kubernetes pour effectuer une mise à niveau via un fichier yaml et que ce fichier yaml référence mcr.microsoft.com à la place du registre privé. Pour résoudre ce problème, annulez le travail de mise à niveau. Pour rechercher le registre à partir duquel vous avez effectué le déploiement, exécutez

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

Recherchez Containers.controller.Image, où vous verrez le registre et le référentiel. Capturez ces valeurs, entrez-les dans votre fichier yaml et réexécutez la mise à niveau.

Ressources insuffisantes

Si vous essayez de mettre à niveau et que le travail de mise à niveau n’a pas généré d’erreur, mais qu’il s’exécute pendant plus de quinze minutes, vous pouvez afficher la progression de la mise à niveau en regardant les pods. Exécuter

kubectl get pods -n <namespace>

Recherchez un pod qui montre que certains conteneurs sont prêts, mais pas, par exemple, ce pod metricsdb-0 n’a qu’un des deux conteneurs :

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

Décrivez le pod pour afficher les événements.

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

S’il n’y a pas d’événements, obtenez les noms des conteneurs et affichez les journaux des conteneurs.

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

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

Si vous voyez un message concernant des ressources de processeur ou de mémoire insuffisantes, vous devez ajouter d’autres nœuds à votre cluster Kubernetes, ou ajouter d’autres ressources à vos nœuds existants.

Ressources par type

Scénario : Résolution des problèmes liés aux serveurs PostgreSQL

Afficher les journaux et les métriques à l’aide de Kibana et Grafana

Contenu connexe

Scénario : Afficher l'inventaire de vos instances dans le portail Azure