Partager via

Comment configurer l’analyse pour Azure Functions

  • Article

Azure Functions s’intègre à Application Insights pour vous permettre de mieux analyser vos applications de fonction. Application Insights, fonctionnalité d’Azure Monitor, est un service extensible de gestion des performances des applications (APM) qui collecte les données générées par votre application de fonction, notamment les informations que votre application écrit dans les journaux. L’intégration d’Application Insights est généralement activée lors de la création de votre application de fonction. Si votre application n’a pas de clé d’instrumentation définie, vous devez d’abord activer l’intégration d’Application Insights.

Vous pouvez utiliser Application Insights sans en personnaliser la configuration. Toutefois, la configuration par défaut peut engendrer d’importants volumes de données. Si vous utilisez un abonnement Azure Visual Studio, vous risquez d’atteindre votre plafond de données pour Application Insights. Pour plus d’informations sur les coûts d’Application Insights, consultez Facturation d’Application Insights. Pour plus d’informations, consultez Solutions avec un volume élevé de télémétrie.

Dans cet article, vous allez découvrir comment configurer et personnaliser les données que vos fonctions envoient à Application Insights. Vous pouvez définir des configurations de journalisation courantes dans le fichier host.json. Par défaut, ces paramètres régissent également les journaux personnalisés émis par votre code. Toutefois, dans certains cas, vous pouvez désactiver ce comportement en faveur d’options vous donnant plus de contrôle sur la journalisation. Pour plus d’informations, consultez Journaux des applications personnalisés.

Remarque

Vous pouvez utiliser des paramètres d’application spécialement configurés pour représenter des paramètres spécifiques dans un fichier host.json pour un environnement particulier. De cette façon, vous pouvez modifier efficacement les paramètres host.json sans avoir à republier le fichier host.json dans votre projet. Pour plus d’informations, consultez Substituer les valeurs de host.json.

Journaux des application personnalisés

Par défaut, les journaux des applications personnalisés que vous écrivez sont envoyés à l’hôte Functions, qui les envoie ensuite à Application Insights sous la catégorie Worker. Certaines piles de langage vous permettent d’envoyer les journaux directement à Application Insights, ce qui vous donne un contrôle total sur la façon dont les journaux que vous écrivez sont émis. Dans ce cas, le pipeline de journalisation passe de worker -> Functions host -> Application Insights à worker -> Application Insights.

Le tableau suivant résume les options de configuration disponibles pour chaque pile :

Pile de langages Où configurer des journaux personnalisés
.NET (modèle in-process) host.json
.NET (modèle isolé) Par défaut (envoyer les journaux personnalisés à l’hôte Functions) : host.json
Pour envoyer les journaux directement à Application Insights, consultez Configurer Application Insights dans HostBuilder.
Node.JS host.json
Python host.json
Java Par défaut (envoyer les journaux personnalisés à l’hôte Functions) : host.json
Pour envoyer les journaux directement à Application Insights, consultez Configurer l’agent Java Application Insights.
PowerShell host.json

Quand vous configurez des journaux d’application personnalisés pour les envoyer directement, l’hôte ne les émet plus et host.json ne contrôle plus leur comportement. De même, les options exposées par chaque pile s’appliquent uniquement aux journaux personnalisés et ne modifient pas le comportement des autres journaux d’exécution décrits dans cet article. Dans ce cas, pour contrôler le comportement de tous les journaux, vous devrez peut-être modifier les deux configurations.

Configurer des catégories

L’enregistreur d’événements d’Azure Functions inclut une catégorie par journal. La catégorie indique quelle partie du code d’exécution ou de votre code de fonction a écrit le journal. Les catégories diffèrent entre la version 1.x et les versions ultérieures.

Les noms de catégorie dans Functions ne sont pas attribués de la même façon que dans d’autres frameworks .NET. Par exemple, quand vous utilisez ILogger<T> dans ASP.NET, la catégorie est le nom du type générique. Les fonctions C# utilisent également ILogger<T>, mais au lieu de définir le nom du type générique comme catégorie, le runtime attribue des catégories en fonction de la source. Par exemple :

  • Les entrées liées à l’exécution d’une fonction se voient attribuer la catégorie Function.<FUNCTION_NAME>.
  • Les entrées créées par le code utilisateur à l’intérieur de la fonction, par exemple lors de l’appel de logger.LogInformation(), se voient attribuer la catégorie Function.<FUNCTION_NAME>.User.

