Activation de CloudWatch Application Signals - Amazon CloudWatch

Activation de CloudWatch Application Signals

Utilisez CloudWatch Application Signals pour instrumenter automatiquement vos applications sur AWS afin de suivre les performances des applications par rapport à vos objectifs métier. Application Signals vous fournit une vue unifiée et centrée sur les applications de vos applications Java, de leurs dépendances et de leurs limites. Pour de plus amples informations, consultez Application Signals.

CloudWatch Application Signals utilise l’agent CloudWatch pour recevoir des métriques et des suivis de vos applications instrumentées automatiquement, appliquer éventuellement des règles pour réduire la cardinalité élevée, puis publier la télémétrie traitée sur CloudWatch. Vous pouvez fournir une configuration personnalisée à l’agent CloudWatch spécifiquement pour Application Signals à l’aide du fichier de configuration de l’agent. Tout d’abord, la présence d’une section application_signals sous la section metrics_collected au sein de la section logs du fichier de configuration de l’agent indique que l’agent CloudWatch recevra les métriques de vos applications instrumentées automatiquement. De même, la présence d’une section application_signals sous la section traces_collected au sein de la section traces du fichier de configuration de l’agent indique que l’agent CloudWatch est activé pour recevoir des suivis de vos applications instrumentées automatiquement. En outre, vous pouvez éventuellement transmettre des règles de configuration personnalisées afin de réduire la publication de télémétrie à cardinalité élevée, comme indiqué dans cette section.

  • Pour les clusters Amazon EKS, lorsque vous installez le module complémentaire EKS Amazon CloudWatch Observability, l’agent CloudWatch est activé par défaut pour recevoir à la fois des métriques et des suivis de vos applications instrumentées automatiquement. Si vous souhaitez éventuellement transmettre des règles de configuration personnalisées, vous pouvez le faire en transmettant une configuration d’agent personnalisée au module complémentaire Amazon EKS lorsque vous le créez ou le mettez à jour en utilisant une configuration supplémentaire, comme indiqué dans (Facultatif) Configuration supplémentaire.

  • Pour le service Red Hat OpenShift sur AWS (ROSA), lorsque vous installez l’opérateur d’agent CloudWatch à l’aide des Charts de Helm, l’agent CloudWatch est, par défaut, activé pour recevoir à la fois les métriques et les suivis provenant de vos applications instrumentées automatiquement. Si vous souhaitez transmettre des règles de configuration personnalisées, vous pouvez le faire en fournissant une configuration personnalisée de l’agent via les Charts de Helm, comme décrit dans (Facultatif) Configuration supplémentaire.

  • Pour les autres plateformes prises en charge, notamment Amazon EC2, vous devez démarrer l’agent CloudWatch avec une configuration d’agent qui active Application Signals en spécifiant les sections application_signals et éventuellement les règles de configuration personnalisées, comme indiqué plus loin dans cette section.

Vous trouverez ci-dessous un aperçu des champs du fichier de configuration de l’agent CloudWatch liés à CloudWatch Application Signals.

  • logs

    • metrics_collected : ce champ peut contenir des sections pour spécifier que l’agent doit collecter des journaux afin d’activer des cas d’utilisation tels que CloudWatch Application Signals et Container Insights avec observabilité améliorée pour Amazon EKS.

      Note

      Auparavant, cette section était également utilisée pour spécifier que l'agent doit collecter les journaux au format de métrique intégrée. Ces paramètres ne sont plus nécessaires.

      • application_signals : (Facultatif) spécifie que vous souhaitez permettre à CloudWatch Application Signals de recevoir des métriques de vos applications instrumentées automatiquement afin de faciliter CloudWatch Application Signals.

        • rules : (facultatif) un ensemble de règles permettant de sélectionner de manière conditionnelle des métriques et des suivis et d’appliquer des actions pour gérer les scénarios de cardinalité élevée. Chaque règle peut contenir les champs suivants :

          • rule_name : (facultatif) le nom de la règle.

          • selectors : (facultatif) un ensemble de métriques et d’analyseur de dimension de suivis. Chaque sélecteur doit fournir les champs suivants :

            • dimension : obligatoire si selectors n’est pas vide. Cela indique la dimension des métriques et des suivis à utiliser comme filtre.

            • match : obligatoire si selectors n’est pas vide. Un motif de caractères génériques utilisé pour faire correspondre les valeurs de la dimension spécifiée.

          • action : (facultatif) action à appliquer aux métriques et aux suivis correspondant aux sélecteurs spécifiés. La valeur de action doit être l’un des mots clés suivants :

            • keep : spécifie de n’envoyer que les métriques et les suivis à CloudWatch s’ils correspondent aux selectors.

            • drop : spécifie de supprimer la métrique et les suivis qui correspondent aux selectors.

            • replace : spécifie de remplacer les dimensions des métriques et des suivis correspondantes aux selectors. Ils sont remplacés conformément à la section replacements.

          • replacements Obligatoire si action a pour valeur replace. Un tableau de paires de dimensions / valeurs qui seront appliquées aux métriques et aux suivis qui correspondent aux selectors spécifiés lorsque action est replace. Chaque remplacement doit fournir les champs suivants :

            • target_dimension : obligatoire si replacements n’est pas vide. Spécifie la dimension à remplacer.

            • value : obligatoire si replacements n’est pas vide. La valeur par laquelle remplacer la valeur target_dimension d’origine.

        • limiter (facultatif) : utilisez cette section pour limiter le nombre de métriques et de dimensions que la vigie applicative envoie à CloudWatch, afin d’optimiser vos coûts.

          • disabled (Facultatif) Si true, la fonctionnalité de limitation des métriques est désactivée. La valeur par défaut est false.

          • drop_threshold (Facultatif) Le nombre maximum de métriques distinctes par service dans un intervalle de rotation qui peuvent être exportées par un agent CloudWatch. La valeur par défaut est 500.

          • rotation_interval (Facultatif) Intervalle auquel le limiteur réinitialise les enregistrements métriques pour le comptage des distinctions. Ceci est exprimé sous la forme d’une chaîne avec une séquence de nombres et un suffixe d’unité. Les fractions sont prises en charge. Les suffixes d’unités pris en charge sont s, m, h, ms, us et ns

            La valeur par défaut est 1h pour une heure.

          • log_dropped_metrics (facultatif) : indique si l’agent doit écrire des journaux dans les journaux de l’agent CloudWatch lorsque les métriques de la vigie applicative sont ignorées. L’argument par défaut est false.

            Note

            Pour activer cette journalisation, le paramètre debug de la section agent doit également être défini sur true.

  • traces

    • traces_collected

      • application_signals : facultatif. Spécifiez cette option pour permettre à l’agent CloudWatch de recevoir des suivis de vos applications instrumentées automatiquement afin de faciliter CloudWatch Application Signals.

