Gestion des opérations à cardinalité élevée

La vigie applicative inclut des paramètres dans l’agent CloudWatch qui permettent de gérer la cardinalité des opérations et de contrôler l’exportation des métriques afin d’optimiser les coûts. Par défaut, la fonction de limitation des métriques s’active lorsque le nombre d’opérations distinctes pour un service au fil du temps dépasse le seuil par défaut de 500. Vous pouvez ajuster ce comportement en modifiant les paramètres de configuration.

Vérification de l’activation de la limitation des métriques

Vous pouvez utiliser les méthodes suivantes pour déterminer si la limitation automatique des métriques est active. Si c’est le cas, il est recommandé d’optimiser le contrôle de la cardinalité en suivant les étapes décrites dans la section suivante.

Optimisation du contrôle de la cardinalité

Pour optimiser le contrôle de la cardinalité, vous pouvez :

Création de règles personnalisées pour agréger les opérations

Les opérations à cardinalité élevée peuvent parfois être causées par des valeurs uniques inappropriées extraites du contexte. Par exemple, l’envoi de requêtes HTTP/S contenant des identifiants d’utilisateur ou des identifiants de session dans le chemin peut générer des centaines d’opérations distinctes. Pour résoudre ce problème, il est recommandé de configurer l’agent CloudWatch avec des règles de personnalisation afin de réécrire ces opérations.

Dans les cas où un grand nombre de métriques distinctes sont générées par des appels RemoteOperation individuels tels que PUT /api/customer/owners/123, PUT /api/customer/owners/456 ou d’autres requêtes similaires, il est conseillé de regrouper ces opérations en une seule RemoteOperation. Une approche consiste à standardiser tous les appels RemoteOperation qui commencent par PUT /api/customer/owners/ dans un format uniforme, à savoir PUT /api/customer/owners/{ownerId}. L’exemple suivant illustre ce scénario. Pour plus d’informations sur d’autres règles de personnalisation, consultez Activation de CloudWatch Application Signals.

{
   "logs":{
      "metrics_collected":{
         "application_signals":{
            "rules":[
               {
                  "selectors":[
                     {
                        "dimension":"RemoteOperation",
                        "match":"PUT /api/customer/owners/*"
                     }
                  ],
                  "replacements":[
                     {
                        "target_dimension":"RemoteOperation",
                        "value":"PUT /api/customer/owners/{ownerId}"
                     }
                  ],
                  "action":"replace"
               }
            ]
         }
      }
   }
}

Dans d’autres cas, les métriques à cardinalité élevée peuvent avoir été agrégées dans AllOtherRemoteOperations, ce qui rend difficile l’identification des métriques spécifiques incluses. L’agent CloudWatch peut journaliser les opérations ignorées. Pour identifier ces opérations ignorées, utilisez la configuration présentée dans l’exemple suivant pour activer la journalisation jusqu’à ce que le problème se reproduise. Examinez ensuite les journaux de l’agent CloudWatch (accessibles par le conteneur stdout ou les fichiers journaux EC2) et recherchez le mot-clé drop metric data.

{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}

Création d’une politique de limitation des métriques

Si la configuration par défaut de la limitation des métriques ne répond pas aux besoins de votre service, vous pouvez personnaliser la configuration du limiteur de métriques. Pour ce faire, ajoutez une section limiter sous la section logs/metrics_collected/application_signals dans le fichier de configuration de l’agent CloudWatch.

L’exemple suivant montre comment réduire le seuil de limitation des métriques de 500 métriques distinctes à 100.

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}