Le tableau suivant décrit les principales catégories de journaux créés par le runtime :

Category Table de charge de travail Description
Function traces Inclut les journaux des fonctions démarrées et terminées pour toutes les exécutions de fonctions. Pour les exécutions ayant réussi, ces journaux d’activité sont de niveau Information. Les exceptions sont journalisées au niveau Error. Le runtime crée également des journaux de niveau Warning, par exemple lorsque des messages de la file d’attente sont envoyés à la file d’attente de messages incohérents.
Function.<YOUR_FUNCTION_NAME> dependencies Les données de dépendance sont collectées automatiquement pour certains services. Pour les exécutions ayant réussi, ces journaux d’activité sont de niveau Information. Pour plus d’informations, consultez Dépendances. Les exceptions sont journalisées au niveau Error. Le runtime crée également des journaux de niveau Warning, par exemple lorsque des messages de la file d’attente sont envoyés à la file d’attente de messages incohérents.
Function.<YOUR_FUNCTION_NAME> customMetrics
customEvents		 Les SDK C# et JavaScript vous permettent de collecter des métriques personnalisées et de journaliser des événements personnalisés. Pour plus d’informations, consultez Données de télémétrie personnalisées.
Function.<YOUR_FUNCTION_NAME> traces Inclut les journaux des fonctions démarrées et terminées pour des exécutions de fonctions spécifiques. Pour les exécutions ayant réussi, ces journaux d’activité sont de niveau Information. Les exceptions sont journalisées au niveau Error. Le runtime crée également des journaux de niveau Warning, par exemple lorsque des messages de la file d’attente sont envoyés à la file d’attente de messages incohérents.
Function.<YOUR_FUNCTION_NAME>.User traces Les journaux générés par l’utilisateur, qui peuvent être de n’importe quel niveau de journalisation. Pour plus d’informations sur l’écriture dans les journaux à partir de vos fonctions, consultez la page sur les écritures dans des journaux.
Host.Aggregator customMetrics Ces journaux d’activité générés par le runtime fournissent des nombres et des moyennes d’appels de fonction sur une période de temps configurable. La période par défaut est 30 secondes ou 1 000 résultats, selon la première de ces éventualités. Le nombre d’exécutions, le taux de réussite et la durée en sont des exemples. Tous ces journaux sont écrits au niveau Information. Si vous filtrez sur le niveau Warning ou un niveau supérieur, vous ne voyez aucune de ces données.
Host.Results requests Ces journaux générés par le runtime indiquent la réussite ou l’échec d’une fonction. Tous ces journaux sont écrits au niveau Information. Si vous filtrez sur le niveau Warning ou un niveau supérieur, vous ne voyez aucune de ces données.
Microsoft traces Catégorie de journal complète qui reflète un composant du runtime .NET appelé par l’hôte.
Worker traces Journaux générés par le processus de traitement des langages pour les langages autres que .NET. Les journaux de processus de traitement des langages peuvent également être journalisés dans une catégorie Microsoft.*, telle que Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Ces journaux sont écrits au niveau Information.

Remarque

Pour les fonctions de la bibliothèque de classes .NET, ces catégories partent du principe que vous utilisez ILogger et non ILogger<T>. Pour plus d’informations, consultez la documentation relative à Functions ILogger.

La colonne Table indique dans quelle table Application Insights le journal est écrit.

Configurer des niveaux de journaux

Un niveau de journal est affecté à chaque journal. La valeur est un entier qui indique l’importance relative :

