Cloud Monitor:Présentation

Qu'est-ce qu'un seuil dynamique ?

Les seuils dynamiques appliquent des algorithmes d'apprentissage automatique pour identifier dynamiquement les caractéristiques des modèles de données historiques, tels que la périodicité, la tendance et la fluctuation des métriques. Ils intègrent les métriques de services cloud spécifiques afin de calculer automatiquement les limites de seuil supérieures et inférieures pour chaque instance.

Limites

La fonctionnalité d'alerte basée sur un seuil dynamique est en aperçu sur invitation. Pour l'utiliser, soumettez un ticket.

Scénarios

Les caractéristiques statistiques des métriques des ressources cloud, telles que l'utilisation des ressources, les variations périodiques et les fluctuations de variance, diffèrent selon les scénarios métier. Par exemple, si votre trafic est intense le jour et faible la nuit, les métriques telles que le trafic de passerelle et l'accumulation de messages ApsaraMQ d'une instance Elastic Compute Service (ECS) ou d'un nom de domaine Alibaba Cloud CDN afficheront respectivement des valeurs de pointe et des valeurs creuses. Les services à forte intensité d'E/S et les tâches à forte intensité de calcul génèrent des seuils différents pour l'utilisation du processeur ou la charge (load.1m, load.5m et load.15m) sur différentes instances ECS.

Les seuils d'alerte sont fixes pour les règles d'alerte à métrique unique, ce qui ne convient pas aux scénarios métier complexes mentionnés précédemment. Il en résulte des alertes constantes sur certaines instances à charge élevée. Toutefois, certaines anomalies métier sur les instances à faible charge n'atteignent pas les seuils d'alerte associés, ou bien ces anomalies persistent depuis plus d'une demi-heure lorsque les seuils sont atteints. Pour améliorer votre expérience d'alerte et réduire le temps de détection des exceptions, Cloud Monitor propose la fonctionnalité d'alerte basée sur un seuil dynamique, fondée sur des algorithmes d'apprentissage automatique et l'expertise en matière de règles d'alerte. L'algorithme principal de cette fonctionnalité identifie dynamiquement les caractéristiques historiques des modèles de données, telles que les motifs périodiques, les fluctuations et l'utilisation des métriques. L'algorithme intègre les métriques de services cloud spécifiques pour générer automatiquement des limites de seuil supérieures et inférieures pour chaque instance. Cette fonctionnalité vous permet de visualiser l'effet du seuil et offre un réglage des paramètres de sensibilité, permettant ainsi une approche en boîte blanche.

Avantages

Par rapport aux règles d'alerte à métrique unique ou multiple, les règles d'alerte déclenchées par un seuil dynamique présentent les avantages suivants :

Réduction du bruit des alertes

La fonctionnalité d'alerte basée sur un seuil dynamique collecte les données de métriques de chaque instance et utilise des modèles tels que la décomposition robuste des séries temporelles et la prévision pour ajuster l'utilisation des données et les changements métier liés aux différentes métriques d'instance. Elle filtre également les bruits anormaux en se basant sur le regroupement historique des alertes et la correspondance de similarité afin d'améliorer la précision des alertes. Cette fonctionnalité convient aux scénarios suivants :

• Niveaux d'utilisation variés des métriques d'instance

  Par exemple, une entreprise de jeux vidéo utilise différentes instances ECS pour le calcul hors ligne et les services en ligne. Dans la plupart des cas, le même modèle d'alerte est utilisé. Dans ce cas, des alertes sont déclenchées lorsque des métriques telles que l'utilisation du processeur, l'utilisation de la charge et l'utilisation de la mémoire dépassent 80. Par conséquent, des alertes inattendues sont constamment déclenchées sur les instances à charge élevée.

• Pics de charge causés par des tâches planifiées

  Par exemple, un utilisateur utilise ApsaraDB RDS pour le stockage et configure une tâche planifiée pour effacer les données historiques générées il y a 30 jours tous les jours à 00:00:00. Cependant, lorsque la tâche planifiée s'exécute, l'utilisation des IOPS d'ApsaraDB RDS atteint instantanément près de 100 % et une alerte est générée. Ensuite, l'utilisation des IOPS redevient rapidement normale. Ce faux positif est généré quotidiennement selon la planification.

