Tests HTTP

Présentation

Les tests HTTP vous permettent d’envoyer des requêtes HTTP aux endpoints d’API de vos applications pour vérifier les réponses et les conditions définies, y compris le temps de réponse global, le code de statut attendu, l’en-tête ou le contenu du corps.

Les tests HTTP peuvent être exécutés depuis des emplacements gérés et des emplacements privés, selon que vous souhaitez exécuter le test à l’extérieur ou à l’intérieur de votre réseau. Les tests HTTP peuvent être exécutés de façon récurrente, à la demande ou directement dans vos pipelines de CI/CD.

Configuration

Après avoir choisi de créer un test HTTP, définissez la requête de votre test.

Définir la requête

  1. Choisissez une valeur pour HTTP Method et indiquez l’URL à interroger. Les méthodes disponibles sont GET, POST, PATCH, PUT, HEAD, DELETE et OPTIONS. Les URL http et https sont prises en charge.

  2. Enrichissez votre requête HTTP en modifiant les réglages de la section Advanced Options (facultatif) :

      • Follow redirects : sélectionnez cette option pour que le test HTTP suive jusqu’à dix redirections lors de l’exécution de la requête.
      • Request headers : définissez les en-têtes à ajouter à votre requête HTTP. Vous pouvez également remplacer les en-têtes par défaut (par exemple, l’en-tête user-agent).
      • Cookies : définissez les cookies à ajouter à votre requête HTTP. Définissez plusieurs cookies en suivant le format <COOKIE_NOM1>=<COOKIE_VALEUR1>; <COOKIE_NOM2>=<COOKIE_VALEUR2>.
      • HTTP Basic Auth : ajoutez des identifiants d’authentification basique HTTP.
      • AWS Signature V4 : entrez votre ID de clé d’accès et votre clé d’accès secrète. Datadog génère la signature de votre requête. Cette option utilise l’implémentation basique de SigV4. Les signatures spécifiques, telles qu’AWS S3, ne sont pas implémentées.
      • NTLM v1 : ajoutez vos identifiants d’authentification NTLM.
      • Body type : sélectionnez le type du corps de requête (text/plain, application/json, text/xml, text/html, application/x-www-form-urlencoded ou None) que vous voulez ajouter à votre requête HTTP.
      • Request body : ajoutez le contenu du corps de votre requête HTTP. Remarque : la taille du corps de la requête est limitée à 50 Ko.

      • Ignore server certificate error : sélectionnez cette option pour que votre test HTTP poursuive son processus de connexion même lorsque des erreurs de validation du certificat SSL surviennent.

      • Client certificate : authentifiez-vous via mTLS en important votre certificat client (.crt) et la clé privée associée (.key) au format PEM. Vous pouvez utiliser la bibliothèque openssl pour convertir vos certificats. Par exemple, vous pouvez convertir un certificat PKCS12 en certificat et clé privée au format PEM.

        openssl pkcs12 -in <CERT>.p12 -out <CERT_KEY>.key -nodes -nocerts