LogLevel Code Description
Trace 0 Journaux contenant les messages les plus détaillés. Ces messages peuvent contenir des données d’application sensibles. Ils sont désactivés par défaut et ne doivent jamais être activés dans un environnement de production.
Débogage 1 Journaux utilisés pour l’investigation interactive durant le développement. Ils doivent principalement contenir des informations utiles pour le débogage et n’ont pas d’intérêt à long terme.
Information 2 Journaux utilisés pour suivre le flux général de l’application. Ils ont généralement une utilité à long terme.
Avertissement 3 Les journaux qui mettent en évidence un événement anormal ou inattendu dans le workflow de l’application, mais ne provoquent pas l’arrêt de l’exécution de l’application.
Error 4 Les journaux qui surveillent le moment où le flux actuel de l’exécution est arrêté en raison d’un échec. Ces erreurs doivent indiquer un échec dans l’activité en cours, et non un échec sur l’ensemble de l’application.
Critique 5 Journaux qui décrivent un plantage irrécupérable de l’application ou du système, ou une défaillance catastrophique nécessitant une attention immédiate.
None 6 Désactive la journalisation pour la catégorie spécifiée.

La configuration du fichier host.json détermine la quantité de journalisation qu’une application de fonction envoie à Application Insights.

Pour chaque catégorie, vous indiquez le niveau de journal minimal à envoyer. Les paramètres host.json varient en fonction de la version du runtime Functions.

Les exemples suivants définissent la journalisation en fonction des règles suivantes :

  • Le niveau de journalisation par défaut est défini sur Warning pour éviter une journalisation excessive pour les catégories non anticipées.
  • Host.Aggregator et Host.Results sont définis sur des niveaux inférieurs. La définition de niveaux de journalisation trop élevés, en particulier des niveaux supérieurs à Information, peut entraîner la perte de métriques et de données de performances.
  • La journalisation des exécutions de fonction est définie sur Information. Si nécessaire, vous pouvez remplacer ce paramètre dans le développement local par Debug ou Trace.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

Si host.json inclut plusieurs journaux qui commencent par la même chaîne, les journaux les plus définis sont traités en priorité. Prenons l’exemple suivant qui journalise tout dans le runtime, à l’exception de Host.Aggregator, au niveau de Error :

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

Vous pouvez utiliser un paramètre de niveau de journalisation None pour empêcher l’écriture de journaux pour une catégorie.

Attention

Azure Functions s’intègre à Application Insights en stockant les événements de télémétrie dans les tables Application Insights. Si vous définissez un niveau de journalisation de catégorie sur une valeur différente de Information, les données de télémétrie ne peuvent pas être acheminées vers ces tables, ce qui vous empêche de voir les données associées sous les onglets Application Insights et Moniteur de fonction.

Par exemple, pour les exemples précédents :

  • Si vous définissez la catégorie Host.Results sur le niveau de journalisation Error, Azure collecte uniquement les événements de télémétrie d’exécution de l’hôte dans la table requests pour les exécutions de fonctions ayant échoué, empêchant ainsi l’affichage des détails des exécutions de l’hôte ayant réussi sous les onglets Application Insights et Moniteur de fonction.
  • Si vous définissez la catégorie Function sur le niveau de journalisation Error, elle cesse de collecter les données de télémétrie des fonctions liées à dependencies, customMetrics et customEvents pour toutes les fonctions, ce qui vous empêche de voir ces données dans Application Insights. Azure rassemble uniquement les traces journalisés au niveau Error.

Dans les deux cas, Azure continue de collecter les données des erreurs et des exceptions sous les onglets Application Insights et Moniteur de fonction. Pour plus d’informations, consultez Solutions avec un volume élevé de télémétrie.

Configurer le paramètre d’agrégation

Comme indiqué dans la section précédente, le runtime agrège les données sur les exécutions de fonction sur une période de temps. La période par défaut est 30 secondes ou 1 000 exécutions, selon la première de ces éventualités. Vous pouvez configurer ce paramètre dans le fichier host.json. Par exemple :

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Configurer l’échantillonnage

Application Insights présente une fonctionnalité d’échantillonnage qui peut vous éviter de produire une quantité excessive de données de télémétrie portant sur les exécutions terminées aux heures de forte activité. Lorsque le taux d'exécutions entrantes dépasse un seuil spécifié, Application Insights commence à ignorer de manière aléatoire certaines exécutions entrantes. Par défaut, le nombre maximal d’exécutions par seconde est fixé à 20 (cinq dans la version 1.x). Vous pouvez configurer l’échantillonnage dans host.json. Voici un exemple :

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Vous pouvez exclure certains types de données de télémétrie de l’échantillonnage. Dans cet exemple, les données de type Request et Exception sont exclues de l’échantillonnage. Cela garantit que toutes les exécutions de fonction (requêtes) et les exceptions sont journalisées, les autres types de données de télémétrie restant soumis à l’échantillonnage.

