AWS Elastic Beanstalk

Présentation

AWS Elastic Beanstalk est un service simple à prendre en main permettant de déployer et de mettre à l’échelle des applications et services Web développés avec Java, .NET, PHP, Node.js, Python, Ruby, Go et Docker sur des serveurs couramment utilisés, comme Apache, Nginx, Passenger et IIS.

Formule et utilisation

Liste des infrastructures

Si vous ne l’avez pas déjà fait, configurez d’abord l’intégration Amazon Web Services. Pour recevoir des métriques Elastic Beanstalk, vous devez activer la création de rapports d’intégrité améliorée pour votre environnement et configurer ce dernier de façon à ce qu’il publie des métriques de santé améliorées sur CloudWatch.

Remarque : ces paramètres augmentent les frais relatifs à vos métriques custom CloudWatch.

Real User Monitoring

Analyse d’entonnoirs

aws.elasticbeanstalk.application_latency_p_1_0
(gauge)
The average time to complete the fastest 10 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_5_0
(gauge)
The average time to complete the fastest 50 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_7_5
(gauge)
The average time to complete the fastest 75 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_8_5
(gauge)
The average time to complete the fastest 85 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_9_0
(gauge)
The average time to complete the fastest 90 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_9_5
(gauge)
The average time to complete the fastest 95 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_9_9
(gauge)
The average time to complete the fastest 99 percent of requests.
Shown as second
aws.elasticbeanstalk.application_latency_p_9_9_9
(gauge)
The average time to complete the fastest 99.9 percent of requests.
Shown as second
aws.elasticbeanstalk.application_requests_2xx
(count)
The number of requests that completed with a 2XX status code.
Shown as request
aws.elasticbeanstalk.application_requests_3xx
(count)
The number of requests that completed with a 3XX status code.
Shown as request
aws.elasticbeanstalk.application_requests_4xx
(count)
The number of requests that completed with a 4XX status code.
Shown as request
aws.elasticbeanstalk.application_requests_5xx
(count)
The number of requests that completed with a 5XX status code.
Shown as request
aws.elasticbeanstalk.application_requests_total
(count)
The number of requests completed by the instance or environment.
Shown as request
aws.elasticbeanstalk.cpuidle
(gauge)
[Instance] The percentage of time the CPU was in the idle state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpuiowait
(gauge)
[Instance] The percentage of time the CPU was in the iowait state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpuirq
(gauge)
[Instance] The percentage of time the CPU was in the interrupt request state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpunice
(gauge)
[Instance] The percentage of time the CPU was in the nice state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpusoftirq
(gauge)
[Instance] The percentage of time the CPU was in the soft interrupt request state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpusystem
(gauge)
[Instance] The percentage of time the CPU was in the system state in the last minute.
Shown as percent
aws.elasticbeanstalk.cpuuser
(gauge)
[Instance] The percentage of time the CPU was in the user state in the last minute.
Shown as percent
aws.elasticbeanstalk.environment_health
(gauge)
[Environment] The health status of the environment. The possible values are 0 (OK) 1 (Info) 5 (Unknown) 10 (No data) 15 (Warning) 20 (Degraded) and 25 (Severe).
aws.elasticbeanstalk.instance_health
(gauge)
[Instance] The health status of the instance.
Shown as instance
aws.elasticbeanstalk.instances_degraded
(count)
[Environment] The number of instances with Degraded health status.
Shown as instance
aws.elasticbeanstalk.instances_info
(count)
[Environment] The number of instances with Info health status.
Shown as instance
aws.elasticbeanstalk.instances_no_data
(count)
[Environment] The number of instances with no health status data.
Shown as instance
aws.elasticbeanstalk.instances_ok
(count)
[Environment] The number of instances with OK health status.
Shown as instance
aws.elasticbeanstalk.instances_pending
(count)
[Environment] The number of instances with Pending health status.
Shown as instance
aws.elasticbeanstalk.instances_severe
(count)
[Environment] The number of instances with Severe health status.
Shown as instance
aws.elasticbeanstalk.instances_unknown
(count)
[Environment] The number of instances with Unknown health status.
Shown as instance
aws.elasticbeanstalk.instances_warning
(count)
[Environment] The number of instances with Warning health status.
Shown as instance
aws.elasticbeanstalk.load_average_1min
(gauge)
[Instance] The average CPU load over the last minute.
aws.elasticbeanstalk.load_average_5min
(gauge)
[Instance] The average CPU load over the last five minutes.
aws.elasticbeanstalk.root_filesystem_util
(gauge)
[Instance] The percentage of disk space in use.
Shown as percent

