View a markdown version of this page

OpenTelemetry Collectionneur - Amazon CloudWatch
Récepteurs pris en chargePrise en mainAuthentifiez-vous à l'aide d'un jeton porteur (clé API)Exemples de configuration de collecteurs

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.

OpenTelemetry Collectionneur

Le OpenTelemetry Collector est un agent open source, indépendant des fournisseurs, qui reçoit, traite et exporte des données de télémétrie. Il agit comme un pipeline central entre vos applications et Amazon CloudWatch, collectant des métriques, des journaux et des traces provenant de plusieurs sources et les envoyant à CloudWatch Using the OpenTelemetry Protocol (OTLP).

L'utilisation du OpenTelemetry Collector avec CloudWatch offre les avantages suivants :

  • Collectez la télémétrie de plusieurs applications et hôtes par le biais d'un seul agent, afin de réduire le nombre de connexions à. CloudWatch

  • Traitez et filtrez la télémétrie avant de l'envoyer CloudWatch, notamment en ajoutant ou en supprimant des attributs, en regroupant des données et en échantillonnant des traces.

  • Utilisez la même configuration de collecteur dans tous les environnements cloud AWS, locaux et autres, afin de fournir un pipeline de télémétrie cohérent quel que soit l'endroit où vos applications s'exécutent.

  • Envoyez des métriques à CloudWatch avec des libellés enrichis disponibles pour effectuer des requêtes à l'aide du langage de requête Prometheus (ProMQL) dans Query Studio. CloudWatch

Récepteurs pris en charge

Le OpenTelemetry Collector prend en charge une large gamme de récepteurs pour l'ingestion de données de télémétrie. Vous pouvez utiliser OpenTelemetry des récepteurs tels que le récepteur OTLP pour les applications équipées de OpenTelemetry SDK, ou des récepteurs Prometheus pour extraire les métriques des exportateurs Prometheus existants. Les récepteurs Prometheus couramment utilisés avec les récepteurs suivants sont les suivants : CloudWatch

  • Récepteur Prometheus, pour le scraping de n'importe quel terminal Prometheus-compatible

  • Récepteur Host Metrics, pour collecter des métriques au niveau du système auprès de l'hôte

  • Récepteur Kubernetes Cluster, pour collecter des métriques au niveau du cluster à partir du serveur API Kubernetes

Vous pouvez configurer plusieurs récepteurs dans un seul collecteur, ce qui vous permet de collecter à la fois des métriques OpenTelemetry et des métriques Prometheus et de les envoyer CloudWatch via le même pipeline. Pour obtenir la liste complète des récepteurs disponibles, consultez le référentiel OpenTelemetry Collector.

Prise en main

Condition préalable : si vous utilisez le point de terminaison OTLP pour le suivi, assurez-vous que la recherche de transactions est activée.

