L’application ne démarre pas après l’activation d’Application Signals L'application Python ne démarre pas une fois les signaux d'application activés Aucune donnée de signal d'application pour une application Python utilisant un serveur WSGI Mon application Node.js n'est pas instrumentée ou ne génère pas de télémétrie des signaux d'application Aucune donnée d'application dans le tableau de bord des signaux d'application Les métriques de service ou les métriques de dépendance ont des valeurs inconnues Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS Je souhaite filtrer les métriques et les traces inutiles Qu'est-ce que InternalOperation cela signifie ?Comment activer la journalisation pour les applications .NET ?Comment puis-je résoudre les conflits de version d'assemblage dans les applications .NET ?Puis-je le désactiver FluentBit ?Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ?

Résolution des problèmes liés à l’installation d’Application Signals

Cette section contient des conseils de résolution des problèmes relatifs aux signaux CloudWatch d'application.

Rubriques

L’application ne démarre pas après l’activation d’Application Signals
L'application Python ne démarre pas une fois les signaux d'application activés
Aucune donnée de signal d'application pour une application Python utilisant un serveur WSGI
Mon application Node.js n'est pas instrumentée ou ne génère pas de télémétrie des signaux d'application
Aucune donnée d'application dans le tableau de bord des signaux d'application
Les métriques de service ou les métriques de dépendance ont des valeurs inconnues
Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS
Je souhaite filtrer les métriques et les traces inutiles
Qu'est-ce que InternalOperation cela signifie ?
Comment activer la journalisation pour les applications .NET ?
Comment puis-je résoudre les conflits de version d'assemblage dans les applications .NET ?
Puis-je le désactiver FluentBit ?
Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ?

L’application ne démarre pas après l’activation d’Application Signals

Si votre application sur un cluster Amazon EKS ne démarre pas une fois que vous avez activé Application Signals sur le cluster, vérifiez les points suivants :

Vérifiez si l’application a été instrumentée par une autre solution de surveillance. Les signaux d'application peuvent ne pas prendre en charge la coexistence avec d'autres solutions d'instrumentation.
Vérifiez que votre application répond aux exigences de compatibilité pour utiliser Application Signals. Pour de plus amples informations, veuillez consulter Systèmes compatibles avec Application Signals .
Si votre application ne parvient pas à extraire les artefacts Application Signals tels que l'agent et CloudWatch les images de l'agent AWS Distro for OpenTelemetery Java ou Python, cela peut être dû à un problème de réseau.

Pour atténuer le problème, supprimez l'annotation instrumentation.opentelemetry.io/inject-java: "true" ou instrumentation.opentelemetry.io/inject-python: "true" du manifeste de déploiement de votre application, puis redéployez votre application. Vérifiez ensuite si l’application fonctionne.

Problèmes connus

La collecte de métriques d'exécution dans la version v1.32.5 du SDK Java est connue pour ne pas fonctionner avec les applications utilisant Wildfly. JBoss Ce problème s'étend au module complémentaire Amazon CloudWatch Observability EKS, affectant les 2.3.0-eksbuild.1 versions 2.5.0-eksbuild.1 suivantes.

Si vous êtes concerné, rétrogradez la version ou désactivez votre collecte de métriques d'exécution en ajoutant la variable d'environnement OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false à votre application.

L'application Python ne démarre pas une fois les signaux d'application activés

Il s'agit d'un problème connu en OpenTelemetry matière d'instrumentation automatique : une variable d'PYTHONPATHenvironnement manquante peut parfois empêcher le démarrage de l'application. Pour résoudre ce problème, veillez à définir la variable d'PYTHONPATHenvironnement à l'emplacement du répertoire de travail de votre application. Pour plus d'informations sur ce problème, consultez la section Le paramètre d'auto-instrumentation Python de PYTHONPATH n'est pas conforme au comportement de résolution des modules de Python, ce qui perturbe les applications Django.

Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la documentation OpenTelemetry Python.

Utilisez le --noreload drapeau pour empêcher le rechargement automatique.
Définissez la variable d'DJANGO_SETTINGS_MODULEenvironnement sur l'emplacement du settings.py fichier de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.

Aucune donnée de signal d'application pour une application Python utilisant un serveur WSGI

Si vous utilisez un serveur WSGI tel que Gunicorn ou uWSGI, vous devez apporter des modifications supplémentaires pour que l'instrumentation automatique ADOT Python fonctionne.

Note

Assurez-vous d'utiliser la dernière version d'ADOT Python et le module complémentaire Amazon CloudWatch Observability EKS avant de continuer.

Étapes supplémentaires pour activer les signaux d'application avec un serveur WSGI

Importez l'instrumentation automatique dans les processus de travail bifurqués.

Pour Gunicorn, utilisez le post_fork crochet :


# gunicorn.conf.py
def post_fork(server, worker):
    from opentelemetry.instrumentation.auto_instrumentation import sitecustomize

Pour uWSGI, utilisez la directive. import


#  uwsgi.ini
[uwsgi]
; required for the instrumentation of worker processes
enable-threads = true
lazy-apps = true
import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize

Activez la configuration pour l'instrumentation automatique ADOT Python afin d'ignorer le processus principal et de s'en remettre aux travailleurs en définissant la variable d'OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLEDenvironnement sur. true

Mon application Node.js n'est pas instrumentée ou ne génère pas de télémétrie des signaux d'application

Pour activer les signaux d'application pour Node.js, vous devez vous assurer que votre application Node.js utilise le format du module CommonJS (CJS). Actuellement, la AWS distribution pour OpenTelemetry Node.js ne prend pas en charge le format du module ESM, car le support OpenTelemetry JavaScript d'ESM est expérimental et est en cours de développement.

Pour déterminer si votre application utilise CJS et non ESM, assurez-vous que votre application ne remplit pas les conditions pour activer ESM.

Aucune donnée d'application dans le tableau de bord des signaux d'application

Si des métriques ou des suivis sont absents des tableaux de bord d’Application Signals, cela peut être dû aux causes suivantes. N’étudiez ces causes que si vous avez attendu 15 minutes pour qu’Application Signals collecte et affiche les données depuis votre dernière mise à jour.

Assurez-vous que la bibliothèque et le framework que vous utilisez sont pris en charge par l’agent Java ADOT. Pour plus d’informations, veuillez consulter la rubrique Bibliothèques/Frameworks.
Assurez-vous que l' CloudWatch agent est en cours d'exécution. Vérifiez d'abord l'état des modules d' CloudWatch agents et assurez-vous qu'ils le Running sont tous.
```
kubectl -n amazon-cloudwatch get pods.
```
Ajoutez ce qui suit au fichier de configuration de l' CloudWatch agent pour activer les journaux de débogage, puis redémarrez l'agent.
```
"agent": {

  "region": "${REGION}",
  "debug": true
},
```
Vérifiez ensuite l'absence d'erreurs dans les modules CloudWatch d'agent.
Vérifiez l'absence de problèmes de configuration avec l' CloudWatch agent. Vérifiez que les informations suivantes se trouvent toujours dans le CloudWatch fichier de configuration de l'agent et que l'agent a été redémarré depuis son ajout.
```
"agent": {
  "region": "${REGION}",
  "debug": true
},
```
Vérifiez ensuite les journaux de OpenTelemetry débogage pour détecter les messages d'erreur tels queERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export .... Ces messages peuvent indiquer le problème.

Si cela ne résout pas le problème, videz et vérifiez les variables d’environnement dont le nom commence par OTEL_ en décrivant le pod à l’aide de la commande kubectl describe pod.
Pour activer la journalisation du débogage en OpenTelemetry Python, définissez la variable d'environnement OTEL_PYTHON_LOG_LEVEL sur debug et redéployez l'application.
Vérifiez que les autorisations d'exportation des données depuis l' CloudWatchagent ne sont pas correctes ou insuffisantes. Si vous voyez Access Denied des messages dans les journaux des CloudWatch agents, cela peut être à l'origine du problème. Il est possible que les autorisations appliquées lors de l'installation de l' CloudWatch agent aient été modifiées ou révoquées ultérieurement.
Vérifiez l'absence d'un problème de AWS distribution pour OpenTelemetry (ADOT) lors de la génération de données de télémétrie.

Assurez-vous que les annotations d’instrumentation instrumentation.opentelemetry.io/inject-java et sidecar.opentelemetry.io/inject-java sont appliquées au déploiement de l’application et que la valeur est true. Sans celles-ci, les pods d’application ne seront pas instrumentés même si le module complémentaire ADOT est correctement installé.

Ensuite, vérifiez si le conteneur init est appliqué sur l’application et si son état Ready est True. Si le conteneur init n’est pas prêt, veuillez consulter l’état pour en connaître la raison.

Si le problème persiste, activez la journalisation du débogage sur le SDK OpenTelemetry Java en définissant la variable d'environnement sur true et OTEL_JAVAAGENT_DEBUG en redéployant l'application. Recherchez ensuite les messages commençant par ERROR io.telemetry.
L’exportateur de métrique/d’intervalle est peut-être en train de supprimer des données. Pour le savoir, consultez le journal des applications pour voir s’il contient des messages incluant Failed to export....
L' CloudWatch agent est peut-être limité lorsqu'il envoie des métriques ou des spans à Application Signals. Vérifiez les messages indiquant une limitation dans les journaux de l' CloudWatch agent.
Assurez-vous d'avoir activé la configuration de découverte des services. Vous ne devez le faire qu'une seule fois dans votre région.

Pour confirmer cela, dans la CloudWatch console, choisissez Application Signals, Services. Si l'étape 1 n'est pas marquée comme terminée, choisissez Commencer à découvrir vos services. Les données devraient commencer à affluer dans les cinq minutes.

Les métriques de service ou les métriques de dépendance ont des valeurs inconnues

Si vous voyez UnknownService, UnknownOperationUnknownRemoteService, ou UnknownRemoteOperationpour un nom de dépendance ou une opération dans les tableaux de bord des signaux d'application, vérifiez si l'occurrence de points de données pour le service distant inconnu et le fonctionnement à distance inconnu coïncident avec leurs déploiements.