Chacune des métriques récupérées à partir d’AWS se voit assigner les mêmes tags que ceux qui apparaissent dans la console AWS, y compris, mais sans s’y limiter, le hostname et les groupes de sécurité.

Aide

L’intégration AWS Elastic Beanstalk n’inclut aucun événement.

Aide

L’intégration AWS Elastic Beanstalk n’inclut aucun check de service.

Configuration de l’Agent Datadog

Les étapes décrites ci-dessous permettent de déployer l’Agent Datadog sur vos VM Elastic Beanstalk, afin que ces dernières transmettent des métriques de host. Ces métriques viennent compléter les métriques récupérées par l’intégration AWS. Lisez la section Pourquoi installer l’Agent Datadog sur mes instances cloud ? pour en savoir plus.

Sélectionnez votre méthode d’installation pour configurer l’Agent dans votre environnement Elastic Beanstalk :

Pour une configuration sans conteneurs, installez l’Agent Datadog dans Elastic Beanstalk à l’aide de la personnalisation d’environnement avancée avec fichiers de configuration (.ebextensions) :

  1. Créez un dossier intitulé .ebextensions à la racine du bundle des fichiers source de l’application.
  2. Téléchargez 99datadog.config et placez cette configuration dans le dossier .ebextensions.
  3. Remplacez la valeur de api_key dans le modèle de fichier pour /etc/datadog-agent/datadog.yaml par votre clé d’API Datadog.
  4. Remplacez la valeur de site dans /etc/datadog-agent/datadog.yaml par votre région Datadog (par exemple ) pour vous assurer que l’Agent envoie les données au bon site Datadog.
  5. Imposez une version spécifique de l’Agent en définissant DD_AGENT_VERSION dans option_settings. Ainsi, tous les hosts exécuteront la même version de l’Agent.
  6. Déployez votre application avec la console Elastic Beanstalk, l’interface de ligne de commande EB ou l’interface de ligne de commande AWS.

Vous pouvez ajouter des paramètres d’Agent supplémentaires dans /etc/datadog-agent/datadog.yaml.

Par exemple, pour activer la surveillance des live processes, définissez ce qui suit :

process_config:
  enabled: "true"

Collecte de traces

Lorsque l’application n’est pas conteneurisée et que l’Agent Datadog est configuré avec 99datadog.config, le tracing est activé sans aucune configuration supplémentaire requise, à condition que l’application soit instrumentée avec la configuration de bibliothèques de tracing.

Pour une configuration sans conteneurs, installez l’Agent Datadog dans Elastic Beanstalk à l’aide de la personnalisation d’environnement avancée avec fichiers de configuration (.ebextensions) :

  1. Créez un dossier intitulé .ebextensions à la racine du bundle des fichiers source de l’application.
  2. Téléchargez 99datadog-windows.config et déplacez cette configuration vers le dossier .ebextensions.
  3. Dans 99datadog-windows.config, remplacez la valeur APIKEY par votre clé d’API Datadog.
  4. (Facultatif) Le fichier 99datadog-windows.config ajoute la bibliothèque de tracing APM .NET afin de générer des traces. Si vous ne souhaitez pas activer APM dans votre environnement, supprimez les sections packages, 02_setup-APM1 et 03_setup-APM2.
  5. (Facultatif) Pour ajouter des variables d’environnement, définissez-les à la section 00_setup-env1 du fichier 99datadog-windows.config. Si vous n’avez pas besoin d’utiliser de variables d’environnement, vous êtes libre de supprimer cette section.
  6. Déployez votre application avec la console Elastic Beanstalk, l’interface de ligne de commande EB ou l’interface de ligne de commande AWS.

Collecte de traces

Lorsque l’application n’est pas conteneurisée et que l’Agent Datadog est configuré avec 99datadog-windows.config, le tracing est activé sans aucune configuration supplémentaire. Pour en savoir plus sur l’instrumentation du tracing, consultez la documentation relative à la configuration de la solution APM Datadog.

Pour une configuration sur un conteneur Docker unique, installez l’Agent Datadog dans Elastic Beanstalk à l’aide de la personnalisation d’environnement avancée avec fichiers de configuration (.ebextensions).

