AWS

Crawler

Présentation

Associez Amazon Web Services (AWS) pour :

• Consulter des mises à jour automatiques de statut AWS dans votre flux
• Obtenir des métriques CloudWatch pour les hosts EC2 sans installer l’Agent
• Appliquer un tag à vos hosts EC2 comportant des informations spécifiques à EC2 (p. ex., leur zone de disponibilité)
• Consulter les événements de maintenance EC2 planifiés dans votre flux
• Recueillir des métriques et des événements CloudWatch depuis de nombreux autres produits AWS

Les intégrations connexes comprennent :

Implémentation

Installation

La configuration de l’intégration de Datadog à Amazon Web Services nécessite la configuration de la délégation de rôles à l’aide d’AWS IAM. Pour mieux comprendre le principe de délégation des rôles, reportez-vous au guide des bonnes pratiques pour AWS IAM.

1. Créez un rôle dans la console IAM d’AWS.
2. Sélectionnez le type de rôle Another AWS account.
3. Pour Account ID, saisissez 464622532012 (identifiant de compte Datadog). Cela signifie que vous accordez à Datadog un accès en lecture seule à vos données AWS.
4. Décochez la case Require external ID et saisissez l’ID généré dans l’application Datadog. Assurez-vous de ne pas cocher Require MFA. Pour en savoir plus sur l’External ID, consultez ce document du guide de l’utilisateur d’IAM.
5. Cliquez sur Next: Permissions.
6. Si vous avez déjà créé la stratégie, sélectionnez-la sur cette page, puis passez à l’étape 12. Si ce n’est pas le cas, cliquez sur Create Policy afin d’ouvrir une nouvelle fenêtre.
7. Sélectionnez l’onglet JSON. Afin de profiter de toutes les intégrations AWS proposées par Datadog, utilisez l’extrait de stratégie sous la zone de texte. Étant donné que d’autres composants sont ajoutés à une intégration, ces autorisations peuvent évoluer.
8. Cliquez sur Review policy.
9. Nommez la stratégie DatadogAWSIntegrationPolicy ou utilisez le nom de votre choix, et saisissez une description pertinente.
10. Cliquez sur Create policy. Vous pouvez ensuite fermer cette fenêtre.
11. Depuis la fenêtre « Create role », actualisez la liste des stratégies et sélectionnez celle que vous venez de créer.
12. Cliquez sur Next: Review.
13. Saisissez le nom DatadogAWSIntegrationRole ou un nom similaire pour le rôle, ainsi qu’une description pertinente. Cliquez sur Create role.

Étape facultative : si vous utilisez Terraform, configurez votre stratégie IAM Datadog à l’aide de l’intégration d’AWS à Terraform.

Stratégie IAM AWS Datadog

Les autorisations énumérées ci-dessous sont incluses dans le document de stratégie à l’aide de wildcards comme List* et Get*. Si vous avez besoin de stratégies strictes, utilisez les noms d’action complets indiqués et consultez la documentation sur l’API Amazon pour les services requis.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "autoscaling:Describe*",
        "budgets:ViewBudget",
        "cloudfront:GetDistributionConfig",
        "cloudfront:ListDistributions",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "codedeploy:List*",
        "codedeploy:BatchGet*",
        "directconnect:Describe*",
        "dynamodb:List*",
        "dynamodb:Describe*",
        "ec2:Describe*",
        "ecs:Describe*",
        "ecs:List*",
        "elasticache:Describe*",
        "elasticache:List*",
        "elasticfilesystem:DescribeFileSystems",
        "elasticfilesystem:DescribeTags",
        "elasticloadbalancing:Describe*",
        "elasticmapreduce:List*",
        "elasticmapreduce:Describe*",
        "es:ListTags",
        "es:ListDomainNames",
        "es:DescribeElasticsearchDomains",
        "health:DescribeEvents",
        "health:DescribeEventDetails",
        "health:DescribeAffectedEntities",
        "kinesis:List*",
        "kinesis:Describe*",
        "lambda:AddPermission",
        "lambda:GetPolicy",
        "lambda:List*",
        "lambda:RemovePermission",
        "logs:TestMetricFilter",
        "logs:PutSubscriptionFilter",
        "logs:DeleteSubscriptionFilter",
        "logs:DescribeSubscriptionFilters",
        "rds:Describe*",
        "rds:List*",
        "redshift:DescribeClusters",
        "redshift:DescribeLoggingStatus",
        "route53:List*",
        "s3:GetBucketLogging",
        "s3:GetBucketLocation",
        "s3:GetBucketNotification",
        "s3:GetBucketTagging",
        "s3:ListAllMyBuckets",
        "s3:PutBucketNotification",
        "ses:Get*",
        "sns:List*",
        "sns:Publish",
        "sqs:ListQueues",
        "support:*",
        "tag:GetResources",
        "tag:GetTagKeys",
        "tag:GetTagValues",
        "xray:BatchGetTraces",
        "xray:GetTraceSummaries"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "ec2:Describe*",
        "support:*",
        "tag:GetResources",
        "tag:GetTagKeys",
        "tag:GetTagValues"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Configuration