Note

Même si les règles personnalisées application_signals sont spécifiées dans la section metrics_collected contenue dans la section logs, elles s’appliquent également implicitement à la section traces_collected. Le même ensemble de règles s’appliquera à la fois aux métriques et aux suivis.

Lorsqu’il existe plusieurs règles comportant des actions différentes, elles s’appliquent dans l’ordre suivant : keep, puis drop, puis replace.

L’exemple suivant illustre un fichier de configuration d’agent CloudWatch complet qui applique des règles personnalisées.

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "rules": [
          {
            "rule_name": "keep01",
            "selectors": [
              {
                "dimension": "Service",
                "match": "pet-clinic-frontend"
              },
              {
                "dimension": "RemoteService",
                "match": "customers-service"
              }
            ],
            "action": "keep"
          },
          {
            "rule_name": "drop01",
            "selectors": [
              {
                "dimension": "Operation",
                "match": "GET /api/customer/owners/*"
              }
            ],
            "action": "drop"
          },
          {
            "rule_name": "replace01",
            "selectors": [
              {
                "dimension": "Operation",
                "match": "PUT /api/customer/owners/*/pets/*"
              },
              {
                "dimension": "RemoteOperation",
                "match": "PUT /owners"
              }
            ],
            "replacements": [
              {
                "target_dimension": "Operation",
                "value": "PUT /api/customer/owners/{ownerId}/pets{petId}"
              }
            ],
            "action": "replace"
          }
        ]
      }
    }
  },
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  }
}

Dans l’exemple de fichier de configuration précédent, les rules sont traitées comme suit :

  1. La règle keep01 garantit que toute métrique et tout suivi dont la dimension Service est pet-clinic-frontend et la dimension RemoteService est customers-service sont conservées.

  2. Pour les métriques et les suivis traités après application de keep01, la règle drop01 garantit que les métriques et les suivis dont la dimension Operation est GET /api/customer/owners/* sont supprimées.

  3. Pour les métriques et les suivis traités après application de drop01, la règle replace01 met à jour les métriques et les suivis dont la dimension Operation est PUT /api/customer/owners/*/pets/* et la dimension RemoteOperation est PUT /owners telles que leur dimension Operation est désormais remplacée par la valeur PUT /api/customer/owners/{ownerId}/pets{petId}.

L’exemple suivant présente un fichier de configuration complet de CloudWatch qui gère la cardinalité dans la vigie applicative en modifiant la limite de métriques à 100, activant la journalisation des métriques ignorées et en définissant l’intervalle de rotation à deux heures.

{
    "logs": {
        "metrics_collected": {
            "application_signals": {
                "limiter": {
                    "disabled": false,
                    "drop_threshold": 100,
                    "rotation_interval": "2h",
                    "log_dropped_metrics": true
                }
            }
        },
        "traces": {
            "traces_collected": {
                "application_signals": {}
            }
        }
    }
}