UnknownServicesignifie que le nom d'une application instrumentée est inconnu. Si la variable d'OTEL_SERVICE_NAMEenvironnement n'est pas définie et service.name n'est pas spécifiée dansOTEL_RESOURCE_ATTRIBUTES, le nom du service est défini sur. UnknownService Pour résoudre ce problème, spécifiez le nom du service dans OTEL_SERVICE_NAME ouOTEL_RESOURCE_ATTRIBUTES.
UnknownOperationsignifie que le nom d'une opération invoquée est inconnu. Cela se produit lorsque Application Signals ne parvient pas à découvrir le nom d'une opération qui appelle l'appel à distance, ou lorsque le nom de l'opération extrait contient des valeurs de cardinalité élevées.
UnknownRemoteServicesignifie que le nom du service de destination est inconnu. Cela se produit lorsque le système ne parvient pas à extraire le nom du service de destination auquel l'appel distant accède.

Une solution consiste à créer un intervalle personnalisé autour de la fonction qui envoie la demande et à ajouter l'attribut aws.remote.service avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique deRemoteService. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultezActiver les signaux CloudWatch d'application.
UnknownRemoteOperationsignifie que le nom de l'opération de destination est inconnu. Cela se produit lorsque le système ne parvient pas à extraire le nom de l'opération de destination à laquelle l'appel distant accède.

Une solution consiste à créer un intervalle personnalisé autour de la fonction qui envoie la demande et à ajouter l'attribut aws.remote.operation avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique deRemoteOperation. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultezActiver les signaux CloudWatch d'application.

Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS

Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS, si vous remarquez une défaillance causée par un type Health Issue ConfigurationConflict de fichier dont la description commence parConflicts found when trying to apply. Will not continue due to resolve conflicts mode, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le sur le cluster. Lorsque le module complémentaire tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour pour éviter de modifier l'état des ressources du cluster.

Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire Amazon CloudWatch Observability EKS lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez Supprimer l' CloudWatch agent et Fluent Bit for Container Insights pour plus d'informations.

Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier OVERWRITE. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la Méthode de résolution des conflits lorsque vous choisissez les Paramètres de configuration facultatifs lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le --resolve-conflicts OVERWRITE à votre commande pour créer ou mettre à jour le module complémentaire.

Je souhaite filtrer les métriques et les traces inutiles

Si Application Signals collecte des traces et des mesures que vous ne souhaitez pas utiliser, consultez Gérez les opérations à haute cardinalité pour plus d'informations sur la configuration de l' CloudWatch agent avec des règles personnalisées afin de réduire la cardinalité.

Pour plus d'informations sur la personnalisation des règles d'échantillonnage des traces, voir Configurer les règles d'échantillonnage dans la documentation de X-Ray.

Qu'est-ce que `InternalOperation` cela signifie ?

An InternalOperation est une opération déclenchée par l'application en interne plutôt que par un appel externe. Voir InternalOperation est attendu, comportement sain.

Voici quelques exemples typiques que vous pourriez voir InternalOperation :

Préchargement au démarrage : votre application exécute une opération nommée loadDatafromDB qui lit les métadonnées d'une base de données pendant la phase de préchauffage. Au lieu de l'observer en loadDatafromDB tant qu'opération de service, vous la verrez classée dans la catégorieInternalOperation.
Exécution asynchrone en arrière-plan : votre application s'abonne à une file d'événements et traite les données de streaming en conséquence chaque fois qu'une mise à jour est effectuée. Chaque opération déclenchée sera considérée InternalOperation comme une opération de service.
Extraction des informations sur l'hôte à partir d'un registre de services : votre application communique avec un registre de services pour la découverte de services. Toutes les interactions avec le système de découverte sont classées dans la catégorieInternalOperation.

Comment activer la journalisation pour les applications .NET ?

Pour activer la journalisation pour les applications .NET, configurez les variables d'environnement suivantes. Pour plus d'informations sur la configuration de ces variables d'environnement, consultez la section Résolution des problèmes d'instrumentation automatique .NET dans la OpenTelemetry documentation.

OTEL_LOG_LEVEL
OTEL_DOTNET_AUTO_LOG_DIRECTORY
COREHOST_TRACE
COREHOST_TRACEFILE

Comment puis-je résoudre les conflits de version d'assemblage dans les applications .NET ?

Si l'erreur suivante s'affiche, consultez la section Conflits de versions d'assemblage dans la OpenTelemetry documentation pour connaître les étapes de résolution.


Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
   at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
   at Program.<Main>$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26

Puis-je le désactiver FluentBit ?

Vous pouvez le désactiver FluentBit en configurant le module complémentaire Amazon CloudWatch Observability EKS. Pour de plus amples informations, veuillez consulter (Facultatif) Configuration supplémentaire.

Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ?

Non, le filtrage des journaux des conteneurs n'est pas encore pris en charge.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Mise à jour vers les versions requises des agents ou du module complémentaire Amazon EKS

Configuration d’Application Signals