Si votre projet utilise une dépendance sur le kit de développement logiciel (SDK) Application Insights pour effectuer un suivi télémétrique manuel, vous constaterez peut-être un comportement inhabituel si votre configuration d’échantillonnage diffère de celle dans votre application de fonction. Dans ce cas, utilisez la même configuration d’échantillonnage que l’application de fonction. Pour plus d’informations, consultez l’article Échantillonnage dans Application Insights.

Activer la collection de requêtes SQL

Application Insights collecte automatiquement des données sur les dépendances pour les requêtes HTTP, les appels de base de données et pour plusieurs liaisons. Pour plus d’informations, consultez Dépendances. Pour les appels SQL, le nom du serveur et de la base de données est toujours collecté et stocké, mais le texte de requête SQL n’est pas collecté par défaut. Vous pouvez utiliser dependencyTrackingOptions.enableSqlCommandTextInstrumentation pour activer la journalisation du texte des requêtes SQL en utilisant les paramètres suivants (au minimum) dans votre fichier host.json :

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Pour plus d’informations, consultez Suivi SQL avancé pour obtenir une requête SQL complète.

Configurer les journaux de contrôleur d’échelle

Cette fonctionnalité est en préversion.

Vous pouvez faire en sorte que le contrôleur d’échelle Azure Functions émette des journaux vers Application Insights ou vers le stockage Blob pour mieux comprendre les décisions prises par ce contrôleur pour votre application de fonction.

Pour activer cette fonctionnalité, ajoutez un paramètre d’application nommé SCALE_CONTROLLER_LOGGING_ENABLED à vos paramètres d’application de fonction. La valeur suivante du paramètre doit être au format <DESTINATION>:<VERBOSITY>. Pour plus d’informations, voir le tableau suivant :

Propriété Description
<DESTINATION> Destination à laquelle les journaux sont envoyés. Les valeurs valides sont AppInsights et Blob.
Quand vous utilisez AppInsights, assurez-vous qu’Application Insights est activé dans votre application de fonction.
Quand vous affectez Blob comme destination, les journaux sont créés dans un conteneur d’objets blob nommé azure-functions-scale-controller dans le compte de stockage par défaut défini dans le paramètre d’application AzureWebJobsStorage.
<VERBOSITY> Spécifie le niveau de journalisation. Les valeurs prises en charge sont None, Warning et Verbose.
Quand il est défini sur Verbose, le contrôleur de mise à l’échelle enregistre une raison pour chaque modification du nombre de Workers, et des informations sur les déclencheurs pris en compte dans ces décisions. Les journaux détaillés incluent les avertissements de déclencheur et les hachages utilisés par les déclencheurs avant et après l’exécution du contrôleur de mise à l’échelle.

Conseil

Gardez à l’esprit que, lorsque vous laissez l’option de journalisation du contrôleur de mise à l’échelle activée, cela a un impact sur les coûts potentiels de surveillance de votre application de fonction. Envisagez d’activer la journalisation jusqu’à ce que vous ayez collecté suffisamment de données pour comprendre le comportement du contrôleur de mise à l’échelle, puis de la désactiver.

Par exemple, la commande Azure CLI suivante active la journalisation détaillée à partir du contrôleur de mise à l’échelle pour Application Insights :

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

Dans cet exemple, remplacez <FUNCTION_APP_NAME> et <RESOURCE_GROUP_NAME> par le nom de votre application de fonction et le nom du groupe de ressources, respectivement.

La commande Azure CLI suivante désactive la journalisation en définissant le niveau de détail sur None :

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

Vous pouvez également désactiver la journalisation en supprimant le paramètre SCALE_CONTROLLER_LOGGING_ENABLED à l’aide de la commande Azure CLI suivante :

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Une fois la journalisation du contrôleur d’échelle activée, vous pouvez interroger vos journaux de contrôleur d’échelle.

Activer l’intégration à Application Insights

