Comment configurer l’analyse pour Azure Functions

Article
11/29/2023

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. La configuration par défaut risque d’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.

Plus loin dans cet article, vous découvrirez comment configurer et personnaliser les données que vos fonctions envoient à Application Insights. La configuration de journalisation courante peut être définie dans le fichier host.json. Par défaut, ces paramètres régissent également les journaux personnalisés émis par votre code, même si, dans certains cas, ce comportement peut être désactivé au profit d’options qui vous donnent plus de contrôle sur la journalisation. Si vous souhaitez obtenir plus d’informations, consultez Journaux des applications personnalisées.

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 spécifique. Cela vous permet de 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ées que vous écrivez sont envoyés à l’hôte Functions, qui les envoie ensuite à Application Insights via la catégorie « Worker ». Certaines piles de langues vous permettent quant à elles d’envoyer les journaux directement à Application Insights, ce qui vous donne un contrôle total sur la façon dont les journaux d’activité que vous écrivez sont émis. Le pipeline de journalisation passe de worker -> Functions host -> Application Insights à worker -> Application Insights.

Le tableau suivant récapitule les options disponibles pour chaque pile :

Pile de langages	Configuration des journaux personnalisés
.NET (modèle in-process)	`host.json`
.NET (modèle isolé)	Par défaut : `host.json` Option d’envoi direct des journaux : Configurer Application Insights dans HostBuilder
Node.JS	`host.json`
Python	`host.json`
Java	Par défaut : `host.json` Option d’envoi direct des journaux : Configurer l’agent Java Application Insights
PowerShell	`host.json`

Quand des journaux d’applications personnalisés sont envoyés 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 elles ne modifient pas le comportement des autres journaux d’exécution décrits dans cet article. Pour contrôler le comportement de tous les journaux, vous devrez peut-être apporter des modifications pour 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 d’activité générées par le runtime :

v2.x+
v1.x