Dans les scénarios précédents, la fonctionnalité d'alerte basée sur un seuil dynamique peut réduire efficacement le taux de faux positifs de 80 % à 90 %. Elle vous permet de vous concentrer sur les anomalies métier et d'améliorer votre expérience de supervision et d'exploitation et maintenance (O&M).

Détection automatique des exceptions

Les exceptions sur les métriques des instances de services cloud sont généralement causées par des changements dans les services amont et aval et le trafic, ou par des modifications des applications et des données déployées sur les instances de services cloud. La fonctionnalité d'alerte basée sur un seuil dynamique permet de détecter rapidement les exceptions de service, telles que les connexions Server Load Balancer (SLB) exposées à Internet et un grand nombre de messages accumulés dans ApsaraMQ. Vous pouvez utiliser cette fonctionnalité pour détecter les exceptions sur les métriques ECS des ressources de base et identifier les causes profondes des anomalies métier.

Lorsque vous configurez une règle d'alerte à métrique unique ou multiple, vous définissez des seuils élevés pour éviter un excès de faux positifs. De plus, une telle règle d'alerte s'applique à un groupe d'applications ou à toutes les ressources. Par conséquent, les paramètres ne peuvent pas être ajustés pour des services ou des instances spécifiques. Les règles d'alerte déclenchées par un seuil dynamique permettent de détecter rapidement et avec précision les augmentations ou diminutions soudaines des valeurs de métriques. Ces règles d'alerte conviennent aux scénarios suivants :

• Détection des exceptions de métriques après des modifications de code

  Par exemple, après qu'un développeur a modifié le code de l'application, une fuite de mémoire se produit dans le programme, entraînant un garbage collection complet et une augmentation significative de l'utilisation du processeur. Cependant, une alerte à métrique unique pour une utilisation élevée du processeur ne peut pas être déclenchée dans ce cas.

• Avertissement rapide avant l'indisponibilité des services

  Par exemple, si le trafic du service amont augmente soudainement, une règle d'alerte déclenchée par un seuil dynamique permet de détecter rapidement l'exception et de déclencher une alerte avant que le seuil d'utilisation spécifié dans une règle d'alerte à métrique unique ne soit atteint. Cela empêche les services aval de devenir indisponibles en raison d'un trafic élevé continu.

Dans les scénarios métier précédents, les règles d'alerte déclenchées par un seuil dynamique peuvent être utilisées pour surveiller les métriques principales des services cloud. Ainsi, Cloud Monitor peut rappeler 85 % ou plus des problèmes et des pannes dans les 3 minutes suivant la survenue d'une exception de métrique.

Réduction des coûts de configuration et de maintenance des seuils

Vous n'avez pas besoin de spécifier de valeurs pour les seuils dynamiques. Il vous suffit de créer une règle d'alerte déclenchée par un seuil dynamique et de sélectionner la condition d'alerte correspondante (au-delà de la limite, supérieure à la limite supérieure ou inférieure à la limite inférieure) pour finaliser les paramètres de seuil. La fonctionnalité d'alerte basée sur un seuil dynamique réduit considérablement les coûts de configuration et de maintenance et convient aux scénarios suivants :

• Paramètres de seuil spécifiques

  Lorsque vous configurez des règles d'alerte pour des métriques qui n'ont pas de limites physiques supérieures, telles que le trafic, la bande passante et le nombre de requêtes par seconde (QPS) d'une instance ECS, les valeurs de ces métriques peuvent varier de plusieurs ordres de grandeur, et il est difficile de spécifier des valeurs communes et appropriées. Si les valeurs réelles de ces métriques changent avec les modifications d'O&M ou les évolutions métier et que les seuils associés doivent être modifiés en conséquence, vous devez ajuster les seuils pour éviter les faux positifs ou les faux négatifs.

• Configuration de plusieurs règles pour déclencher des alertes avec des seuils différents et à différentes périodes

  Si les valeurs de certaines métriques présentent des pics et des creux significatifs à différentes périodes, vous devez configurer plusieurs règles et spécifier différentes plages horaires effectives.

Bonnes pratiques

Réduction du bruit des alertes pour les ressources de base ECS

