Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configuration d’Application Signals

Cette section contient des informations sur la configuration des signaux CloudWatch d'application.

Taux d’échantillonnage du suivi

Par défaut, lorsque vous activez Application Signals, l’échantillonnage centralisé X-Ray est activé en utilisant les paramètres de fréquence d’échantillonnage par défaut de reservoir=1/s et fixed_rate=5%. Les variables d'environnement de l'SDKagent AWS Distro for OpenTelemetry (ADOT) sont définies comme suit.

Pour plus d’informations sur la configuration d’échantillonnage, veuillez consulter les ressources suivantes :

Si vous souhaitez désactiver l'échantillonnage centralisé X-Ray et utiliser l'échantillonnage local à la place, définissez les valeurs suivantes pour l'agent ADOT SDK Java comme indiqué ci-dessous. L’exemple suivant définit le taux d’échantillonnage à 5 %.

Pour plus d'informations sur les paramètres d'échantillonnage plus avancés, voir OTEL_ TRACES _ SAMPLER.

Activer la corrélation entre le traçage et le journal

Vous pouvez activer la corrélation entre le suivi et le journal dans Application Signals. Cela injecte automatiquement la trace IDs et le span IDs dans les journaux d'application pertinents. Ensuite, lorsque vous ouvrez une page détaillée de trace dans la console Application Signals, les entrées de journal pertinentes (le cas échéant) en corrélation avec la trace actuelle apparaissent automatiquement en bas de la page.

Supposons, par exemple, que vous remarquiez un pic dans un graphique de latence. Vous pouvez choisir le point sur le graphique pour charger les informations de diagnostic pour ce moment. Vous choisissez ensuite la trace appropriée pour obtenir plus d'informations. Lorsque vous consultez les informations de suivi, vous pouvez faire défiler l'écran vers le bas pour voir les journaux associés au suivi. Ces journaux peuvent révéler des modèles ou des codes d'erreur associés aux problèmes à l'origine du pic de latence.

Pour obtenir une corrélation entre les journaux de suivi, Application Signals s'appuie sur l'MDCinstrumentation automatique Logger pour Java et sur l'instrumentation de OpenTelemetry journalisation pour Python. Les deux sont fournis par OpenTelemetry la communauté. Application Signals l'utilise pour injecter des contextes de trace tels que l'ID de trace et l'ID de span dans les journaux des applications. Pour ce faire, vous devez modifier manuellement votre configuration de journalisation afin d'activer l'instrumentation automatique.

En fonction de l'architecture sur laquelle votre application s'exécute, vous devrez peut-être également définir une variable d'environnement pour activer la corrélation des journaux de suivi, en plus de suivre les étapes décrites dans cette section.

Après avoir activé la corrélation des journaux de suivi,

Exemples de configuration de la corrélation des journaux de suivi

Cette section contient des exemples de configuration de la corrélation des journaux de suivi dans plusieurs environnements.

Spring Boot pour Java

Supposons que vous ayez une application Spring Boot dans un dossier appelécustom-app. La configuration de l'application est généralement un YAML fichier nommé custom-app/src/main/resources/application.yml qui peut ressembler à ceci :

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...   

Pour activer la corrélation entre les journaux de suivi, ajoutez la configuration de journalisation suivante.

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...    

logging:
  pattern:
    level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

Logback pour Java

Dans la configuration de journalisation (telle que logback.xml), insérez le contexte pattern de trace trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p dans Encoder. Par exemple, la configuration suivante ajoute le contexte de trace avant le message du journal.

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>app.log</file>
  <append>true</append>
  <encoder> 
    <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> 
  </encoder>
</appender>

Pour plus d'informations sur les encodeurs dans Logback, consultez la section Encodeurs dans la documentation Logback.

Log4j2 pour Java

Dans la configuration de journalisation (telle que log4j2.xml), insérez le contexte de trace trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p dansPatternLayout. Par exemple, la configuration suivante ajoute le contexte de trace avant le message du journal.

<Appenders>
  <File name="FILE" fileName="app.log">
    <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>
  </File>
</Appenders>

Pour plus d'informations sur les mises en page de modèles dans Log4j2, voir Disposition de modèles dans la documentation de Log4j2.

Log4j pour Java

Dans la configuration de journalisation (telle que log4j.xml), insérez le contexte de trace trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p dansPatternLayout. Par exemple, la configuration suivante ajoute le contexte de trace avant le message du journal.

