Monitoring de Azure OpenAI Service
Lorsque vous avez des applications critiques et des processus métier basés sur des ressources Azure, vous voulez superviser ces ressources pour connaître leur disponibilité, leurs performances et leur fonctionnement.
Cet article décrit les données de monitoring générées par Azure OpenAI Service. Azure OpenAI fait partie de Azure AI services, lequel utilise Azure Monitor. Si vous n’êtes pas familiarisé avec les fonctionnalités d’Azure Monitor qui sont communes à tous les services Azure qui utilisent le service, consultez Analyse des ressources Azure avec Azure Monitor.
Tableaux de bord
Azure OpenAI fournit des tableaux de bord prêts à l’emploi pour chacune de vos ressources Azure OpenAI. Pour accéder aux tableaux de bord de surveillance, connectez-vous à https://portal.azure.com et sélectionnez le volet de vue d’ensemble de l’une de vos ressources Azure OpenAI.
Les tableaux de bord sont regroupés en quatre catégories : requêtes HTTP, utilisation basée sur les jetons, utilisation PTU et réglage précis
Collecte et routage des données dans Azure Monitor
Azure OpenAI collecte les mêmes types de données d’analyse que les autres ressources Azure. Vous pouvez configurer Azure Monitor pour générer des données dans les journaux d’activité, les journaux de ressources, les journaux d’activité des machines virtuelles et les métriques de plateforme. Pour plus d’informations, consultez Analyse des données à partir des ressources Azure.
Les mesures de plateforme et le journal d’activité Azure Monitor sont collectés et stockés automatiquement. Ces données peuvent être acheminées vers d'autres emplacements à l'aide d'un paramètre de diagnostic. Les journaux de ressources Azure Monitor ne sont pas collectés ni stockés tant que vous n’avez pas créé un paramètre de diagnostic et que ensuite vous ne acheminez pas les journaux vers un ou plusieurs emplacements.
Lorsque vous créez un paramètre de diagnostic, vous spécifiez les catégories de journaux à collecter. Pour plus d’informations sur la création d’un paramètre de diagnostic en utilisant le portail Azure, Azure CLI ou PowerShell, consultez Créer un paramètre de diagnostic pour collecter des journaux et métriques de plateforme dans Azure.
N’oubliez pas que l’utilisation des paramètres de diagnostic et l’envoi de données aux journaux Azure Monitor entraînent d’autres coûts. Pour plus d’informations, consultez Calculs et options des coûts des journaux Azure Monitor.
Les métriques et les journaux que vous pouvez collecter sont décrits dans les sections suivantes.
Analyser les métriques
Vous pouvez analyser les métriques de vos ressources Azure OpenAI Service avec les outils Azure Monitor dans le portail Azure. Dans la page Vue d’ensemble de votre ressource Azure OpenAI, sélectionnez Métriques sous Supervision dans le volet gauche. Pour en savoir plus, consultez Prise en main de Azure Monitor Metrics Explorer.
Azure OpenAI a des points communs avec un sous-ensemble de Azure AI services. Pour obtenir la liste de toutes les métriques de plateforme collectées pour Azure OpenAI et des services Azure AI similaires par Azure Monitor, consultez les métriques prises en charge par Microsoft.CognitiveServices/accounts.
Métriques Cognitive Services
Il s’agit de métriques héritées communes à toutes les ressources Azure AI Services. Nous vous déconseillons d’utiliser ces métriques avec Azure OpenAI.
Métriques Azure OpenAI
Remarque
La métrique d’utilisation gérée par l’approvisionnement est désormais déconseillée et n’est plus recommandée. Cette métrique a été remplacée par la métrique d’utilisation managée provisionnée V2.
Le tableau suivant récapitule le sous-ensemble actuel de métriques disponibles dans Azure OpenAI.
Métrique | Catégorie | Agrégation | Description | Dimensions |
---|---|---|---|---|
Azure OpenAI Requests |
HTTP | Count | Nombre total d’appels effectués à l’API Azure OpenAI sur une période donnée. S’applique à PayGo, PTU et aux références SKU gérées par PTU. | ApiName , ModelDeploymentName ,ModelName ,ModelVersion , OperationName , Region , StatusCode , StreamType |
Active Tokens |
Utilisation | Somme | Nombre total de jetons moins les jetons mis en cache sur une période donnée. S’applique aux PTU et aux déploiements gérés par PTU. Utilisez cette métrique pour comprendre votre utilisation basée sur TPS ou TPM pour les PTU et la comparer à vos benchmarks pour le TPM ou TPS cible pour vos scénarios. | ModelDeploymentName ,ModelName ,ModelVersion |
Generated Completion Tokens |
Utilisation | Somme | Nombre de jetons générés (sortie) à partir d’un modèle Azure OpenAI. S’applique à PayGo, PTU et aux références SKU gérées par PTU | ApiName , ModelDeploymentName ,ModelName , Region |
Processed FineTuned Training Hours |
Utilisation | Somme | Nombre d’heures d’entraînement traitées sur un modèle azure OpenAI affiné. | ApiName , ModelDeploymentName ,ModelName , Region |
Processed Inference Tokens |
Utilisation | Somme | Nombre de jetons d’inférence traités par un modèle Azure OpenAI. Calculé en tant que jetons d’invite (entrée) + jetons générés. S’applique à PayGo, PTU et aux références SKU gérées par PTU. | ApiName , ModelDeploymentName ,ModelName , Region |
Processed Prompt Tokens |
Utilisation | Somme | Nombre total de jetons de prompt (entrée) traités sur un modèle Azure OpenAI. S’applique à PayGo, PTU et aux références SKU gérées par PTU. | ApiName , ModelDeploymentName ,ModelName , Region |
Provision-managed Utilization V2 |
HTTP | Moyenne | L’utilisation gérée par l’approvisionnement est le pourcentage d’utilisation d’un déploiement géré approvisionné donné. Calculé en tant que (PTU consommés/PTU déployés)*100. Lorsque l’utilisation est égale ou supérieure à 100 %, les appels sont limités et retournent un code d’erreur 429. | ModelDeploymentName ,ModelName ,ModelVersion , Region , StreamType |
Prompt Token Cache Match Rate |
HTTP | Moyenne | Géré-provisionné uniquement. La ration d’accès au cache de jetons d’invite exprimée en pourcentage. | ModelDeploymentName , ModelVersion , ModelName , Region |
Time to Response |
HTTP | Moyenne | Mesure de latence recommandée (réactivité) pour les requêtes de diffusion en continu. S’applique aux PTU et aux déploiements gérés par PTU. Cette métrique ne s’applique pas aux déploiements de paiement standard. Calculé comme temps nécessaire pour que la première réponse apparaisse après qu’un utilisateur envoie une invite, comme mesuré par la passerelle API. Ce nombre augmente à mesure que la taille de l’invite augmente et/ou que la taille du cache atteinte diminue. Remarque : cette métrique est une approximation, car la latence mesurée dépend fortement de plusieurs facteurs, notamment les appels simultanés et le modèle de charge de travail global. En outre, elle ne tient pas compte d’une latence côté client qui peut exister entre votre client et le point de terminaison de l’API. Reportez-vous à votre propre journalisation pour un suivi de latence optimal. | ModelDepIoymentName , ModelName et ModelVersion |
Configurer les paramètres de diagnostic
Toutes les métriques sont exportables avec les paramètres de diagnostic dans Azure Monitor. Pour analyser des journaux et des données de métriques avec des requêtes Log Analytics Azure Monitor, vous devez configurer les paramètres de diagnostic pour votre ressource Azure OpenAI et votre espace de travail Log Analytics.
Dans la page de votre ressource Azure OpenAI, sous Supervision, sélectionnez Paramètres de diagnostic dans le volet gauche. Dans la page Paramètres de diagnostic, sélectionnez Ajouter un paramètre de diagnostic.
Dans la page Paramètres de diagnostic, configurez les champs suivants :
- Sélectionnez Envoyer à l’espace de travail Log Analytics.
- Choisissez l’abonnement de votre compte Azure.
- Choisissez votre espace de travail Log Analytics.
- Sous Journaux, sélectionnez Tous les journaux.
- Sous Métriques, sélectionnez AllMetrics.
Entrez un nom de paramètre de diagnostic pour enregistrer la configuration.
Cliquez sur Enregistrer.
Après avoir configuré les paramètres de diagnostic, vous pouvez utiliser des métriques et des données de journal pour votre ressource Azure OpenAI dans votre espace de travail Log Analytics.
Analyser les journaux d’activité
Les données des journaux Azure Monitor sont stockées dans des tables, chacune ayant son propre ensemble de propriétés uniques.
Tous les journaux de ressources dans Azure Monitor ont les mêmes champs suivis de champs spécifiques au service. Pour plus d’informations sur le schéma commun, consultez Schémas communs et spécifiques au service pour les journaux de ressources Azure.
Le journal d’activité est un type de journal de plateforme dans Azure qui fournit des aperçus de tous les événements de niveau abonnement. Vous pouvez afficher ce journal indépendamment ou l’acheminer vers des journaux Azure Monitor. Dans le portail Azure, vous pouvez utiliser le journal d’activité dans les journaux Azure Monitor pour exécuter des requêtes complexes avec Log Analytics.
Pour une liste des types de journaux de ressources disponibles pour Azure OpenAI et d’autres services Azure AI, consultez les opérations de fournisseur de ressources Azure Microsoft.CognitiveServices.
Utiliser des requêtes Kusto
Après avoir déployé un modèle Azure OpenAI, vous pouvez envoyer des appels d’achèvement à l’aide de l’environnement de terrain de jeu dans Azure AI Studio.
Tout texte que vous entrez dans le terrain de jeu d’achèvements ou le terrain de jeu d’achèvements de conversation génère des métriques et des données de journal pour votre ressource Azure OpenAI. Dans l’espace de travail Log Analytics de votre ressource, vous pouvez interroger les données de surveillance à l’aide du langage de requête Kusto .
Important
L’option Ouvrir la requête de la page de ressources Azure OpenAI accède à Azure Resource Graph, ce qui n’est pas décrit dans cet article. Les requêtes suivantes utilisent l’environnement de requête pour Log Analytics. Veillez à suivre les étapes décrites dans Configurer les paramètres de diagnostic pour préparer votre espace de travail Log Analytics.
Dans la page de votre ressource Azure OpenAI, sous Supervision dans le volet gauche, sélectionnez Journaux.
Sélectionnez l’espace de travail Log Analytics que vous avez configuré avec diagnostics pour votre ressource Azure OpenAI.
Dans la page de l’espace de travail Log Analytics, sous Vue d’ensemble dans le volet gauche, sélectionnez Journaux.
Le portail Azure affiche une fenêtre Requêtes avec des exemples de requêtes et des suggestions par défaut. Vous pouvez fermer cette fenêtre.
Pour les exemples suivants, entrez la requête Kusto dans la région d’édition en haut de la fenêtre Requête, puis sélectionnez Exécuter. Les résultats de la requête s’affichent sous le texte de la requête.
La requête Kusto suivante est utile pour une analyse initiale des données Diagnostics Azure (AzureDiagnostics
) relatives à votre ressource :
AzureDiagnostics
| take 100
| project TimeGenerated, _ResourceId, Category, OperationName, DurationMs, ResultSignature, properties_s
Cette requête retourne un exemple de 100 entrées et affiche un sous-ensemble des colonnes de données disponibles dans les journaux. Dans les résultats de la requête, vous pouvez sélectionner la flèche en regard du nom de la table pour afficher toutes les colonnes disponibles et les types de données associés.
Pour afficher toutes les colonnes de données disponibles, vous pouvez supprimer la ligne | project ...
de paramètres d’étendue de la requête :
AzureDiagnostics
| take 100
Pour examiner les données de métriques Azure (AzureMetrics
) de votre ressource, exécutez la requête suivante :
AzureMetrics
| take 100
| project TimeGenerated, MetricName, Total, Count, Maximum, Minimum, Average, TimeGrain, UnitName
La requête retourne un échantillon de 100 entrées et affiche un sous-ensemble des colonnes disponibles des données de métriques Azure :
Remarque
Lorsque vous sélectionnez Supervision>Journaux dans le menu d’Azure OpenAI pour vos ressources, Log Analytics s’ouvre avec une étendue de la requête définie sur la ressource actuelle. Les requêtes de journal visibles incluent des données provenant de cette ressource spécifique uniquement. Pour exécuter une requête qui inclut des données provenant d’autres ressources ou d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor dans le portail Azure. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.
Configurer des alertes
Azure Monitor vous avertit de façon proactive lorsque des conditions significatives sont détectées dans vos données de surveillance. Elles permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos utilisateurs ne les remarquent. Vous pouvez définir des alertes sur des métriques, sur des journaux et sur le journal d’activité. Les différents types d’alertes présentent des avantages et des inconvénients différents.
Les besoins d’alerte de chaque organisation varient et peuvent changer au fil du temps. En règle générale, toutes les alertes doivent être actionnables et doivent faire l’objet d’une réponse spécifique en cas de déclenchement de l’alerte. Si une alerte ne nécessite pas de réponse immédiate, la condition peut être capturée dans un rapport plutôt que dans une alerte. Certains cas d’usage peuvent nécessiter le déclanchement d’une alerte chaque fois que certaines conditions d’erreur existent. Dans d’autres cas, vous pouvez avoir besoin d’alertes pour les erreurs qui dépassent un certain seuil pendant une période désignée.
Les erreurs en dessous de certains seuils peuvent souvent être évaluées par l’analyse régulière des données dans les journaux Azure Monitor. Lorsque vous analysez vos données de journal au fil du temps, vous pouvez découvrir qu’une certaine condition ne se produit pas pendant une période attendue. Vous pouvez effectuer le suivi de cette condition à l’aide d’alertes. Parfois, l’absence d’un événement dans un journal est un signal tout aussi important qu’une erreur.
Selon le type d’application que vous développez avec votre utilisation de Azure OpenAI, Azure Monitor Application Insights peut offrir des avantages supplémentaires de supervision au niveau de la couche application.
Étapes suivantes
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour