Utiliser Resource Health pour résoudre des problèmes de connectivité avec Azure SQL Database

S’applique à : Azure SQL Database

Resource Health pour Azure SQL Database vous aide à diagnostiquer les problèmes et à accéder au support quand un problème Azure a une incidence sur vos ressources. Il vous informe de l’intégrité (actuelle et passée) de vos ressources et vous aide à atténuer les problèmes. La page Resource Health propose un support technique dès lors que vous êtes confronté à des problèmes de service Azure et que vous avez besoin d’aide.

Une capture d’écran du Portail Azure montrant la page Resource Health d’une base de données Azure SQL Database.

Contrôles d'intégrité

Resource Health détermine l’intégrité de votre SQL Database en examinant la réussite et les échecs des connexions à la ressource. Actuellement, Resource Health pour votre ressource SQL Database examine uniquement les échecs de connexion dus à une erreur système et non à une erreur utilisateur. L’état d’intégrité est mis à jour toutes les une à deux minutes.

États d'intégrité

Disponible

Le statut Disponible signifie que Resource Health n’a pas détecté d’échecs de connexion en raison d’erreurs système sur votre base de données SQL ou qu’il y avait des échecs de connexion, mais qu’ils ne respectaient pas le seuil d’alerte. Les sections suivantes fournissent plus de détails sur le seuil d'alerte.

Une capture d’écran du Portail Azure montrant le message d’état Disponible.

Dégradé

Un statut Dégradé signifie que, dans deux des trois dernières minutes, Resource Health a détecté :

  • une majorité de connexions réussies, mais il y a eu plusieurs échecs de connexion (dus à des erreurs système), ou
  • plusieurs échecs de connexion (dus à des erreurs système), mais moins de six tentatives de connexion au total.

Il s’agit probables erreurs de connexion temporaires. Pour réduire l’impact des problèmes de connexion dus à des erreurs de connexion temporaires, implémentez une logique de nouvelle tentative dans votre code.

Une capture d’écran du Portail Azure montrant le message d’état Dégradé.

Indisponible

L’état Non disponible signifie que Resource Health a détecté qu’il y avait plus de cinq tentatives de connexion au cours de la dernière minute, et que plus d'un quart d'entre elles ont échoué pour des raisons liées au système. Si votre ressource reste dans cet état pendant une période prolongée, contactez le Support Microsoft.

Une capture d’écran du Portail Azure montrant le message d’état Indisponible.

Inconnu

L’état d’intégrité Inconnu indique que Resource Health n’a reçu aucune information sur cette ressource depuis plus de 10 minutes. Même si cet état n’est pas une indication définitive de l’état de la ressource, il s’agit d’un point de données important dans le processus de dépannage. Si la ressource fonctionne comme prévu, son état devient Disponible après quelques minutes. Si vous rencontrez des problèmes avec la ressource, l’état d’intégrité Inconnu peut suggérer qu’un événement de la plateforme influe sur la ressource.

Une capture d’écran du Portail Azure montrant le message d’état Inconnu.

Heure de l’alerte

L’heure indiquée par l’alerte Resource Health ne correspond pas aux heures des échecs de connexion qui ont provoqué l’alerte. Cela est dû au fait qu’il faut plusieurs minutes pour que les données de télémétrie soient collectées et analysées, afin de déterminer qu’il existe un problème Resource Health. Ainsi, l’heure indiquée dans l’alerte Resource Health sera de plusieurs minutes après l'échec de la connexion.

En outre, l'intervalle de temps pendant lequel les échecs de connexion se sont produits peut souvent être plus court que l'intervalle de temps indiqué dans l'alerte Resource Health.

Informations d’historique

Vous pouvez accéder à 30 jours maximum d’historique de l’intégrité dans la section Historique de l’intégrité de Resource Health. La section contient également la raison du temps d’arrêt (le cas échéant). Actuellement, Azure indique le temps d’arrêt de votre ressource de base de données avec une granularité de deux minutes. Le temps d’arrêt réel est probablement inférieur à une minute. La moyenne est de huit secondes.

Raisons des temps d’arrêt

En cas de temps d’arrêt de votre base de données, une analyse est effectuée pour en déterminer la cause. Lorsqu’elle est disponible, la raison du temps d’arrêt est signalée dans la section Historique de l’intégrité de Resource Health. Les raisons des temps d’arrêt sont généralement publiées 45 minutes après un événement.

Sélectionner une fenêtre de maintenance

Vous pouvez configurer votre fenêtre de maintenance pour rendre les événements de maintenance importants prévisibles et moins perturbants pour votre charge de travail. La fonctionnalité de fenêtre de maintenance vous aide à planifier les mises à niveau prévisibles ou la maintenance planifiée. Les notifications préalables sont disponibles pour les bases de données configurées pour utiliser une fenêtre de maintenance autre que celle par défaut. Les notifications préalables permettent aux clients de configurer des notifications à envoyer jusqu’à 24 heures à l’avance de tout événement planifié.

Maintenance planifiée

L’infrastructure Azure effectue régulièrement une maintenance planifiée (mise à niveau des composants matériels ou logiciels dans le centre de données). Pendant la maintenance de la base de données, Azure SQL peut mettre fin à des connexions existantes et en refuser de nouvelles. Les échecs de connexion rencontrés pendant une maintenance planifiée sont généralement temporaires. Une logique de nouvelle tentative pour les erreurs réseau occasionnelles permet d’en réduire l’impact. Si vous êtes toujours confronté à des erreurs de connexion, contactez le support technique.

Reconfiguration

Les reconfigurations sont considérées comme des conditions transitoires et prévues de temps à autre. Ces événements peuvent être déclenchés par les échecs d’équilibrage de charge ou de logiciel/matériel. Toute application de production client qui se connecte à une base de données cloud doit implémenter une logique de nouvelle tentative pour les erreurs temporaires de connexion robuste, qui aide à remédier à ces situations et rend généralement les erreurs transparentes pour l’utilisateur final.