Étapes :

  1. Téléchargez la dernière version de la distribution OpenTelemetry Collector. Pour plus d'informations, consultez les versions de OpenTelemetry Collector.

  2. Installez le OpenTelemetry Collector sur votre hôte. Le collecteur fonctionne sur tous les systèmes d'exploitation et toutes les plateformes. Pour plus d’informations, consultez Installer le Collector.

  3. Configurez les AWS informations d'identification sur votre hôte Amazon EC2 ou sur site. Le collecteur utilise ces informations d'identification pour s'authentifier CloudWatch lors de l'envoi de données de télémétrie. Voir ci-dessous pour plus de détails.

    Setup IAM permissions for Amazon EC2
    Suivez la procédure ci-dessous pour associer la politique IAM CloudWatchAgentServerPolicy au rôle IAM de votre instance Amazon EC2.

    1. Ouvrez la console IAM à l’adresse https://console.aws.amazon.com/iam/.

    2. Sélectionnez Rôles, puis recherchez et sélectionnez le rôle utilisé par votre instance Amazon EC2.

    3. Sous l’onglet Autorisations, sélectionnez Ajouter des autorisations, Associer des politiques.

    4. À l’aide du champ de recherche, recherchez la politique CloudWatchAgentServerPolicy.

    5. Sélectionnez la politique CloudWatchAgentServerPolicy, puis choisissez Ajouter des autorisations.

    Setup IAM permissions for on-premise hosts
    Vous pouvez créer un utilisateur IAM qui peut être utilisé pour fournir des autorisations à vos hôtes sur site.

    1. Ouvrez la console IAM à l’adresse https://console.aws.amazon.com/iam/.

    2. Sélectionnez Utilisateurs, Créer un utilisateur.

    3. Sous Détails de l’utilisateur, pour Nom d’utilisateur, entrez un nom pour le nouvel utilisateur IAM. Il s'agit du nom de connexion AWS qui sera utilisé pour authentifier votre hôte.

    4. Choisissez Suivant.

    5. Sur la page Définir les autorisations, pour les Options des autorisations, sélectionnez Attacher directement les politiques.

    6. Dans la liste des politiques d'autorisations, sélectionnez la CloudWatchAgentServerPolicy politique à ajouter à votre utilisateur.

    7. Choisissez Suivant.

    8. Sur la page Réviser et créer, assurez-vous que vous êtes satisfait du nom d'utilisateur et que la CloudWatchAgentServerPolicy politique figure dans le résumé des autorisations.

    9. Choisissez Create user (Créer un utilisateur).

    10. Créez et récupérez votre clé AWS d'accès et votre clé secrète  : dans le volet de navigation de la console IAM, choisissez Utilisateurs, puis sélectionnez le nom d'utilisateur de l'utilisateur que vous avez créé à l'étape précédente.

    11. Sur la page de l’utilisateur, ouvrez l’onglet Informations d’identification de sécurité.

    12. Dans la section Clés d’accès, sélectionnez Créer une clé d’accès.

    13. Pour Créer une clé d’accès – Étape 1, sélectionnez Interface de ligne de commande (CLI).

    14. Pour Créer une clé d’accès – Étape 2, ajoutez éventuellement une balise puis cliquez sur Suivant.

    15. Pour Créer une clé d’accès – Étape 3, sélectionnez Télécharger le fichier .csv pour enregistrer un fichier .csv avec la clé d’accès et la clé d’accès secrète de votre utilisateur IAM. Vous aurez besoin de ces informations pour l’étape suivante.

    16. Sélectionnez Exécuté.

    17. Configurez vos AWS informations d'identification sur votre hôte local en saisissant la commande suivante. Remplacez ACCESS_KEY_ID et SECRET_ACCESS_ID par votre clé d’accès et votre clé d’accès secrète nouvellement générées à partir du fichier .csv que vous avez téléchargé à l’étape précédente.

      
$ aws configure
AWS Access Key ID [None]: ACCESS_KEY_ID
AWS Secret Access Key [None]: SECRET_ACCESS_ID
Default region name [None]: MY_REGION
Default output format [None]: json
    Astuce

    Pour les hôtes locaux qui n'ont besoin que d'envoyer des métriques ou des journaux, vous pouvez utiliser l'authentification par jeton au porteur comme alternative plus simple à la configuration des clés d' AWS accès. Les jetons porteurs ne nécessitent pas l'aws configureétape ou les fichiers d'identification sur l'hôte. Pour de plus amples informations, veuillez consulter Configuration de l'authentification par jeton au porteur pour Metrics.

  4. Configurez les AWS informations d'identification pour vos clusters Amazon EKS ou Kubernetes. Le moyen le plus simple de démarrer avec Amazon EKS est d'utiliser le module complémentaire EKS OTel Container Insights. Si vous préférez utiliser le OpenTelemetry Collector directement, suivez la procédure ci-dessous pour configurer les AWS informations d'identification de vos clusters Amazon EKS ou Kubernetes auxquels envoyer des données de télémétrie. CloudWatch

    Setup IAM permissions for Amazon EKS

    1. Créez un fournisseur d’identité OIDC IAM pour votre cluster à l’aide de la commande suivante. 

      eksctl utils associate-iam-oidc-provider --cluster ${CLUSTER_NAME} --region ${REGION} --approve

    2. Attribuez des rôles IAM au compte de service Kubernetes pour OTel Collector à l’aide de la commande suivante.

      
