Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article identifie des ressources de résolution des problèmes pour les services de données avec Azure Arc.
Uploads
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
If you configured automatic upload of metrics, in the direct connected mode and the permissions needed for the MSI have not been properly granted (as described in Upload metrics), you might see an error in your logs as follows:
'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."}}
To resolve above error, retrieve the MSI for the Azure Arc data controller extension, and grant the required roles as described in Upload metrics.
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 liés aux autorisations, vous pouvez voir une 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.\"}}"}
To resolve the permissions issue, retrieve the MSI and grant the required roles as described in Upload metrics).
Upgrades
É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
To resolve, reference the Version log for the correct image tag. 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. Run
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. Run
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
Afficher les journaux et les métriques à l’aide de Kibana et Grafana
Related content
Scénario : Afficher l'inventaire de vos instances dans le portail Azure