Corrélation de la cause première

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 2 minutes de lecture
  • La corrélation de la cause première (RCC) rationalise l’exécution d’une analyse de la cause première en corrélant automatiquement les mesures, les journaux et les informations d’événement pour les symptômes pris en charge sur les instances de production au cours des dernières 24 heures.

    Catégories de symptômes du CCR

    La fonctionnalité RCC est disponible pour les alertes en libre-service et prend en charge les catégories de symptômes suivantes :
    • Mémoire
    • Sessions en cours les plus longues
    • Transactions lentes
    • Purge du cache
    • Verrous de base de données
    • Impacts sur la base de données
    Le tableau décrit les catégories de symptômes et les alertes correspondantes détectées par le moteur RCC.
    Tableau 1. Catégories de symptômes ciblées et alertes correspondantes
    Catégories de symptômes Description Alerte correspondante
    Impact sur la base de données Aide l’utilisateur à identifier et à traiter les requêtes SQL étendues ayant un impact sur les performances de la base de données, liées à un temps d’exécution élevé ou à des volumes accrus. Les modèles de requête fournissent des instantanés d’une durée de 30 minutes et 60 minutes à partir du moment où l’impact est observé sur les temps d’exécution des requêtes. Délai de réponse de la base de données
    Purge du cache Des purges de cache et des redémarrages de nœuds sont détectés, ainsi que des niveaux de saturation de service élevés qui peuvent s’être produits au moment du déclenchement d’une alerte de performances. Moyenne de sémaphore par défaut
    Session en cours la plus longue Recherche les journaux des sessions les plus longues dans le délai moyen de récupération (MTTR) et identifie le hachage de modèle de transaction principal avec les temps de traitement les plus élevés, puis les ID de transaction. Moyenne de sémaphore par défaut
    Transactions lentes
    • Identifie les transactions les plus longues à l’aide de la durée totale, y compris le temps ACL, le temps SQL, le temps CPU, le temps de traitement, le temps BR et le temps de script.
    • Renvoie les ID de transaction, le hachage de modèle et ces mesures pour aider les utilisateurs à identifier les causes spécifiques des transactions de longue durée.
    Moyenne de sémaphore par défaut
    Mémoire
    • Identifie les trois nœuds les plus affectés par les pauses de nettoyage de la mémoire, déterminées par la durée agrégée des pauses.
    • Identifie toutes les transactions ou les threads de travail sur ces nœuds qui dépassent 200 secondes.
      Remarque :
      Il est conseillé aux utilisateurs de passer en revue ces fils de discussion de longue durée ou récurrents.
    Heure de nettoyage de la mémoire du nœud
    Verrous de base de données Le moteur RCC surveille les innodb_row_lock_waits et les threads_running pour détecter les événements de verrouillage de base de données anormaux qui se produisent lorsqu’une opération de base de données nécessite un accès exclusif. Threads en cours d’exécution

    États des rapports RCC

    Lorsqu’un rapport RCC est généré, plusieurs états sont disponibles :
    • RCC En cours : la génération du rapport RCC est en cours de génération
    • Généré par RCC : le rapport a été généré avec succès
    • Aucun RCC trouvé : lorsqu’il n’y a pas assez d’informations pour générer le rapport
    • Échec du RCC : renvoyé en cas de problème technique, généralement corrigé pour régénérer le rapport