eksctl create iamserviceaccount \
--name ${COLLECTOR_SERVICE_ACCOUNT}\
--namespace ${NAMESPACE} \
--cluster ${CLUSTER_NAME} \
--region ${REGION} \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--approve \
--override-existing-serviceaccounts
    Setup IAM permissions for Kubernetes

    1. Configurez vos AWS informations d'identification sur votre hôte local en saisissant la commande suivante. Remplacez ACCESS_KEY_ID et SECRET_ACCESS_ID par votre clé d'accès et votre clé d'accès secrète nouvellement générées à partir du fichier .csv que vous avez téléchargé à l'étape précédente. Par défaut, le fichier d'informations d'identification est enregistré sous/home/user/. aws/credentials. .

      
aws configure
AWS Access Key ID [None]: ACCESS_KEY_ID 
AWS Secret Access Key [None]: SECRET_ACCESS_ID 
Default region name [None]: MY_REGION 
Default output format [None]: json

    2. Modifiez la ressource OpenTelemetry Collector pour ajouter le secret d'identification AWS nouvellement créé à l'aide de la commande : kubectl edit OpenTelemetryCollector otel_collector

    3. À l'aide de l'éditeur de fichiers, ajoutez les AWS informations d'identification dans le OpenTelemetryCollector conteneur en ajoutant la configuration suivante en haut du déploiement. Remplacez le chemin /home/user/.aws/credentials par l'emplacement de votre fichier d' AWS informations d'identification local. 

      
                     spec:
                    volumeMounts:
                    - mountPath: /rootfs
                    volumeMounts:
                    - name: aws-credentials
                    mountPath: /root/.aws
                    readOnly: true
                    volumes:
                    - hostPath:
                    path: /home/user/.aws/credentials
                    name: aws-credentials

  5. Configurez l'exportateur OTLP dans la configuration de votre collecteur pour envoyer la télémétrie au terminal. CloudWatch Consultez les exemples ci-dessous.

Authentifiez-vous à l'aide d'un jeton porteur (clé API)

Si vous n'avez pas besoin de configurer les AWS informations d'identification sur l'hôte, par exemple lorsque vous exécutez sur des sites hors AWS infrastructure, sur d'autres fournisseurs de cloud ou sur des CI/CD pipelines, vous pouvez utiliser l'authentification par jeton au lieu de Sigv4. Les jetons porteurs sont pris en charge pour les points de terminaison des métriques et des journaux (des clés API distinctes sont requises pour chaque service). L'authentification par jeton du porteur n'est pas prise en charge pour les traces.

Pour les instructions de configuration, consultezConfiguration de l'authentification par jeton au porteur pour Metrics. Pour les journaux, voir Configuration de l'authentification par jeton du porteur pour les journaux.

Pour un exemple de configuration de collecteur utilisant des jetons de support, consultez l'exemple de métriques de jetons de support dans les exemples de configuration de collecteur ci-dessous.

Exemples de configuration de collecteurs

Copiez et collez le contenu ci-dessous pour configurer votre collecteur afin qu’il envoie les journaux et les traces aux points de terminaison OTLP.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp/logs:
    compression: gzip
    logs_endpoint: logs_otlp_endpoint
    headers: 
      x-aws-log-group: ency_log_group
      x-aws-log-stream: default
    auth:
      authenticator: sigv4auth/logs
      
  otlphttp/traces:
    compression: gzip
    traces_endpoint: traces_otlp_endpoint
    auth:
      authenticator: sigv4auth/traces

extensions:
  sigv4auth/logs:
    region: "region"
    service: "logs"
  sigv4auth/traces:
    region: "region"
    service: "xray"