Pour qu’une application de fonction envoie des données à Application Insights, elle doit se connecter à la ressource Application Insights à l’aide d’un seul de ces paramètres d’application :

Nom du paramètre Description
APPLICATIONINSIGHTS_CONNECTION_STRING Ce paramètre est recommandé et obligatoire lorsque votre instance Application Insights s’exécute dans un cloud souverain. La chaîne de connexion prend en charge d’autres nouvelles fonctionnalités.
APPINSIGHTS_INSTRUMENTATIONKEY Paramètre hérité, déconseillé par Application Insights en faveur du paramètre de chaîne de connexion.

Lorsque vous créez votre application de fonction dans le Portail Azure, à partir de la ligne de commande avec Azure Functions Core Tools, ou Visual Studio Code, l’intégration d’Application Insights est activée par défaut. La ressource Application Insights porte le même nom que votre application de fonction et est créée dans la même région ou la région la plus proche.

Exiger l’authentification Microsoft Entra

Vous pouvez utiliser le paramètre APPLICATIONINSIGHTS_AUTHENTICATION_STRING pour activer les connexions à Application Insights à l’aide de l’authentification Microsoft Entra. Cela crée une expérience d’authentification cohérente dans tous les pipelines Application Insights, notamment Profiler et Débogueur de capture instantanée, ainsi qu’à partir de l’hôte Functions et des agents spécifiques à une langue.

Remarque

Il n’existe aucune prise en charge de l’authentification Entra pour le développement local.

La valeur contient Authorization=AAD pour une identité managée affectée par le système ou ClientId=<YOUR_CLIENT_ID>;Authorization=AAD pour une identité managée affectée par l’utilisateur. L’identité managée doit déjà être disponible pour l’application de fonction avec un rôle affecté équivalent à Éditeur d’indicateurs de performance d’analyse. Pour plus d’informations, consultez Authentification Microsoft Entra pour Application Insights.

Le paramètre APPLICATIONINSIGHTS_CONNECTION_STRING est encore obligatoire.

Remarque

Lorsque vous utilisez APPLICATIONINSIGHTS_AUTHENTICATION_STRING pour vous connecter à Application Insights au moyen de l’authentification Microsoft Entra, vous devez également désactiver l’authentification locale pour Application Insights. Cette configuration nécessite une authentification Microsoft Entra pour une ingestion de la télémétrie dans votre espace de travail.

Nouvelle application de fonction dans le portail

Pour examiner la ressource Application Insights en cours de création, sélectionnez-la de manière à développer la fenêtre Application Insights. Vous pouvez modifier le Nouveau nom de ressource ou sélectionner un autre Emplacement dans une Zone géographique Azure où vous souhaitez stocker vos données.

Capture d’écran montrant comment activer Application Insights lors de la création d’une application de fonction.

Lorsque vous sélectionnez Créer, une ressource Application Insights est créée avec votre application de fonction, et APPLICATIONINSIGHTS_CONNECTION_STRING est défini dans les paramètres de l’application. Tout est prêt.

Ajouter à une application de fonction existante

Si une ressource Application Insights n’a pas été créée avec votre application de fonction, procédez comme suit pour créer la ressource. Vous pouvez ensuite ajouter la chaîne de connexion de cette ressource en tant que paramètre d’application dans votre application de fonction.

  1. Dans le Portail Azure, recherchez et sélectionnez Application de fonction, puis sélectionnez votre application de fonction.

  2. Sélectionnez la bannière Application Insights n'est pas configuré en haut de la fenêtre. Si vous ne voyez pas cette bannière, cela signifie que votre application a probablement déjà Application Insights activé.

    Capture d’écran montrant comment activer Application Insights à partir du portail.

  3. Développez Changer votre ressource et créez une ressource Application Insights en utilisant les paramètres spécifiés dans le tableau suivant :

    Paramètre Valeur suggérée Description
    Nouveau nom de la ressource Nom d’application unique Il est plus facile d’utiliser le même nom que celui de votre application de fonction, qui doit être unique dans votre abonnement.
    Lieu Europe Ouest Si possible, utilisez la même région que celle de votre application de fonction ou une région proche.

    Capture d’écran montrant comment créer une ressource Application Insights.

  4. Sélectionnez Appliquer.

    La ressource Application Insights est créée dans le même groupe de ressources et le même abonnement que votre application de fonction. Une fois la ressource créée, fermez la fenêtre Application Insights.

  5. Dans votre application de fonction, développez Paramètres, puis sélectionnez Variables d’environnement. Sous l’onglet Paramètres de l’application, si vous voyez un paramètre d’application nommé APPLICATIONINSIGHTS_CONNECTION_STRING, cela signifie que l’intégration d’Application Insights est activée pour votre application de fonction s’exécutant dans Azure. S ce paramètre n’existe pas, ajoutez-le en utilisant votre chaîne de connexion Application Insights comme valeur.