Remarque : pour définir cette configuration, vous devez placer votre clé d’API dans votre répertoire .ebextensions, qui fait partie du code source. Utilisez AWS Secret Manager ou une autre solution de gestion de secrets pour protéger votre clé d’API.

  1. Créez un dossier intitulé .ebextensions à la racine du bundle des fichiers source de l’application.
  2. Téléchargez 99datadog.config et placez cette configuration dans le dossier .ebextensions.
  3. Remplacez la valeur de api_key dans le modèle de fichier pour /etc/datadog-agent/datadog.yaml par votre clé d’API Datadog.
  4. Remplacez la valeur de site dans /etc/datadog-agent/datadog.yaml par votre région Datadog (par exemple ) pour vous assurer que l’Agent envoie les données au bon site Datadog.
  5. Imposez une version spécifique de l’Agent en définissant DD_AGENT_VERSION dans option_settings. Ainsi, tous les hosts exécuteront la même version de l’Agent.
  6. Déployez votre application avec la console Elastic Beanstalk, l’interface de ligne de commande EB ou l’interface de ligne de commande AWS.

Vous pouvez ajouter des paramètres d’Agent supplémentaires dans /etc/datadog-agent/datadog.yaml.

Par exemple, pour activer la surveillance des live processes, définissez ce qui suit :

process_config:
  enabled: "true"

Collecte de traces

Pour activer le tracing pour des conteneurs Docker uniques :

  1. Modifiez la section /etc/datadog-agent/datadog.yaml du fichier 99datadog.config en ajoutant apm_non_local_traffic avec le format suivant :

    apm_config:
      enabled: "true"
      apm_non_local_traffic: "true"
    
  2. Configurez les bibliothèques de tracing de manière à faire passer les traces par l’IP de passerelle du pont, qui correspond par défaut à 172.17.0.1 à l’intérieur du conteneur d’application. Si vous n’êtes pas sûr de l’IP de passerelle, exécutez la commande docker inspect <id conteneur> pour la vérifier.

Pour tous les langages, définissez la variable d’environnement DD_AGENT_HOST sur l’IP de passerelle. Pour les langages ci-dessous, vous pouvez également définir le nom du host par programmation comme suit :

Collecte d’erreurs du navigateur
from ddtrace import tracer

tracer.configure(hostname="172.17.0.1")
.NET
const tracer = require('dd-trace');

tracer.init({ hostname: "172.17.0.1" });
Modifier des données et leur contexte
require 'ddtrace'

Datadog.configure do |c|
  c.tracer hostname: "172.17.0.1")
end
Données collectées
package main

import (
    "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer"
)

func main() {
  tracer.Start(tracer.WithAgentAddr("172.17.0.1"))
  defer tracer.Stop()

  // ...
}

Si vous avez plusieurs conteneurs Docker, utilisez l’Agent Datadog conteneurisé pour surveiller l’utilisation de Docker avec un fichier intitulé Dockerrun.aws.json.

Un fichier Dockerrun.aws.json est un fichier JSON propre à Elastic Beanstalk qui décrit comment déployer un ensemble de conteneurs Docker sous la forme d’une application Elastic Beanstalk. Vous pouvez utiliser ce fichier pour un environnement Docker à conteneurs multiples. Dockerrun.aws.json décrit les conteneurs à déployer sur chaque instance de conteneur dans l’environnement et les volumes de données à créer sur l’instance du host, qui seront montés par les conteneurs.

Un fichier Dockerrun.aws.json peut être utilisé de façon autonome ou compressé avec du code source supplémentaire dans une archive unique. Le code source archivé dans Dockerrun.aws.json est déployé dans les instances de conteneur et accessible dans le répertoire /var/app/current/. Utilisez la section volumes de la configuration pour fournir des points de montage aux conteneurs s’exécutant sur l’instance. Utilisez la section mountPoints des définitions de conteneurs intégrés pour les monter depuis les conteneurs.

L’exemple de code suivant correspond à un Dockerrun.aws.json déclarant l’Agent Datadog. Mettez à jour la section containerDefinitions en ajoutant votre clé d’API Datadog, vos tags (facultatif) et toutes les définitions de conteneur supplémentaires. Si besoin, ce fichier peut être compressé avec du contenu supplémentaire, comme décrit ci-dessus. Pour obtenir plus d’informations sur la syntaxe de ce fichier, consultez Configuration Docker multi-conteneurs.

Remarques :

  • En cas d’utilisation intense des ressources, il se peut que vous ayez besoin de rehausser la limite de mémoire.
  • Pour vous assurer que tous les hosts exécutent la même version de l’Agent, nous vous conseillons de remplacer agent:7 par une version mineure spécifique de l’image Docker.

  • Définissez DD_SITE sur pour vous assurer que l’Agent envoie les données au bon site Datadog.

