Tracer les informations d’un appel HTTP vers Application Insights depuis API Management

Introduction

 

L’API Management (ou APIM) permet de lister des APIs exposant des opérations. Ses opérations seront consommées via des requêtes HTTP.
Pour pouvoir récupérer les informations liées à la requête HTTP, l’API Management met en place plusieurs outils.
Nous allons utiliser Application Insights pour tracer les informations d’entrées et de sortie des requêtes en succès et des requêtes en erreur.

 

Mise en place de l’API dans l’API Management

 

En prérequis, un Ressource Group avec un API Management et un Application Insights doivent être créés.
Dans notre cas, nous avons créé une API “TraceAPI” dans l’API Management. Nous avons ensuite ajouté une opération POST “Post Request” dans l’API “TraceAPI”, qui fera office d’exemple.

 

 

 

Pour activer les logs dans l’Application Insights, il faut configurer l’API via la section “Settings” comme indiqué ci-dessous, dans la partie “Diagnostic Logs”.

 

 

Ajout des policies dans l’API

 

Pour analyser nos traces dans l’Application Insights, il faut ajouter les informations nécessaires dans l’API, via les “policies”. Pour que les traces soient disponibles dans l’intégralité des opérations, il est préférable de modifier les policies dans “All operations”.

 

 

Voilà ci-dessous le code à ajouter :

 

<policies>
    <inbound>
        <base />
        <set-variable name="requestBody" value="@{
            return context.Request.Body != null ? context.Request.Body.As<string>(preserveContent: true) : "";
        }" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
        <set-variable name="responseBody" value="@{
            return context.Response.Body != null ? context.Response.Body.As<string>(preserveContent: true) : "";
        }" />
        <trace source="SucceedInformation" severity="error">
            <message>SucceedInformation</message>
            <metadata name="Request.Body" value="@((context.Request.Body == null || String.IsNullOrEmpty((string)context.Variables["requestBody"])) ? "-none-" : (string)context.Variables["requestBody"])" />
            <metadata name="Response.Body" value="@((context.Response.Body == null || String.IsNullOrEmpty((string)context.Variables["responseBody"])) ? "-none-" : (string)context.Variables["responseBody"])" />
        </trace>
    </outbound>
    <on-error>
        <base />
        <set-variable name="requestBody" value="@{
            return context.Request.Body != null ? context.Request.Body.As<string>(preserveContent: true) : "";
        }" />
        <set-variable name="responseBody" value="@{
            return context.Response.Body != null ? context.Response.Body.As<string>(preserveContent: true) : "";
        }" />
        <trace source="ErrorInformation" severity="error">
            <message>ErrorInformation</message>
            <metadata name="Request.Body" value="@((context.Request.Body == null || String.IsNullOrEmpty((string)context.Variables["requestBody"])) ? "-none-" : (string)context.Variables["requestBody"])" />
            <metadata name="Response.Body" value="@((context.Response.Body == null || String.IsNullOrEmpty((string)context.Variables["responseBody"])) ? "-none-" : (string)context.Variables["responseBody"])" />
        </trace>
    </on-error>
</policies>

 

Dans cet exemple, on récupère le body en entrée et la réponse en sortie, à la fois pour les requêtes en succès et les requêtes en erreur.

 

Description du code

Pour continuer, il faut d’abord définir le body en entrée, dans une variable “requestBody” à l’intérieur de la balise “inbound”, là où la valeur est accessible. C’est le même cas pour la réponse, la variable est à créer dans la balise “outbound”.
La balise “trace” permet d’obtenir une trace dans Application Insights, il faut la définir directement dans le code. On ajoute une balise “message” pour lui donner un nom, et des balises “metadata” pour indiquer les données à logger.
Notez que ces informations ont permis d’obtenir les logs d’entrée/sortie dans l’Application Insights.
Dans le cas d’une requête en erreur, le fonctionnement est similaire, mais les paramètres doivent être définis dans la balise “on-error” comme dans l’exemple de code plus haut.

 

Analyser les traces dans Application Insights

 

Pour analyser nos traces, on se rend dans l’Application Insights connecté à notre APIM.
Dans ce chapitre, on prendra un cas de requête en erreur. Notez tout de même que l’analyse d’une requête en succès passe par le même fonctionnement.

 

Démarche à suivre

Pour commencer, il faut se rendre dans la liste des requêtes en erreur. Pour cela, cliquez sur “Failures” dans le menu gauche.

 

 

Une fois dans ce menu, et après avoir effectué un appel (en erreur) vers notre endpoint “Post Request”, nous obtenons une failed request sur le graphique à l’écran. Vous obtiendrez aussi une erreur en consommant votre endpoint de votre côté.

 

 

Cliquez sur la requête en rouge, cela va ouvrir un menu sur la droite. Cliquez à nouveau sur votre requête, mais dans ce menu.

 

 

Les détails de la requête sont maintenant visibles à l’écran, cliquez sur “View all telemetry” en bas à droite pour analyser votre trace définie dans l’APIM.

 

 

En cliquant sur la trace “ErrorInformation”, le Request Body et le Response Body sont maintenant visibles depuis la fenêtre de droite.

 

 

Conclusion

 

Nous avons donc vu le traçage d’informations d’une requête HTTP vers Application Insights depuis API Management. Cela permet de garder un suivi constant sur les appels faits vers l’APIM.

Si vous souhaitez plus d’informations liées à l’API Management, voici quelques liens :

• Policy avancées de Microsoft (incluant les traces) : https://docs.microsoft.com/en-us/azure/api-management/api-management-advanced-policies
• Autre article de blog Middleway lié à l’API Management : https://www.middleway.eu/fr/comment-migrer-le-portail-des-developpeurs-dazure-api-management-vers-une-autre-instance-apim-avec-azure-devops/