Remarque

Les applications de fonction plus anciennes peuvent utiliser APPINSIGHTS_INSTRUMENTATIONKEY à la place de APPLICATIONINSIGHTS_CONNECTION_STRING. Si possible, mettez à jour votre application pour utiliser la chaîne de connexion au lieu de la clé d’instrumentation.

Désactiver la journalisation intégrée

Les premières versions de Functions utilisaient la surveillance intégrée, ce qui n’est plus recommandé. Lorsque vous activez Application Insights, désactivez la journalisation intégrée qui utilise le Stockage Azure. La journalisation intégrée permet de tester des charges de travail légères, mais n'a pas vocation à être utilisée en production avec des charges importantes. Nous recommandons Application Insights à des fins de surveillance de la production. Si vous utilisez la journalisation intégrée en production, l’enregistrement de journalisation peut être incomplet en raison d’une limitation sur Stockage Azure.

Pour désactiver la journalisation intégrée, supprimez le paramètre d’application AzureWebJobsDashboard. Pour plus d’informations sur la suppression de paramètres d’application dans le Portail Azure, consultez la section Paramètres de l’application dans Comment gérer une application de fonction dans le Portail Azure. Avant de supprimer le paramètre d’application, assurez-vous qu’aucune fonction existante dans la même application de fonction ne l’utilise pour les déclencheurs ou les liaisons du Stockage Azure.

Solutions avec un volume élevé de télémétrie

Les applications de fonction constituent une partie essentielle des solutions pouvant engendrer des volumes élevés de données de télémétrie. Citons par exemple les solutions IoT, les solutions rapides pilotées par les événements, les systèmes financiers à haute charge et les systèmes d’intégration. Dans ce cas, vous devez envisager une configuration supplémentaire pour réduire les coûts tout en conservant l’observabilité.