service:
  telemetry:
  extensions: [sigv4auth/logs, sigv4auth/traces]
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlphttp/logs]
    traces:
      receivers: [otlp]
      exporters: [otlphttp/traces]

Voici un exemple d’envoi de journaux et de traces à l’aide de sigv4 vers us-east-1.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp/logs:
    compression: gzip
    logs_endpoint: https://logs.us-east-1.amazonaws.com/v1/logs
    headers: 
      x-aws-log-group: MyApplicationLogs
      x-aws-log-stream: default
    auth:
      authenticator: sigv4auth/logs
      
  otlphttp/traces:
    compression: gzip
    traces_endpoint: https://xray.us-east-1.amazonaws.com/v1/traces
    auth:
      authenticator: sigv4auth/traces

extensions:
  sigv4auth/logs:
    region: "us-east-1"
    service: "logs"
  sigv4auth/traces:
    region: "us-east-1"
    service: "xray"

service:
  telemetry:
  extensions: [sigv4auth/logs, sigv4auth/traces]
  pipelines:
    logs:
     receivers: [otlp]
      exporters: [otlphttp/logs]
    traces:
      receivers: [otlp]
      exporters: [otlphttp/traces]
Note

Configurez vos OpenTelemetry SDK selon une configuration d'échantillonnage permanente afin d'enregistrer de manière fiable des intervalles de 100 % et d'obtenir une visibilité complète de vos applications critiques grâce à Application Signals. CloudWatch Pour plus d'informations, consultez un exemple de configuration d'un sampler du SDK OpenTelemetry Java. Pour un exemple de configuration de OpenTelemetry Collector avec un point de terminaison X-Ray OTLP, consultez le référentiel de démonstration des signaux d'application.

Copiez et collez le contenu ci-dessous pour configurer votre collecteur afin qu'il envoie des métriques aux points de terminaison OTLP.

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"

processors:
  batch:
    send_batch_size: 200
    timeout: 10s

exporters:
  otlphttp:
    tls:
      insecure: false
    endpoint: metrics_otlp_endpoint
    auth:
      authenticator: sigv4auth

extensions:
  sigv4auth:
    service: "monitoring"
    region: "region"

service:
  extensions: [sigv4auth]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

Voici un exemple d'envoi de métriques à us-east-1 à l'aide de sigv4.

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"

processors:
  batch:
    send_batch_size: 200
    timeout: 10s

exporters:
  otlphttp:
    tls:
      insecure: false
    endpoint: "https://monitoring.us-east-1.amazonaws.com/v1/metrics:443"
    auth:
      authenticator: sigv4auth

extensions:
  sigv4auth:
    service: "monitoring"
    region: "us-east-1"

service:
  extensions: [sigv4auth]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

Métriques avec authentification par jeton au porteur

L'exemple suivant montre comment envoyer des métriques à us-east-1 à l'aide d'un jeton porteur. Pour les instructions de configuration et les meilleures pratiques de sécurité, consultezConfiguration de l'authentification par jeton au porteur pour Metrics.

extensions:
  bearertokenauth:
    filename: "/etc/otel/cw-api-key"

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"

processors:
  batch:
    send_batch_size: 200
    timeout: 10s

exporters:
  otlphttp:
    tls:
      insecure: false
    endpoint: "https://monitoring.us-east-1.amazonaws.com/v1/metrics"
    auth:
      authenticator: bearertokenauth

service:
  extensions: [bearertokenauth]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]
Important

Ne codez jamais en dur les clés d'API directement dans les fichiers de configuration du collecteur. Utilisez-le filename pour lire à partir d'un secret monté ou ${env:VAR} pour lire à partir d'une variable d'environnement injectée par votre gestionnaire de secrets.

Note

Contrairement à Sigv4, les jetons porteurs ne nécessitent pas de fichiers AWS d'informations d'identification, de rôles IAM ou de configuration IRSA. Le collecteur peut fonctionner sur n'importe quelle plateforme sans AWS dépendre du SDK.