Category	Table de charge de travail	Description
`Function`	traces	Inclut les journaux de démarrage et de fin de fonction pour toutes les exécutions de fonction. 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 supérieur, vous ne pouvez pas visualiser 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 supérieur, vous ne pouvez pas visualiser 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`.

Notes

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.

Category	Table de charge de travail	Description
`Function`	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 supérieur, vous ne pouvez pas visualiser ces données.
`Host.Executor`	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.
`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 supérieur, vous ne pouvez pas visualiser ces données.

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 ci-dessous 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 ces valeurs à un niveau trop élevé (en particulier à un niveau supérieur à 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 ceci dans le développement local par Debug ou Trace.

v2.x+
v1.x

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "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 :

v2.x+
v1.x

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

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "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. La définition d’un niveau de journal de catégorie sur n’importe quelle valeur différente Information empêche la télémétrie de circuler vers ces tables. En conséquence, vous ne pourrez pas voir les données associées sous l’onglet Application Insights ou Moniteur de fonction.

Dans les exemples ci-dessus :

Si la catégorie Host.Results est définie sur le niveau de journalisation Error, elle 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é, ce qui empêche d’afficher les détails des exécutions de l’hôte ayant réussi à la fois dans Application Insights et sous l’onglet Superviser de la fonction.
Si la catégorie Function est définie sur le niveau de journalisation Error, elle cesse de collecter les données de télémétrie de fonction relatives à dependencies, à customMetrics et à customEvents pour toutes les fonctions, ce qui empêche de voir ces données dans Application Insights. Elle collecte uniquement les traces journalisées avec le niveau Error.

Dans les deux cas, vous continuerez à collecter les données d’erreurs et d’exceptions dans Application Insights et sous l’onglet Superviser de la 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. Voici un 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 :

v2.x+
v1.x

{
  "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 garantira la journalisation de toutes les exécutions de fonction (requêtes) et exceptions, tandis que d’autres types de données de télémétrie restent soumis à l’échantillonnage.

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Si votre projet prend 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 en présence d’une configuration d’échantillonnage différente de la configuration d’échantillonnage 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 définissant (au minimum) ce qui suit 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é, vous pouvez ajouter 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> :

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.

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 Recommandations, elle doit se connecter à la ressource Application Recommandations à l’aide de l’un des paramètres d’application suivants :

Nom du paramètre	Description
APPLICATIONINSIGHTS_CONNECTION_STRING	Il s’agit du paramètre recommandé, qui est requis lorsque votre instance d’application Recommandations s’exécute dans un cloud souverain. Le chaîne de connexion prend en charge d’autres nouvelles fonctionnalités.
APPINSIGHTS_INSTRUMENTATIONKEY	Paramètre hérité, déconseillé par l’application Recommandations 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, qui porte le même nom que votre application de fonction est créée dans la même région ou dans la région la plus proche.

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.

Screenshot of enabling Application Insights while creating a function app.

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 le chaîne de connexion à partir de cette ressource en tant que paramètre d’application dans votre application de fonction.

Dans le Portail Azure, recherchez et sélectionnez Application de fonction, puis sélectionnez votre application de fonction.
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é.

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.

Screenshot of creating an Application Insights resource.

Sélectionnez Apply.

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.
Dans votre application de fonction, sélectionnez Configuration sous Paramètres, puis sélectionnez Paramètres d'application. Si vous voyez un paramètre 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. Si, pour une raison quelconque, ce paramètre n’existe pas, ajoutez-le à l’aide de votre application Recommandations chaîne de connexion comme valeur.

Remarque

Les applications de fonction plus anciennes peuvent utiliser APPINSIGHTS_INSTRUMENTATIONKEY au lieu de APPLICATIONINSIGHTS_CONNECTION_STRING. Dans la mesure du possible, vous devez mettre à jour votre application pour utiliser le 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 la journalisation intégrée est utilisée en production, l’enregistrement de journal peut être incomplet en raison d’une limitation du 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 qui peuvent entraîner des volumes élevés de données de télémétrie telles que des solutions IoT, des solutions rapides pilotées par les événements, des systèmes financiers à haute charge et des 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 la télémétrie générée va être consommée, vous devez définir une stratégie pour réduire le volume de données générées. Cette stratégie vous permet de superviser, d’utiliser et de diagnostiquer correctement vos applications de fonction en production. Vous pouvez envisager les options suivantes :

Utiliser l’échantillonnage : comme indiqué précédemment, cela 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. Vous pouvez maintenant choisir les catégories que vous voulez définir sur le niveau Information afin de pouvoir superviser et diagnostiquer correctement vos fonctions.
Réglez 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 qui sont essentielles pour la supervision 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. À ce stade, pour éviter de collecter des journaux générés par l’utilisateur 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 recueillies dans la table customMetrics d’Application Insights, et elles s’affichent sous l’onglet Vue d’ensemble de la fonction dans le Portail Azure. En fonction de la façon dont vous configurez l’agrégateur, pensez qu’il y aura un retard, déterminé par la valeur flushTimeout, dans la télémétrie collectée. Si vous définissez cette catégorie sur une autre valeur différente de Information, vous arrêtez la collecte des données dans la table customMetrics et les métriques ne s’affichent pas 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 :

La capture d’écran suivante montre les données de 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 Application Insights requests et affichées dans l’onglet Monitor de fonction et dans différents tableaux de bord Application Insights (performances, défaillances, etc.). Si vous définissez cette catégorie sur une autre valeur différente de Information, vous allez collecter 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 :

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 :
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 :

v2.x+
v1.x

{
  "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"
      }
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Avec cette configuration, vous disposez des éléments suivants :

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. Par conséquent, par défaut, pour toutes les fonctions, seuls les journaux des exceptions et les journaux des erreurs sont collectés (les dépendances, les métriques générées par l’utilisateur et les é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, aucune information agrégée à partir des appels de fonction n’est collectée dans la table customMetrics d’Application Insights, et aucune information sur les nombres d’exécutions (nombre total, réussies et ayant échoué) ne s’affiche 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 s’affichent dans le tableau de bord Superviser de la fonction et dans les tableaux de bord Application Insights.
Pour la fonction nommée Function1, nous avons défini 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, la catégorie Function1.User (traces générées par l’utilisateur) est définie sur Error, de sorte que seule la journalisation personnalisée des erreurs est collectée.

Remarque

La configuration par fonction n’est pas prise en charge dans la v1.x.
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, le point (.) utilisé pour indiquer la hiérarchie JSON est remplacé par un trait de soulignement double (__). Par exemple, vous pouvez utiliser les paramètres d’application ci-dessous pour configurer des niveaux de journalisation de fonctions individuels comme indiqué dans host.json ci-dessus.

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 cli
PowerShell

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"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é

La fonctionnalité Contrôle d’intégrité peut être utilisée pour superviser les applications de fonction dans le cadre des plans Premium (Élastique 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.

Étapes suivantes

Pour plus d'informations sur la surveillance, consultez :

Comment configurer l’analyse pour Azure Functions

Journaux des application personnalisés

Configurer des catégories

Configurer des niveaux de journaux

Configurer le paramètre d’agrégation

Configurer l’échantillonnage

Activer la collection de requêtes SQL

Configurer les journaux de contrôleur d’échelle

Activer l’intégration à Application Insights

Nouvelle application de fonction dans le portail

Ajouter à une application de fonction existante

Désactiver la journalisation intégrée

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

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

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

Étapes suivantes

Ressources supplémentaires