Les données de télémétrie générées peuvent être consommées dans des tableaux de bord en temps réel, des alertes, des diagnostics détaillés, et ainsi de suite. En fonction de la manière dont les données de télémétrie générées sont consommées, vous devez définir une stratégie pour réduire le volume des données générées. Cette stratégie vous permet de monitorer, d’exploiter et de diagnostiquer correctement vos applications de fonction en production. Considérez les options suivantes :

  • Utiliser l’échantillonnage : comme indiqué précédemment, l’échantillonnage permet de réduire considérablement le volume d’événements de télémétrie ingérés tout en conservant une analyse statistiquement correcte. Il peut arriver que, même en utilisant l’échantillonnage, vous obteniez quand même un volume élevé de télémétrie. Inspectez les options que vous fournit l’échantillonnage adaptatif. Par exemple, définissez maxTelemetryItemsPerSecond sur une valeur qui équilibre le volume généré avec vos besoins de supervision. Gardez à l’esprit que l’échantillonnage de télémétrie est appliqué par hôte exécutant votre application de fonction.

  • Niveau de journalisation par défaut : utilisez Warning ou Error comme valeur par défaut pour toutes les catégories de télémétrie. Plus tard, vous pourrez choisir les catégories à définir au niveau Information pour monitorer et diagnostiquer correctement vos fonctions.

  • Régler la télémétrie de vos fonctions : si le niveau de journalisation par défaut est défini sur Error ou Warning, aucune information détaillée de chaque fonction n’est collectée (dépendances, métriques personnalisées, événements personnalisés et traces). Pour les fonctions essentielles au monitoring de la production, définissez une entrée explicite pour la catégorie Function.<YOUR_FUNCTION_NAME> et affectez-lui la valeur Information afin de pouvoir collecter des informations détaillées. Pour éviter de collecter les journaux générés par les utilisateurs au niveau Information, définissez la catégorie Function.<YOUR_FUNCTION_NAME>.User sur le niveau de journalisation Error ou Warning.

  • Catégorie Host.Aggregator : comme décrit dans la section Configurer des catégories, cette catégorie fournit des informations agrégées sur les appels de fonction. Les informations de cette catégorie sont collectées dans la table customMetrics d’Application Insights et sont affichées sous l’onglet Vue d’ensemble de la fonction dans le Portail Azure. Selon le mode de configuration de l’agrégateur, considérez qu’il peut y avoir un retard, déterminé par le paramètre flushTimeout, dans la télémétrie collectée. Si vous définissez cette catégorie sur une valeur différente de Information, la collecte des données dans la table customMetrics est arrêtée et les métriques ne sont pas affichées sous l’onglet Vue d’ensemble de la fonction.

    La capture d’écran suivante montre les données de télémétrie Host.Aggregator affichées sous l’onglet Vue d’ensemble de la fonction :

    Capture d’écran montrant la télémétrie Host.Aggregator affichée sous l’onglet Vue d’ensemble de la fonction.

    La capture d’écran suivante montre les données de télémétrie Host.Aggregator dans la table customMetrics d’Application Insights :

    Capture d’écran montrant la télémétrie Host.Aggregator dans la table customMetrics d’Application Insights.

  • Catégorie Host.Results : comme décrit dans Configurer des catégories, cette catégorie fournit les journaux générés par le runtime qui indiquent la réussite ou l’échec d’un appel de fonction. Les informations de cette catégorie sont collectées dans la table requests d’Application Insights et affichées sous l’onglet Moniteur de la fonction et dans différents tableaux de bord Application Insights (Performances, Défaillances, etc.). Si vous définissez cette catégorie sur une valeur différente de Information, vous collectez uniquement les données de télémétrie générées au niveau du journal défini (ou supérieur). Par exemple, le fait de le définir sur error génère des données de suivi des demandes uniquement pour les exécutions ayant échoué.

    La capture d’écran suivante montre les données de télémétrie Host.Results affichées sous l’onglet Moniteur de la fonction :

    Capture d’écran montrant la télémétrie Host.Results sous l’onglet Moniteur de la fonction.

    La capture d’écran suivante montre les données de télémétrie Host.Results affichées dans le tableau de bord Performances d’Application Insights :

    Capture d’écran montrant la télémétrie Host.Results dans le tableau de bord Performances d’Application Insights.

  • Host.Aggregator et Host.Results : les deux catégories fournissent de bons insights sur les exécutions de fonction. Si nécessaire, vous pouvez supprimer les informations détaillées de l’une de ces catégories, afin de pouvoir utiliser l’autre pour la supervision et les alertes. Voici un exemple :

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
}

Avec cette configuration :

  • La valeur par défaut pour toutes les catégories de fonctions et de télémétrie est définie sur Warning (dont les catégories Microsoft et Worker). Ainsi, par défaut, toutes les erreurs et avertissements générés par le runtime et la journalisation personnalisée sont collectés.

  • Le niveau de journalisation de la catégorie Function est défini sur Error. Ainsi, pour toutes les fonctions, seuls les exceptions et les journaux d’erreurs sont collectés par défaut. Les dépendances, métriques générées par l’utilisateur et événements générés par l’utilisateur sont ignorés.

  • Pour la catégorie Host.Aggregator, étant donné qu’elle est définie sur le niveau de journalisation Error, les informations agrégées provenant des appels de fonction ne sont pas collectées dans la table customMetrics d’Application Insights, et les informations sur le nombre d’exécutions (total, réussies et ayant échoué) ne sont pas affichées dans le tableau de bord Vue d’ensemble de la fonction.

  • Pour la catégorie Host.Results, toutes les informations d’exécution de l’hôte sont collectées dans la table requests d’Application Insights. Tous les résultats des appels sont affichés dans le tableau de bord Moniteur de la fonction et dans les tableaux de bord Application Insights.

  • Pour la fonction appelée Function1, nous définissons le niveau de journalisation sur Information. Pour cette fonction concrète, toute la télémétrie soit collectée (dépendance, métriques personnalisées, événements personnalisés). Pour la même fonction, nous définissons la catégorie Function1.User (traces générées par l’utilisateur) sur Error, de sorte que seule la journalisation des erreurs personnalisée est collectée.

    Remarque

    La configuration par fonction n’est pas prise en charge dans la version 1.x du runtime Functions.

  • L’échantillonnage est configuré pour envoyer un élément de télémétrie par seconde et par type, en excluant les exceptions. Cet échantillonnage se produit pour chaque hôte de serveur exécutant notre application de fonction. Par conséquent, si nous avons quatre instances, cette configuration émet quatre éléments de télémétrie par seconde et par type et toutes les exceptions qui peuvent se produire.

    Remarque

    Les données de mesure telles que le taux de demandes et le taux d’exceptions sont ajustées pour compenser le taux d’échantillonnage, afin qu’elles affichent des valeurs approximativement correctes dans Metrics Explorer.