• Dropdown

1. Ouvrez le carré d’intégration AWS.
2. Sélectionnez l’onglet Role Delegation.
3. Saisissez votre ID de compte AWS sans tiret, p. ex. 123456789012 et non 1234-5678-9012. Votre ID de compte est indiqué dans l’ARN du rôle créé durant l’installation de l’intégration AWS. Saisissez ensuite le nom du rôle créé. Remarque : le nom du rôle saisi dans le carré d’intégration est sensible à la casse et doit correspondre parfaitement au nom de rôle créé sur AWS.
4. Choisissez les services pour lesquels vous souhaitez récupérer des métriques sur le côté gauche de la fenêtre de dialogue. Vous pouvez également ajouter des tags à l’ensemble des hosts et métriques. De même, si vous souhaitez uniquement surveiller un sous-ensemble d’instances EC2 sur AWS, appliquez-leur un tag et indiquez ce tag dans la zone de texte « limite » de cette page.
5. Cliquez sur Install Integration.

1. Ouvrez le carré d’intégration AWS.
2. Sélectionnez l’onglet Access Keys (GovCloud or China Only).
3. Saisissez votre clé d’accès et votre clé de secret AWS. Seules les clés d’accès et de secret pour GovCloud et la Chine sont acceptées.
4. Choisissez les services pour lesquels vous souhaitez récupérer des métriques sur le côté gauche de la fenêtre de dialogue. Vous pouvez également ajouter des tags à l’ensemble des hosts et métriques. De même, si vous souhaitez uniquement surveiller un sous-ensemble d’instances EC2 sur AWS, appliquez-leur un tag et indiquez ce tag dans la zone de texte « limite » de cette page.
5. Cliquez sur Install Integration.

Collecte de logs

Les logs de service AWS sont recueillis via la fonction Lambda de Datadog. Ce Lambda, qui se déclenche sur les compartiments S3, les groupes de logs CloudWatch et les événements CloudWatch, transmet des logs à Datadog.

Pour commencer à recueillir des logs à partir de vos services AWS :

1. Configurez la fonction Lambda de Datadog.
2. Activez la journalisation pour votre service AWS (la plupart des services AWS peuvent se connecter à un compartiment S3 ou à un groupe de logs CloudWatch).

3. Configurez les déclencheurs entraînant l’exécution du lambda. Il existe deux façons de les configurer :

   • automatiquement : Datadog récupère les logs pour les services AWS sélectionnés et les ajoute en tant que déclencheurs pour la fonction Lambda de Datadog. Datadog met également la liste à jour.
   • manuellement : configurez vous-même chaque déclencheur via la console AWS.

Configurer la fonction Lambda de Datadog

Pour ajouter le Lambda de transmission de logs à Datadog sur votre compte AWS, vous pouvez utiliser le référentiel sans serveur AWS ou créer manuellement un nouveau Lambda.