<appender name="FILE" class="org.apache.log4j.FileAppender">;
  <param name="File" value="app.log"/>;
  <param name="Append" value="true"/>;
  <layout class="org.apache.log4j.PatternLayout">;
    <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>;
  </layout>;
</appender>;

Pour plus d'informations sur les mises en page de modèles dans Log4j, consultez Class Pattern Layout dans la documentation de Log4j.

Python

Définissez la variable d'environnement OTEL_PYTHON_LOG_CORRELATION sur true pendant l'exécution de votre application. Pour plus d'informations, consultez Activer l'injection de contexte de trace dans la OpenTelemetry documentation Python.

Activer la corrélation entre les métriques et les journaux

Si vous publiez des journaux d'applications dans des groupes de CloudWatch journaux dans Logs, vous pouvez activer la corrélation entre les métriques et les journaux des applications dans Application Signals. Grâce à la corrélation des journaux métriques, la console Application Signals affiche automatiquement les groupes de journaux pertinents associés à une métrique.

Supposons, par exemple, que vous remarquiez un pic dans un graphique de latence. Vous pouvez choisir un point sur le graphique pour charger les informations de diagnostic pour ce moment. Les informations de diagnostic indiqueront les groupes de journaux d'applications pertinents associés au service et à la métrique actuels. Vous pouvez ensuite choisir un bouton pour exécuter une requête CloudWatch Logs Insights sur ces groupes de journaux. Selon les informations contenues dans les journaux de l'application, cela peut vous aider à rechercher la cause du pic de latence.

En fonction de l'architecture sur laquelle votre application s'exécute, il se peut que vous deviez également définir une variable d'environnement pour permettre la corrélation entre les métriques et le journal de l'application.

Gérez les opérations à haute cardinalité

Application Signals inclut des paramètres dans l' CloudWatch agent que vous pouvez utiliser pour gérer la cardinalité de vos opérations et gérer l'exportation des métriques afin d'optimiser les coûts. Par défaut, la fonction de limitation des métriques devient 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 le comportement en ajustant les paramètres de configuration.

Déterminez si la limitation métrique est activée

Vous pouvez utiliser les méthodes suivantes pour déterminer si la limite métrique par défaut est respectée. Si tel est le cas, vous devez envisager d'optimiser le contrôle de cardinalité en suivant les étapes de la section suivante.

Optimisez le contrôle de la cardinalité

Pour optimiser votre contrôle de cardinalité, vous pouvez effectuer les opérations suivantes :

Créez des règles personnalisées pour agréger les opérations

Les opérations à haute cardinalité peuvent parfois être causées par des valeurs uniques inappropriées extraites du contexte. Par exemple, l'envoi de requêtes HTTP /S incluant un utilisateur IDs ou une session IDs dans le chemin peut entraîner des centaines d'opérations disparates. Pour résoudre ces problèmes, nous vous recommandons de configurer l' CloudWatch agent avec des règles de personnalisation afin de réécrire ces opérations.

Dans les cas où il y a une augmentation de la génération de nombreux indicateurs différents par le biais d'RemoteOperationappels individuels PUT /api/customer/owners/123PUT /api/customer/owners/456, tels que, et de demandes similaires, nous vous recommandons de regrouper ces opérations en une seuleRemoteOperation. L'une des approches consiste à normaliser tous les RemoteOperation appels commençant PUT /api/customer/owners/ par un format uniforme, en particulierPUT /api/customer/owners/{ownerId}. L’exemple suivant illustre ce scénario. Pour plus d'informations sur les autres règles de personnalisation, consultezActiver les signaux CloudWatch d'application.

{
   "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 à haute cardinalité peuvent avoir été agrégéesAllOtherRemoteOperations, et il est possible que les métriques spécifiques incluses ne soient pas claires. L' CloudWatch agent est en mesure d'enregistrer les opérations abandonnées. Pour identifier les opérations abandonnées, utilisez la configuration de l'exemple suivant pour activer la journalisation jusqu'à ce que le problème réapparaisse. Inspectez ensuite les journaux de l' CloudWatch agent (accessibles par conteneur stdout ou par fichier EC2 journal) 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éez votre politique de limitation des métriques

Si la configuration de limitation métrique par défaut ne tient pas compte de la cardinalité de votre service, vous pouvez personnaliser la configuration du limiteur métrique. Pour ce faire, ajoutez une limiter section sous la logs/metrics_collected/application_signals section du fichier de configuration de l' CloudWatch agent.

L'exemple suivant abaisse le seuil de limitation des métriques de 500 métriques distinctes à 100.

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