Un utilisateur utilise une instance ECS pour le rendu hors ligne et d'autres instances ECS pour le support des activités en ligne. L'utilisation de la mémoire de l'instance ECS utilisée pour le rendu hors ligne est nettement supérieure à celle des autres instances ECS utilisées pour les tâches en ligne. Lorsque l'utilisateur configure une règle d'alerte à métrique unique, il définit le seuil d'utilisation de la mémoire à une valeur supérieure à 80 %. Par conséquent, des alertes constantes sont déclenchées sur l'instance ECS pour le rendu hors ligne pendant une semaine, générant un total de 200 alertes. Après avoir configuré une règle d'alerte déclenchée par un seuil dynamique, moins de cinq alertes sont générées en une semaine et le taux de convergence des faux positifs est de 95 %.

Les bonnes pratiques de réduction du bruit des alertes s'appliquent à d'autres métriques outre l'utilisation de la mémoire des instances ECS. Nous vous recommandons de configurer des règles d'alerte déclenchées par un seuil dynamique pour les métriques décrites dans le tableau suivant.

Convergence des faux positifs causée par les tâches planifiées d'ApsaraDB RDS

Lorsqu'une tâche planifiée spécifiée par l'utilisateur est exécutée pour effacer les données historiques tôt le matin chaque jour, le QPS d'une base de données ApsaraDB RDS for MySQL augmente immédiatement. Une règle d'alerte à métrique unique déclenche un faux positif lors de l'exécution de la tâche planifiée. Après avoir changé la règle d'alerte en une règle d'alerte déclenchée par un seuil dynamique, les faux positifs planifiés ne se produisent plus.

Les bonnes pratiques de convergence des faux positifs causés par les tâches planifiées s'appliquent à d'autres métriques outre le QPS des bases de données ApsaraDB RDS for MySQL. Nous vous recommandons de configurer des règles d'alerte déclenchées par un seuil dynamique pour les métriques décrites dans le tableau suivant.

Détection des exceptions sur OSS ou CDN

Object Storage Service (OSS) et Alibaba Cloud CDN (CDN) servent respectivement de composants d'optimisation de la livraison de contenu accélérée dépendante du stockage et des services. Les exceptions sur OSS et CDN affectent directement la disponibilité des fonctionnalités de service. Cependant, en général, la surveillance de la disponibilité des applications ne couvre pas la disponibilité d'OSS et de CDN. Par conséquent, des alertes peuvent ne pas être déclenchées lorsque des exceptions se produisent sur OSS ou CDN.

Par exemple, si le BPS de CDN chute à zéro, la fonctionnalité d'alerte basée sur un seuil dynamique peut détecter et rappeler l'exception à temps, et envoyer une notification d'alerte.

Les règles d'alerte déclenchées par un seuil dynamique peuvent être utilisées pour couvrir rapidement les alertes de supervision pour OSS et CDN, et détecter les exceptions à l'avance avant que les services ne deviennent indisponibles. Nous vous recommandons de configurer des règles d'alerte déclenchées par un seuil dynamique pour les métriques décrites dans le tableau suivant.

Simplification de la configuration O&M d'ApsaraMQ for Kafka

Les quantités de certaines métriques d'ApsaraMQ for Kafka sont liées aux services, telles que le nombre d'envois de messages sur une instance et le nombre de messages consommés sur une instance. De plus, la consommation de messages varie considérablement entre les groupes et les sujets. Par conséquent, il est difficile de définir un seuil commun pour surveiller les files d'attente de messages pour différents services. Cela peut entraîner des erreurs telles que des faux négatifs et un retard de détection.

Grâce à ses capacités d'alerte automatisées, la fonctionnalité d'alerte basée sur un seuil dynamique peut simplifier les configurations de règles d'alerte et réduire les coûts de maintenance. Cette fonctionnalité permet de détecter rapidement les exceptions en 2 à 3 minutes, réduisant ainsi efficacement le temps moyen de réparation (MTTR) des services.

Par exemple, si le nombre de messages accumulés pour ApsaraMQ for Kafka augmente soudainement, cette fonctionnalité rappelle l'exception et envoie une notification d'alerte.

Nous vous recommandons de configurer des règles d'alerte déclenchées par un seuil dynamique pour les métriques d'ApsaraMQ for Kafka répertoriées dans le tableau suivant.