Référentiel sans serveur AWS

Utilisez le référentiel sans serveur AWS pour déployer la fonction Lambda sur votre compte AWS.

Créer manuellement un nouveau Lambda

Créer une fonction Lambda

1. Accédez à la console Lambda et créez une nouvelle fonction :

2. Sélectionnez Author from scratch et saisissez un nom unique pour la fonction.

3. Définissez Runtime sur Python 2.7, Python 3.6 ou Python 3.7.

4. Pour Role, sélectionnez Create new role from template(s) et saisissez un nom unique pour le rôle.

5. Si vous récupérez des logs à partir d’un compartiment S3, sous « Policy templates », sélectionnez s3 object read-only permissions.

6. Sélectionnez Create Function.

Fournir le code et configurer le Lambda

1. Copiez le code depuis ce référentiel et collez-le dans le champ de code de la fonction.
2. Assurez-vous que le gestionnaire indique lambda_function.lambda_handler.

3. En haut du script se trouve une section intitulée #DD_API_KEY: Datadog API Key. Vous pouvez fournir la clé d’API requise par la fonction Lambda de deux façons différentes :

   • En configurant une variable d’environnement (conseillé)
   • Modifiez directement le code avec votre clé d’API Datadog.

4. Si vous utilisez le site européen de Datadog, définissez DD_SITE sur datadoghq.eu en tant que variable d’environnement ou directement dans le code.

5. Faites défiler jusqu’à atteindre Basic Settings sous la zone de code intégrée.

6. Définissez la mémoire sur une valeur proche de 1 Go.

7. Définissez le délai d’expiration sur 120 secondes.

8. Définissez l’option Execution Role sur le rôle créé précédemment.

9. Faites défiler vers le bas vers la section Concurrency et définissez l’option Reserve concurrency sur 100.

10. Ajoutez la couche Lambda de Datadog à l’aide de l’ARN suivante. Remplacez us-east-1 par la région où votre fonction est déployée et remplacez Python27 par le runtime Python que votre fonction utilise (Python27, Python36 ou Python37).

    arn:aws:lambda:us-east-1:464622532012:layer:Datadog-Python27:5
    

11. Faites défiler vers le haut de la page et cliquez sur Save.

Tester votre Lambda

1. Cliquez sur Test.
2. Sélectionnez CloudWatch Logs comme événement de test.

3. Saisissez un nom unique pour l’événement, puis cliquez sur Create.
4. Cliquez sur Test et vérifiez qu’aucune erreur ne survient (les logs de test n’apparaîtront pas dans votre plateforme Datadog).

Paramètres avancés

Site Datadog

La variable d’environnement DD_SITE définit le site Datadog vers lequel les informations doivent être envoyées. Utilisez datadoghq.com pour le site américain de Datadog (valeur par défaut) ou datadoghq.eu pour le site européen de Datadog.

Proxy

Deux variables d’environnement sont disponibles pour faire passer les logs par un proxy :

• DD_URL : définit l’endpoint du proxy vers lequel les logs doivent être transmis.
• DD_PORT : définit le port du proxy vers lequel les logs doivent être transmis.

Envoyer les logs par TCP ou HTTP

Par défaut, le forwarder envoie les logs en HTTPS par l’intermédiaire du port 443. Pour envoyer les logs en passant par une connexion TCP chiffrée par SSL, définissez la variable d’environnement DD_USE_TCP sur true. Lorsque le TCP est activé, le port 10516 est utilisé pour le site américain de Datadog et le port 1883 est utilisé pour le site européen de Datadog.

Ajouter des règles de filtrage ou de remplacement à l’aide de variables d’environnement

Règles de remplacement

Plusieurs options de nettoyage sont disponibles : REDACT_IP et REDACT_EMAIL trouvent les expressions codées en dur, alors que DD_SCRUBBING_RULE permet aux utilisateurs de spécifier une expression régulière.