{
    "AWSEBDockerrunVersion": 2,
    "volumes": [
        {
            "name": "docker_sock",
            "host": {
                "sourcePath": "/var/run/docker.sock"
            }
        },
        {
            "name": "proc",
            "host": {
                "sourcePath": "/proc/"
            }
        },
        {
            "name": "cgroup",
            "host": {
                "sourcePath": "/cgroup/"
            }
        }
    ],
    "containerDefinitions": [
        {
            "name": "dd-agent",
            "image": "gcr.io/datadoghq/agent:7",
            "environment": [
                {
                    "name": "DD_API_KEY",
                    "value": "<VOTRE_CLÉ_API_DD>"
                },
                {
                    "name": "DD_SITE",
                    "value": "<VOTRE_SITE_DD>"
                },
                {
                    "name": "DD_TAGS",
                    "value": "<TAG_SIMPLE>, <TAG_KEY:VALUE>"
                }
            ],
            "memory": 256,
            "mountPoints": [
                {
                    "sourceVolume": "docker_sock",
                    "containerPath": "/var/run/docker.sock",
                    "readOnly": false
                },
                {
                    "sourceVolume": "proc",
                    "containerPath": "/host/proc",
                    "readOnly": true
                },
                {
                    "sourceVolume": "cgroup",
                    "containerPath": "/host/sys/fs/cgroup",
                    "readOnly": true
                }
            ]
        }
    ]
}

Création de l’environnement

Une fois la définition du conteneur prête, envoyez-la à Elastic Beanstalk. Pour obtenir des instructions précises, consultez Environnements Docker multi-conteneurs dans la documentation AWS Elastic Beanstalk.

Aide

Pour recueillir des métriques custom depuis le conteneur de votre application en utilisant DogStatsD dans l’environnement Docker à conteneurs multiples, ajoutez les éléments suivants à votre fichier Dockerrun.aws.json :

  1. Ajoutez la variable d’environnement DD_DOGSTATSD_NON_LOCAL_TRAFFIC sous le conteneur dd-agent :

    {
      "name": "DD_DOGSTATSD_NON_LOCAL_TRAFFIC",
      "value": "true"
    }
    
  2. Ajoutez un lien vers le conteneur dd-agent sous le conteneur de votre application :

    "links": [ "dd-agent:dd-agent"]
    

Consultez la section DogStatsD et Docker pour en savoir plus.

Conteneurs Docker multiples

  1. Dans le même fichier Dockerrun.aws.json que celui de l’application, ajoutez un conteneur de l’Agent Datadog à l’aide de l’image datadog/agent. Ajoutez ensuite ce qui suit :
    • Sous la section portMappings, ajoutez un hostPort 8126 avec le containerPort 8126.
    • Sous la section environment, définissez DD_APM_ENABLED et DD_APM_NON_LOCAL_TRAFFIC sur true.
  2. Sous le conteneur de votre application, qui a été instrumenté avec la [configuration de bibliothèques de tracing][14], ajoutez ce qui suit :
    • Sous la section environment, ajoutez une variable d’environnement DD_AGENT_HOST ayant pour valeur le nom du conteneur de l’Agent Datadog.
    • Sous la section links section, définissez le conteneur de l’Agent afin de l’utiliser comme une variable d’environnement.

Vous trouverez un exemple ci-dessous :

 "containerDefinitions": [    {
      "name": "dd-agent",
      "image": "datadog/agent:latest",
      "environment": [
          {
              "name": "DD_API_KEY",
              "value": "<clé api>"
          },
          {
              "name": "DD_APM_ENABLED",
              "value": "true"
          },
          {
             "name": "DD_APM_NON_LOCAL_TRAFFIC",
             "value": "true"
          },
         # toute autre variable d'environnement requise 
      ],
      "portMappings": [
        {
          "hostPort": 8126,
          "containerPort": 8126
        }
      ],
      "memory": 256,
      "mountPoints": [
          # tout autre mountpoint requis
         }
      ]
    },
    {
      "name": "application-container",
      "image": "<nom image application>",
      "environment": [
        {
          "name": "DD_AGENT_HOST",
          "value": "dd-agent",
          # toute autre variable d'environnement requise
        }
      ],
      "links": [
        "dd-agent:dd-agent"
      ],

Aide

Besoin d’aide ? Contactez l’assistance Datadog.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

PREVIEWING: rtrieu/product-analytics-ui-changes