Conseil

Faites des essais avec des configurations différentes pour vérifier que vous respectez vos exigences concernant la journalisation, la supervision et les alertes. Vérifiez également que vous disposez de diagnostics détaillés en cas d’erreurs inattendues ou de dysfonctionnements.

Remplacement de la configuration de la supervision au moment de l’exécution

Enfin, il peut arriver que vous deviez modifier rapidement le comportement de journalisation d’une certaine catégorie en production et que vous ne vouliez pas effectuer un déploiement complet uniquement pour un changement apporté au fichier host.json. Dans ce cas, vous pouvez remplacer les valeurs host.json.

Pour configurer ces valeurs au niveau des paramètres de l’application (et éviter le redéploiement uniquement sur les changements apportés à host.json), vous devez remplacer des valeurs host.json spécifiques en créant une valeur équivalente comme paramètre d’application. Quand le runtime trouve un paramètre d’application au format AzureFunctionsJobHost__path__to__setting, il remplace le paramètre host.json équivalent situé sur path.to.setting dans le fichier code JSON. Quand il est exprimé sous la forme d’un paramètre d’application, un double trait de soulignement (__) remplace le point (.) utilisé pour indiquer la hiérarchie JSON. Par exemple, vous pouvez utiliser les paramètres d’application suivants pour configurer des niveaux de journalisation de fonctions individuels dans host.json.

Chemin de host.json Paramètre d’application
logging.logLevel.default AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator AzureFunctionsJobHost__logging__logLevel__Host.Aggregator
logging.logLevel.Function AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1 AzureFunctionsJobHost__logging__logLevel__Function.Function1
logging.logLevel.Function.Function1.User AzureFunctionsJobHost__logging__logLevel__Function.Function1.User

Vous pouvez remplacer les paramètres directement dans le panneau Configuration de l’application de fonction du Portail Azure ou à l’aide d’un script Azure CLI ou PowerShell.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"

Notes

Si vous remplacez host.json en changeant les paramètres de l’application, votre application de fonction redémarre. Les paramètres d’application qui contiennent une période ne sont pas pris en charge lorsqu’ils sont exécutés sur Linux dans un plan Elastic Premium ou un plan dédié (App Service). Dans ces environnements d’hébergement, vous devez continuer à utiliser le fichier host.json.

Superviser les applications de fonction en utilisant le contrôle d’intégrité

Vous pouvez utiliser la fonctionnalité Contrôle d’intégrité pour monitorer les applications de fonction dans le cadre des plans Premium (Elastic Premium) et Dédié (App Service). Le contrôle d’intégrité n’est pas une option pour le plan Consommation. Pour savoir comment le configurer, consultez Superviser des instances App Service à l’aide du contrôle d’intégrité. Votre application de fonction doit avoir une fonction de déclencheur HTTP qui répond avec un code d’état HTTP de 200 sur le même point de terminaison que celui configuré sur le paramètre Path du contrôle d’intégrité. Vous pouvez également faire en sorte que cette fonction effectue des vérifications supplémentaires pour vous assurer que les services dépendants sont accessibles et fonctionnent.

Contenu connexe

Pour plus d'informations sur la surveillance, consultez :