openssl pkcs12 -in <CERT>.p12 -out <CERT>.cert -nokeys
      • Proxy URL : indiquez l’URL du proxy que la requête HTTP doit utiliser (http://<VOTRE_UTILISATEUR>:<VOTRE_MOT_DE_PASSE>@<VOTRE_IP>:<VOTRE_PORT>).
      • Proxy Header : ajoutez les en-têtes à inclure dans la requête HTTP envoyée au proxy.
      • Do not save response body : sélectionnez cette option pour désactiver l’enregistrement du corps de la réponse au moment de l’exécution. Cela peut être utile pour s’assurer qu’aucune donnée sensible ne figure dans les résultats de test. Utilisez cette option avec précaution, car elle peut rendre plus difficile le dépannage des problèmes. Pour découvrir d’autres recommandations de sécurité, consultez Sécurité de la surveillance Synthetic.

    1. Donnez un nom à votre test HTTP.

    2. Ajoutez des tags env et tout autre tag de votre choix à votre test HTTP. Vous pourrez ensuite utiliser ces tags pour filtrer rapidement vos tests Synthetic depuis la page d’accueil de la surveillance Synthetic.

    Définir une requête HTTP

    Cliquez sur Test URL pour essayer la configuration de requête. Un aperçu de la réponse s’affiche sur le côté droit de votre écran.

    Définir des assertions

    Les assertions définissent un résultat de test escompté. Lorsque vous cliquez sur Test URL, les assertions de base pour response time, status code et header content-type sont ajoutées en fonction de la réponse obtenue. Vous devez définir au moins une assertion à surveiller pour votre test.

    TypeOpérateurType de valeur
    bodycontains, does not contain, is, is not,
    matches, does not match,
    jsonpath, xpath    		Chaîne
    Regex
    Chaîne, Regex
    headercontains, does not contain, is, is not,
    matches, does not match    		Chaîne
    Regex
    response timeis less thanNombre entier (ms)
    status codeis, is notNombre entier

    Remarque : les tests HTTP peuvent décompresser les corps de réponse contenant les en-têtes content-encoding suivants : br, deflate, gzip et identity.

    Vous pouvez créer jusqu’à 20 assertions par test API en cliquant sur New Assertion ou en sélectionnant directement l’aperçu de la réponse :

    Définir les assertions pour votre test HTTP

    Sélectionner des emplacements

    Sélectionnez les emplacements à partir desquels vous souhaitez exécuter votre test HTTP. Les tests HTTP peuvent être exécutés depuis des emplacements gérés et des emplacements privés, selon que vous souhaitez exécuter le test à l’extérieur ou à l’intérieur de votre réseau.

    Indiquer la fréquence du test

    Les tests HTTP peuvent être exécutés :

    • Selon un programme, pour vous assurer que vos utilisateurs peuvent toujours accéder à vos principaux endpoints. Sélectionnez la fréquence à laquelle vous souhaitez que Datadog exécute votre test HTTP.
    • Dans vos pipelines de CI/CD, pour déployer votre code sans crainte de dégrader l’expérience de vos utilisateurs.
    • À la demande, afin d’exécuter les tests au moment le plus opportun pour votre équipe.

    Définir des conditions d’alerte

    Définissez des conditions d’alerte afin de spécifier les circonstances dans lesquelles vous souhaitez qu’un test échoue et déclenche une alerte.

    Règle d’alerte

    Lorsque vous définissez les conditions d’alerte sur An alert is triggered if any assertion fails for X minutes from any n of N locations, une alerte se déclenche uniquement si les deux conditions suivantes se vérifient :

    • Au moins un emplacement a donné lieu à un échec (au moins une assertion a échoué) au cours des X dernières minutes
    • À un moment au cours des X dernières minutes, au moins n emplacements ont donné lieu à un échec

    Nouvelle tentative rapide

    Votre test peut déclencher X nouvelles tentatives après Y ms en cas d’échec. Cet intervalle peut être personnalisé en fonction de vos préférences en matière d’alertes.

    La disponibilité d’un emplacement est calculée pour chaque évaluation (quels que soient les résultats du dernier test avant l’évaluation). La disponibilité totale est calculée selon les conditions d’alerte configurées. Les notifications envoyées se basent sur la disponibilité totale.

    Informer votre équipe

    Votre test envoie une notification selon les conditions d’alerte définies au préalable. Référez-vous à cette section pour définir les conditions et le message à envoyer à vos équipes.

    1. Tout comme pour les monitors, sélectionnez les utilisateurs et/ou services qui doivent recevoir des notifications. Pour ce faire, ajoutez @notification au message, ou cherchez des membres d’équipe ou des intégrations connectées à l’aide de la liste déroulante.

    2. Saisissez un message de notification pour le test. Ce champ accepte le format de mise en forme Markdown standard ainsi que les variables conditionnelles suivantes :

      Variable conditionnelleDescription
      {{#is_alert}}S’affiche lorsque le test envoie une alerte.
      {{^is_alert}}S’affiche lorsque le test n’envoie pas d’alerte.
      {{#is_recovery}}S’affiche lorsque le test est rétabli depuis un état d’alerte.
      {{^is_recovery}}S’affiche lorsque le test n’est pas rétabli depuis un état d’alerte.

    3. Indiquez une fréquence de renvoi du message de notification en cas d’échec d’un test. Si vous ne souhaitez pas renvoyer de notification en cas d’échec, définissez l’option sur Never renotify if the monitor has not been resolved.

    Cliquez sur Save pour enregistrer et démarrer votre test.

    Variables

    Créer des variables locales

    Vous pouvez créer des variables locales en cliquant sur Create Local Variable en haut à droite du formulaire de configuration de votre test. Vous pouvez définir leurs valeurs sur l’un des builtins disponibles ci-dessous :

    {{ numeric(n) }}
    Génère une chaîne numérique de n chiffres.
    {{ alphabetic(n) }}
    Génère une chaîne alphabétique de n lettres.
    {{ alphanumeric(n) }}
    Génère une chaîne alphanumérique de n caractères.
    {{ date(n, format) }}
    Génère une date dans l’un des formats acceptés. Sa valeur correspond à la date d’initiation du test + n jours.
    {{ timestamp(n, unit) }}
    Génère un timestamp dans l’une des unités acceptées. Sa valeur correspond au timestamp d’initiation du test +/- n unités choisies.

    Utiliser des variables

    Les variables globales définies sur la page Settings et les variables définies localement peuvent être utilisées dans l’URL, les options avancées et les assertions de vos tests HTTP.

    Pour afficher votre liste de variables, tapez {{ dans le champ souhaité :

    Échec de test

    Un test est considéré comme FAILED s’il ne répond pas à une ou plusieurs de ses assertions ou si la requête a échoué prématurément. Dans certains cas, le test peut en effet échouer sans que les assertions n’aient pu être comparées à l’endpoint.

    Voici la liste des erreurs concernées :

    CONNRESET
    La connexion a été interrompue de façon soudaine par le serveur à distance. Causes possibles : erreur ou défaillance du serveur Web lors de la réponse ou perte de connectivité du serveur Web.
    DNS
    L’entrée DNS est introuvable pour l’URL du test. Causes possibles : URL du test mal configurée, ou configuration des entrées DNS incorrecte.
    INVALID_REQUEST
    La configuration du test n’est pas valide (par exemple, en raison d’une faute de frappe dans l’URL).
    SSL
    La connexion SSL n’a pas pu être établie. Pour en savoir plus, consultez la page relative aux erreurs.
    TIMEOUT
    La requête n’a pas pu être effectuée dans un délai raisonnable. Deux types d’erreur TIMEOUT peuvent se produire :
    • TIMEOUT: The request couldn’t be completed in a reasonable time. indique que la requête a expiré lors de la connexion au socket TCP.
    • TIMEOUT: Retrieving the response couldn’t be completed in a reasonable time. indique que la requête a expiré lors de son traitement global (qui comprend la connexion au socket TCP, le transfert de données et les assertions).
    MALFORMED_RESPONSE
    Le serveur à distance a répondu avec une charge utile non conforme aux spécifications HTTP.

    Autorisations

    Par défaut, seuls les utilisateurs disposant des rôles Admin Datadog et Standard Datadog peuvent créer, modifier et supprimer des tests HTTP Synthetic. Pour que votre utilisateur puisse effectuer ces opérations, vous devez donc lui accorder l’un de ces deux rôles par défaut.

    Si vous avez accès aux rôles personnalisés, ajoutez votre utilisateur à un rôle personnalisé disposant des autorisations synthetics_read et synthetics_write.

    Pour aller plus loin

    Documentation, liens et articles supplémentaires utiles:

    Présentation de la surveillance Synthetic DatadogBLOG more more Présentation des tests SyntheticCENTRE D'APPRENTISSAGE more more Débuter avec les tests HTTPDOCUMENTATION more more Exécuter des tests HTTP sur des endpoints internesDOCUMENTATION more more