• Pour utiliser REDACT_IP, ajoutez-la comme variable d’environnement et définissez sa valeur sur true.
  • Le texte correspondant à \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} est remplacé par xxx.xxx.xxx.xxx.
• Pour utiliser REDACT_EMAIL, ajoutez-la comme variable d’environnement et définissez sa valeur sur true.
  • Le texte correspondant à [a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+ est remplacé par xxxxx@xxxxx.com.
• Pour utiliser DD_SCRUBBING_RULE, ajoutez-la comme variable d’environnement et entrez une expression régulière pour définir sa valeur.
  • Par défaut, le texte correspondant à l’expression régulière spécifiée par l’utilisateur est remplacé par xxxxx.
  • Utilisez la variable d’environnement DD_SCRUBBING_RULE_REPLACEMENT pour spécifier une valeur en remplacement de xxxxx.
• Les règles de nettoyage sont appliquées à l’intégralité du log au format JSON, y compris aux métadonnées automatiquement ajoutées par la fonction Lambda.
• Chaque expression correspondante est remplacée jusqu’à ce qu’aucune correspondance ne soit trouvée dans chaque log.

Règles de filtrage

Utilisez les variables d’environnement EXCLUDE_AT_MATCH OU INCLUDE_AT_MATCH pour filtrer les logs en fonction d’une expression régulière.

• Pour utiliser EXCLUDE_AT_MATCH, ajoutez-la comme variable d’environnement et entrez une expression régulière pour définir sa valeur. Les logs correspondant à l’expression régulière sont exclus.
• Pour utiliser INCLUDE_AT_MATCH, ajoutez-la comme variable d’environnement et entrez une expression régulière pour définir sa valeur. Les logs non exclus par EXCLUDE_AT_MATCH et correspondant à l’expression régulière sont inclus.
• Si un log correspond à la fois aux critères d’inclusion et d’exclusion, il est exclus.
• Les règles de filtrage sont appliquées à l’intégralité du log au format JSON, y compris aux métadonnées automatiquement ajoutées par la fonction.

Pensez à tester votre Lambda après avoir configuré les paramètres avancés pour vérifier qu’aucune erreur ne se produit.

Prise en charge des logs multiligne pour S3

Pour traiter les logs multiligne dans S3, définissez la variable d’environnement DD_MULTILINE_LOG_REGEX_PATTERN sur l’expression régulière spécifiée pour la détection d’une nouvelle ligne de log.

Exemple : pour les logs multiligne commençant par l’expression 11/10/2014, utilisez : DD_MULTILINE_LOG_REGEX_PATTERN="\d{2}\/\d{2}\/\d{4}"

Activer la journalisation pour votre service AWS

Tous les services AWS qui génèrent des logs dans un compartiment S3 ou un groupe de logs CloudWatch sont pris en charge. Consultez les instructions de configuration spécifiques des services les plus utilisés dans le tableau ci-dessous :

Envoyer des logs de service AWS à Datadog

Vous pouvez choisir entre deux options pour la configuration des déclencheurs de la fonction Lambda de Datadog :

• Configurer manuellement des déclencheurs sur des compartiments S3, des groupes de logs CloudWatch ou des événements CloudWatch.
• Laisser Datadog définir et gérer automatiquement la liste des déclencheurs.

Configurer automatiquement des déclencheurs

Si vous stockez des logs dans de nombreux compartiments S3 ou groupes de logs CloudWatch, Datadog peut gérer automatiquement les déclencheurs à votre place.

1. Si vous ne l’avez pas déjà fait, configurez la fonction Lambda de collecte de logs AWS avec Datadog.

2. Le référentiel sans serveur AWS déploie la fonction Lambda sur le compte et crée un rôle, généralement avec un nom comme ‘serverlessrepo-Datadog-Log-loglambdaddfunctionRole-xyz’. Toutefois, une stratégie doit être appliquée à ce rôle avec le nombre d’autorisations adéquat. Habituellement, le rôle est associé à une stratégie n’ayant pas suffisamment d’autorisations pour que l’enregistrement de la fonction Lambda fonctionne. Ajoutez toutes les autorisations requises énumérées ci-dessous à la stratégie faisant partie du rôle de la fonction Lambda de Datadog en utilisant la console IAM. Il s’agit des autorisations déjà utilisées dans l’intégration Datadog/AWS. Une autre méthode permettant de mettre à jour les autorisations de la stratégie associée au rôle de la fonction Lambda consiste à associer une deuxième stratégie, celle qui est utilisée par l’intégration Datadog/AWS. Les descriptions ci-dessous expliquent comment ces autorisations sont utilisées :

   "cloudfront:GetDistributionConfig",
   "cloudfront:ListDistributions",
   "elasticloadbalancing:DescribeLoadBalancers",
   "elasticloadbalancing:DescribeLoadBalancerAttributes",
   "lambda:AddPermission",
   "lambda:GetPolicy",
   "lambda:RemovePermission",
   "redshift:DescribeClusters",
   "redshift:DescribeLoggingStatus",
   "s3:GetBucketLogging",
   "s3:GetBucketLocation",
   "s3:GetBucketNotification",
   "s3:ListAllMyBuckets",
   "s3:PutBucketNotification",
   "logs:PutSubscriptionFilter",
   "logs:DeleteSubscriptionFilter",
   "logs:DescribeSubscriptionFilters"
   

1. Accédez à l’onglet Collect logs dans le carré d’intégration AWS.
2. Sélectionnez le compte AWS à partir duquel vous souhaitez recueillir des logs, puis saisissez l’ARN du Lambda créé dans la section précédente.

3. Cochez les services à partir desquels vous souhaitez recueillir des logs et cliquez sur « Save ». Pour arrêter la collecte de logs d’un service spécifique, décochez la case associée.

4. Si vous possédez des logs dans plusieurs régions, vous devez créer des fonctions Lambda supplémentaires dans ces régions et les indiquer dans ce carré.
5. Pour arrêter la collecte de l’ensemble des logs AWS, appuyez sur la croix en regard de chaque ARN de Lambda. Tous les déclencheurs de cette fonction seront supprimés.
6. Quelques minutes après cette première configuration, vos logs AWS apparaîtront dans votre page Log Explorer Datadog, quasiment en temps réel.

Configurer manuellement des déclencheurs

Collecte de logs depuis un groupe de logs CloudWatch

Si vous stockez des logs dans un groupe de logs CloudWatch, suivez les étapes ci-dessous pour les transmettre à Datadog :

1. Si vous ne l’avez pas déjà fait, configurez la fonction Lambda de collecte de logs AWS avec Datadog.
2. Une fois la fonction Lambda installée, ajoutez manuellement un déclencheur dans la console AWS sur le groupe de logs CloudWatch qui contient vos logs :

Sélectionnez le groupe de logs CloudWatch correspondant, ajoutez un nom de filtre (vous pouvez toutefois laisser le filtre vide) et ajoutez le déclencheur :

Accédez ensuite à la section Log de Datadog pour commencer à explorer vos logs !

Collecte de logs depuis des compartiments S3

Si vous stockez des logs dans un compartiment S3, suivez les étapes ci-dessous pour les transmettre à Datadog :

1. Si vous ne l’avez pas déjà fait, configurez la fonction Lambda de collecte de logs AWS avec Datadog.

2. Une fois la fonction Lambda installée, ajoutez manuellement un déclencheur dans la console AWS sur le compartiment S3 qui contient vos logs :

3. Sélectionnez le compartiment, puis suivez les instructions d’AWS :

4. Définissez le bon type d’événement sur les compartiments S3 :

Accédez ensuite à la section Log de Datadog pour commencer à explorer vos logs !

Données collectées

Métriques

Événements

Vous pouvez configurer la collecte d’événements AWS pour chaque service AWS. Consultez la documentation des différents services AWS pour en savoir plus sur la collecte d’événements.

Dépannage

Vous constatez un écart entre vos données dans CloudWatch et Datadog ?

Il est important de tenir compte des deux distinctions suivantes :

1. Pour les counters AWS, un graphique défini sur « sum » « 1minute » affiche le nombre total d’occurrences en l’espace d’une minute, soit le taux par minute. Datadog affiche les données brutes à partir des valeurs AWS normalisées par seconde, peu importe l’intervalle sélectionné dans AWS. Cela explique pourquoi la valeur affichée dans Datadog peut être plus faible.
2. Les valeurs minimales, maximales et moyennes n’ont généralement pas la même signification dans AWS et dans Datadog. Dans AWS, les latences moyenne, minimale et maximale correspondent à trois métriques distinctes recueillies. Lorsque Datadog récupère des métriques à partir d’AWS CloudWatch, la latence moyenne est transmise sous la forme de séries temporelles distinctes par ELB. Dans Datadog, lorsque vous sélectionnez les valeurs « min », « max » ou « avg », vous définissez les critères de rassemblement de séries temporelles. Par exemple, si vous cherchez à obtenir system.cpu.idle sans appliquer de filtre, une série est envoyée pour chaque host qui renvoie cette métrique. Ces séries doivent être combinées pour être représentées graphiquement. À l’inverse, si vous cherchez à obtenir system.cpu.idle pour un seul host, aucune agrégation n’est nécessaire. Les valeurs maximale et moyenne sont identiques.

Métriques en retard

Lorsque vous utilisez l’intégration AWS, Datadog récupère vos métriques via l’API CloudWatch. Il est possible que les données des métriques AWS accusent un léger retard, en raison des contraintes liées à l’API.

Pour commencer, l’API CloudWatch propose uniquement une analyse métrique par métrique afin d’extraire des données. Les API CloudWatch prévoient une limite de débit qui varie en fonction des informations d’authentification, de la région et du service. Les métriques sont transmises par AWS en fonction du niveau du compte. Par exemple, si vous payez pour des « métriques détaillées » dans AWS, vous y avez accès plus rapidement. Ce niveau de service pour les métriques détaillées s’applique également à la granularité. Ainsi, certaines métriques sont transmises toutes les minutes, tandis que d’autres sont envoyées toutes les cinq minutes.

Datadog vous permet de hiérarchiser certaines métriques d’un compte afin de les récupérer en priorité, en fonction de certaines circonstances. Contactez l’assistance Datadog pour en savoir plus.

Pour obtenir des métriques quasiment en temps réel, installez l’Agent Datadog sur le host. Pour en savoir plus, consultez l’article de blog de Datadog Tout ce dont vous devez savoir pour effectuer une surveillance à partir d’Agents (en anglais).

Métriques manquantes

L’API CloudWatch renvoie uniquement les métriques avec des points de données. Ainsi, si un ELB ne possède aucune instance liée, aucune métrique associée à cet ELB n’apparaît dans Datadog.

Nombre aws.elb.healthy_host_count incorrect

Lorsque l’option d’équilibrage des charges entre zones est activée sur un ELB, toutes les instances liées à cet ELB font partie de toutes les zones de disponibilité (pour CloudWatch). Ainsi, si vous possédez deux instances dans 1a et trois dans ab, la métrique affiche cinq instances par zone de disponibilité. Puisque cela peut s’avérer contre-intuitif, nous avons ajouté de nouvelles métriques, aws.elb.healthy_host_count_deduped et aws.elb.un_healthy_host_count_deduped, qui affichent le nombre d’instances saines et non saines par zone de disponibilité, que vous ayez activé ou non l’option d’équilibrage des charges entre zones.

Hosts dupliqués lors de l’installation de l’Agent

Lors de l’installation de l’Agent sur un host AWS, il est possible que des hosts soient dupliqués pendant quelques heures sur la page d’infrastructure si vous avez défini manuellement le hostname dans la configuration de l’Agent. Ces doublons disparaîtront après quelques heures et ne seront pas pris en compte durant la facturation.