Alibaba Cloud Model Studio:Surveillance des modèles

Model Studio offre des fonctionnalités de surveillance, d'alerte et de journalisation des modèles, vous permettant de suivre les appels de modèle en temps réel, de détecter rapidement les anomalies et de résoudre les problèmes.

Model Studio propose trois fonctionnalités d'alerte : les règles d'alerte, les modèles d'alerte et l'historique des alertes. Ces éléments sont accessibles via les onglets Alert rules, Alert templates et Alert history de la page Model Monitoring & Alerting.

Gestion des règles d'alerte

Sur la page Model Monitoring & Alerting, cliquez sur l'onglet Alerting pour accéder à la gestion des règles d'alerte. La liste affiche les règles actuellement actives et permet de créer, modifier, arrêter ou supprimer des règles. Elle indique également les destinataires des notifications (contacts ou groupes de contacts) et prend en charge plusieurs canaux, tels que l'e-mail.

Pour configurer l'alerte pour la première fois, suivez ce parcours : commencez par autoriser le rôle lié au service CloudMonitor dans la section Data delivery > Monitoring data delivery, puis créez une règle d'alerte dans cette rubrique (en sélectionnant un modèle d'alerte et en remplissant les champs), et enfin configurez les notifications d'alerte (contacts ou groupes de contacts, plage horaire de notification et politique de répétition).

Avant de créer une règle d'alerte, vous devez autoriser le rôle lié au service CloudMonitor dans la livraison de la surveillance des modèles (pour savoir comment procéder, consultez la section Data delivery > Monitoring data delivery). Sans cette autorisation, le bouton Create alert rule reste inactif ; un survol de la souris affiche alors le message suivant : « The CloudMonitor service-linked role is not authorized, so you cannot create an alert rule. Click to authorize. » Une fois l'autorisation accordée, le service CloudMonitor est activé automatiquement en arrière-plan.

1. Cliquez sur Create Alert Rule pour ouvrir une nouvelle page.
2. Renseignez le nom de l'alerte, le modèle d'alerte, le modèle concerné, la durée, la période de vérification de l'alerte, le contenu de l'alerte et le niveau d'alerte, comme décrit dans le tableau des champs ci-dessous.
3. Configurez les notifications d'alerte (contacts ou groupes de contacts, plage horaire de notification et politique de répétition), puis cliquez sur Create pour terminer.

Le tableau suivant décrit les champs du formulaire.

Field	Required	Description
Alert name	Required	Jusqu'à 50 caractères.
Alert template	Required	Sélectionnez un modèle prédéfini ou personnalisé dans la liste déroulante, ou créez-en un en enregistrant une copie basée sur un modèle existant.
Model	Required	Jusqu'à 50 modèles.
Duration	Required	Spécifié en minutes.
Alert check period	Required	Par défaut 60 secondes, exprimé en secondes ; doit être un entier supérieur ou égal à 0 (0 signifie que l'alerte est déclenchée immédiatement).
Alert content	Required	Jusqu'à 200 caractères ; prend en charge les variables (vous pouvez insérer des espaces réservés tels que workspace, model et current value).
Alert level	Optional	INFO / WARNING / ERROR / CRITICAL. Par défaut INFO.
Alert contacts / contact groups	Multiple allowed	Issus des contacts ou groupes de contacts CloudMonitor.
Notification time range	Required	N'importe quel intervalle sur 24 heures, pouvant s'étendre sur deux jours (par exemple, de 23:00 à 01:00 le lendemain).
Repeat policy	Required	Aucune escalade signifie que l'alerte n'est envoyée qu'une seule fois tant qu'elle n'est pas résolue ; sinon, spécifiez un intervalle en heures et minutes pour répéter les notifications.

Si vous avez déjà activé la livraison de la surveillance et configuré des règles d'alerte, vous pouvez migrer vos règles d'alerte depuis l'instance Prometheus de CloudMonitor vers Model Studio en un clic. Actuellement, seules les règles d'alerte créées par la plateforme peuvent être migrées ; celles créées directement dans CloudMonitor ne sont pas éligibles.

1. Au-dessus de la liste des règles d'alerte, cliquez sur Migrate now ou Migrate alert rules.
2. Confirm the migration source. Vérifiez le nom et l'état de l'instance Prometheus, puis cliquez sur Start detection.
3. Check alert rules. Le système détecte les règles d'alerte migrables et celles qui sont incompatibles. Sélectionnez-les, confirmez votre choix, puis cliquez sur Start migration.
4. Migrate alert rules. Pendant la migration, le statut « Migrating » s'affiche. À la fin du processus, le résultat (succès ou échec) est indiqué. En cas d'échec, vous pouvez réessayer. Après une migration réussie, fermez la boîte de dialogue.

Après la migration, les règles d'alerte de l'instance Prometheus sont désactivées (mais non supprimées) ; vous pouvez les supprimer manuellement côté Prometheus. La tâche de migration est conservée pendant 6 heures et l'actualisation de la page n'interrompt pas le processus. Une fois la migration réussie, aucune seconde migration n'est nécessaire, l'entrée de migration est masquée et seul un message de succès intégré s'affiche.

Les règles d'alerte prennent en charge les opérations d'arrêt, de modification et de suppression.

Portée de l'alerte : actuellement, seules certaines métriques prennent en charge l'alerte. Les éléments configurables sont indiqués ligne par ligne dans le tableau des métriques de la section Model monitoring details.

Modèles d'alerte

Un modèle d'alerte est une configuration d'alerte avec des conditions de déclenchement prédéfinies. Il permet de créer rapidement des règles d'alerte sans tout configurer depuis zéro. Le système fournit 12 modèles prédéfinis, mais vous pouvez aussi créer les vôtres. L'onglet Alert templates se trouve sur la page Model Monitoring & Alerting, au même niveau que les onglets Alert rules et Alert history.

Cliquez sur Create alert template pour ouvrir le panneau latéral de création de modèle d'alerte, puis renseignez les informations suivantes :

• Template name : Obligatoire, jusqu'à 20 caractères.
• Parameter : Jusqu'à 10 paramètres. Choisissez de déclencher l'alerte lorsque toutes les règles remplissent les conditions (ET) ou lorsqu'au moins une règle les remplit (OU).
• Metric : Obligatoire. Sélectionne la métrique à surveiller pour l'alerte. Les options de la liste déroulante incluent les appels, les échecs, le taux d'échec, la durée des appels et le temps jusqu'au premier token.
• Alert Threshold : Obligatoire. Sélectionnez un opérateur de comparaison (>, >=, <, <=, ==, !=) et une valeur.
• Cycle : En minutes. Plage valide de 1 à 10 080 minutes.

Les modèles d'alerte prédéfinis sont identifiés par un tag Preset après leur nom. Ils permettent de consulter les détails et de faire une copie, mais ne peuvent ni être modifiés ni supprimés. Les modèles d'alerte personnalisés prennent en charge la consultation des détails, la modification, la suppression et la copie. Recommandations : utilisez d'abord les modèles prédéfinis pour couvrir les scénarios d'alerte courants (la métrique et le seuil sont prédéfinis pour des charges typiques) ; il suffit de renseigner les paramètres pour les utiliser. Recourez aux modèles personnalisés pour des conditions composites complexes ou des règles spécifiques à votre activité. Le tableau suivant liste les métriques prises en charge par les modèles d'alerte prédéfinis.

Preset alert template name	Metric
Model call failures: 1-minute sum > 10	Model call failures
Model call failure ratio: 1-minute sum > 1 %	Model call failure ratio
Model 4xx calls: 1-minute sum > 10	Model 4xx calls
Model 4xx ratio: 1-minute sum > 1 %	Model 4xx ratio
Model 429 calls: 1-minute sum > 10	Model 429 calls
Model 429 ratio: 1-minute sum > 1 %	Model 429 ratio
Model 5xx calls: 1-minute sum > 10	Model 5xx calls
Model 5xx ratio: 1-minute sum > 1 %	Model 5xx ratio
Model calls: 1-minute sum > 500	Model calls
Model call duration: 1-minute average > 60 seconds	Model call duration
Model time to first token: 1-minute average > 10 seconds	Model time to first token (first-token latency)
Model TotalToken consumption: 1-minute sum > 10000	Model TotalToken consumption

Historique des alertes

Sur la page Model Monitoring & Alerting, cliquez sur l'onglet History pour consulter les enregistrements de déclenchement des alertes. Dans la liste de l'historique des alertes, le destinataire de la notification affiche uniquement les informations de contact, et non les canaux de notification associés.

Vous pouvez filtrer l'historique des alertes selon quatre critères : l'heure de l'alerte (préréglages rapides et calendrier), la règle d'alerte, le niveau d'alerte et le statut (Recovered ou Alerting).

La liste de l'historique des alertes affiche les colonnes suivantes.

Column	Description
Alert instance	Identifiant de l'instance d'alerte
Alert level	INFO / WARNING / ERROR / CRITICAL
Alert time	Moment du déclenchement de l'alerte
Alert count	Nombre de déclenchements de cette alerte
Alert rule	Nom et ID de la règle d'alerte
Status	Recovered ou Alerting
Notification recipient	Contacts d'alerte ou groupes de contacts
Actions	View details (ouvre le panneau latéral des détails de l'alerte)

Cliquez sur View details dans la liste pour ouvrir le panneau latéral des détails de l'alerte. Le statut dans ce panneau ne peut prendre que deux valeurs : Recovered et Alerting.

Vue d'ensemble de la surveillance des modèles

Model Studio propose une surveillance unifiée des modèles. Un appel apparaît dans les graphiques de surveillance environ 1 à 2 minutes (jusqu'à 5 minutes) après son occurrence, ce qui vous aide à suivre les appels en temps réel. Les données de surveillance sont isolées par workspace : vous ne pouvez voir que les données du workspace actuellement sélectionné. Ces données sont fournies à titre indicatif et ne servent pas de base à la facturation. Pour la réconciliation, consultez votre facture dans Expenses and Costs.

Cette rubrique est organisée par fonctionnalité : pour dépanner les appels de modèle, commencez par l'audit log ; pour configurer des alertes, reportez-vous à la section Alerting ; pour activer la livraison des données, consultez la section Data delivery.

Filtrer les données de surveillance par dimension

Vous pouvez filtrer les données de surveillance par Time (préréglages rapides et personnalisé), Inference Type et API key (tous affichés par défaut ; montre l'ID et la description, et liste uniquement les clés API présentes dans le workspace actuel). Le filtrage par granularité temporelle est disponible uniquement sur la page des détails de la surveillance des modèles.

Consulter l'échelle globale des appels et l'état de santé

La page de vue d'ensemble affiche des cartes de données telles que le nombre total de modèles, le nombre total d'appels, le nombre total d'échecs, la durée moyenne des appels et le temps moyen jusqu'au premier token (latence du premier token), vous permettant d'évaluer rapidement l'échelle globale des appels et l'état de santé du service.

Afficher les détails de surveillance ou les journaux d'un modèle

La liste des modèles affiche les données de surveillance pour chaque modèle du workspace actuel. Cliquez sur View details pour ouvrir la page des détails de surveillance du modèle, ou sur View Logs pour accéder à l'onglet Audit Log de la page des journaux. Connectez-vous à la console Model Studio, puis dans le volet de navigation de gauche, choisissez Model Monitoring & Alerting pour ouvrir la page de vue d'ensemble de la surveillance.

Détails de la surveillance des modèles

Sur la page de vue d'ensemble de la surveillance, repérez le modèle cible dans la liste et cliquez sur View details pour ouvrir sa page de détails. Le chemin de navigation en haut de la page est : Model monitoring > nom du modèle.

La page de détails affiche les statistiques d'appels et les graphiques de performance pour un modèle unique, et propose un accès rapide à la configuration des alertes : la cloche d'alerte sur un graphique de métrique vous permet de configurer rapidement une alerte pour le modèle ou la métrique actuel (pour la gestion complète des règles inter-modèles, consultez la section Alerting). Les filtres sont identiques à ceux de la page de vue d'ensemble (temps, granularité temporelle, type d'inférence et clé API), et les paramètres de la page de vue d'ensemble sont conservés lors de la navigation. Pour consulter les journaux, revenez à la liste des modèles sur la page de vue d'ensemble et cliquez sur l'entrée View logs (voir la section Logging).

Métriques de surveillance

Sur la page de détails, les métriques sont présentées en deux groupes : statistiques d'appels et performance. Le tableau suivant détaille la signification, les notes de référence et la prise en charge des alertes pour chaque métrique.

Metric	Description	Reference	Alerting support
Calls	Nombre total d'appels au modèle	Varie selon l'activité	Configurable
Usage	Total des tokens	Varie selon l'activité	Configurable
Failures	Nombre d'appels ayant échoué	Varie selon l'activité	Configurable
Failure rate	Échecs divisés par le nombre total d'appels	Varie selon l'activité	Configurable
Call duration	Durée totale de la requête à la réponse	Varie selon le modèle et le scénario	Configurable
Time to first token	Latence entre la requête et le retour du premier token	Varie selon le modèle et le scénario	Configurable
Subsequent token latency	Temps moyen de génération de chaque token après le premier	Varie selon le modèle et le scénario	Non pris en charge
Model TotalToken consumption	Total des tokens consommés, agrégé par modèle (métrique dédiée aux modèles d'alerte prédéfinis)	Varie selon l'activité	Configurable
Average usage per request	Moyenne des tokens par requête	Varie selon l'activité	Non pris en charge
Content moderation error count	Nombre de blocages dus à la modération de contenu	Varie selon l'activité	Non pris en charge
Rate limiting error count	Nombre de déclenchements de limite de débit 429	Varie selon l'activité	Configurable
RPM	Requêtes par minute	Varie selon l'activité	Non pris en charge
TPM	Tokens par minute	Varie selon l'activité	Non pris en charge
Output tokens per second (TPS)	Tokens de sortie par seconde	Varie selon le modèle et le scénario	Non pris en charge

Pour plus de détails sur les codes d'erreur et la limitation de débit, consultez Codes d'erreur.

Configuration de la cloche d'alerte

Les métriques prenant en charge l'alerte affichent une icône de cloche sur leur graphique. Cliquez sur la cloche pour ouvrir le panneau latéral de configuration de la règle d'alerte (pour le détail des champs, voir la section Gestion des règles d'alerte). L'icône de cloche et les libellés de statut du panneau latéral ont les significations suivantes :

Type	Status	Color	Meaning
Bell icon	No alert configured	Gray	Aucune règle d'alerte n'est configurée ; cliquez pour ouvrir le panneau de configuration
Bell icon	Alert configured, normal	Blue	Une règle est configurée et n'est pas actuellement déclenchée ; cliquez pour voir les détails de la règle
Bell icon	Alerting	Red	Une alerte est en cours de déclenchement ; cliquez pour voir les détails du déclenchement
Side-panel label	Normal	Green	Une règle est configurée et son statut est normal
Side-panel label	Alerting	Red	Une alerte est en cours de déclenchement
Side-panel label	Disabled	Gray	La règle est désactivée et ne génère plus d'alertes

Après avoir cliqué sur la cloche, le panneau latéral d'alerte affiche différents champs selon le statut de l'alerte (Normal = non déclenchée, Alerting = actuellement déclenchée, Recovered = déclenchée puis résolue) :

Field	Normal	Recovered	Alerting
Alert rule name	Shown	Shown	Shown
Alert rule ID	Shown	Shown	Shown
Alert content	Shown	Shown	Shown
Alert metric	Shown	Shown	Shown
Notification recipients	Shown	Shown	Shown
Alert target	Shown	Shown	Shown
Start time	Hidden	Shown	Shown
Duration	Hidden	Shown	Shown
Alert count	Hidden	Shown	Shown
Status	Hidden	Shown	Shown
Recovery time	Hidden	Shown	Hidden

Journalisation

Model Studio enregistre par défaut les audit logs (stockés sur la plateforme, aucune configuration requise), qui capturent les informations de requête de chaque appel de modèle, mais pas le Prompt ni la Response. Les inference logs enregistrent le Prompt et la Response complets ainsi que les étapes intermédiaires ; ils doivent être activés manuellement et reposent sur la livraison des journaux pour écrire les données dans votre propre Logstore Simple Log Service (SLS) (pour la livraison des journaux, voir la section Data delivery).

Audit Log

Les audit logs sont activés par défaut pour tous les utilisateurs, ne nécessitent aucune configuration et sont stockés sur la plateforme Model Studio. Ils enregistrent les informations de requête de chaque appel de modèle, y compris les métriques clés telles que Request ID, l'heure, le modèle, l'utilisation des tokens, la latence et le statut, mais n'incluent pas le contenu du Prompt et de la Response. Pour afficher le contenu complet du Prompt et de la Response, activez les inference logs (pour savoir comment les activer, voir la section Inference Log).

Conditions de filtrage

Les audit logs prennent en charge les conditions de filtrage suivantes :

• Time range : 7 derniers jours par défaut ; permet de interroger les journaux sur une période allant jusqu'à 30 jours.
• Model : Sélection dans une liste déroulante ; tous les modèles par défaut.
• API key ID : Sélection dans une liste déroulante. Les clés API affichent l'ID et la description ; si une clé API est supprimée, la description est vide.
• Status : Sélection multiple, incluant 0 (requête réussie mais interrompue activement par l'utilisateur), 200 (succès), 4XX (exceptions causées par le comportement de l'utilisateur) et 5XX (service indisponible).
• Inference Type : Inférence en temps réel par défaut.
• Search Request ID : Correspondance exacte.

Liste des journaux

La liste des audit logs affiche les champs suivants : Request ID, heure de l'appel, modèle, utilisation, temps jusqu'au premier token, durée de l'appel, statut et code d'erreur. La colonne Actions propose View details pour ouvrir la boîte de dialogue de configuration de la livraison des journaux. Vous pouvez également y accéder en cliquant sur le bouton Start configuration en haut à droite de la page des journaux. Après avoir complété l'autorisation et la configuration du Logstore, vous pourrez consulter la liste des inference logs.

Liste des journaux et détails

Les conditions de filtrage des inference logs sont identiques à celles des audit logs, à l'exception du filtre de type d'inférence (inférence en temps réel/inférence par lots) qui est supprimé. Pour les modèles ne prenant pas en charge les inference logs, le message « The current model is not supported » s'affiche.

En plus des données des audit logs, la liste des inference logs ajoute les données Prompt et Response, avec une limite de longueur de 128 Ko. Le contenu dépassant 128 Ko est tronqué ; pour le contenu complet, consultez les journaux d'appels réels.

Les règles d'affichage après la suppression d'une clé API sont les mêmes que pour les audit logs (la liste n'affiche pas la description, et les détails montrent uniquement l'ID).

Les inference logs peuvent être réinjectés dans des jeux de données d'entraînement. Pour plus d'informations, consultez Log backflow.

Data delivery

Par défaut, Model Studio stocke les métriques de surveillance et les audit logs sur la plateforme, vous permettant de les consulter dans la console sans aucune livraison. Pour livrer les métriques de surveillance ou les journaux vers vos propres services Alibaba Cloud (pour une conservation à long terme ou une intégration avec vos systèmes d'exploitation et de maintenance, ce qui engendre des frais de service cloud), activez la livraison de données correspondante : les données de surveillance sont livrées vers une instance CloudMonitor Prometheus, et les journaux vers un Logstore Simple Log Service (SLS). La livraison des journaux est également une condition préalable aux inference logs.

Livraison des données de surveillance

L'entrée de livraison de la surveillance des modèles se trouve dans le coin supérieur gauche de la page de vue d'ensemble de la surveillance. La livraison de la surveillance des modèles livre automatiquement les données de surveillance des modèles Model Studio vers une instance Prometheus d'Alibaba Cloud CloudMonitor pour une gestion unifiée des données de surveillance. Model Studio fournit par défaut des métriques de service de modèle, consultables sur la plateforme sans configuration supplémentaire. Pour livrer ces métriques vers le service CloudMonitor de votre compte, activez la livraison de données et configurez la ressource cible.

Étapes de configuration

Pour les nouveaux utilisateurs, la configuration de la livraison de la surveillance des modèles nécessite les étapes suivantes :

1. Autorisez le rôle lié au service CloudMonitor.
2. Activez le service CloudMonitor.
3. Créez une instance de surveillance CloudMonitor Prometheus.

La livraison de la surveillance des modèles prend actuellement en charge uniquement les instances CloudMonitor Prometheus, et non les instances Prometheus auto-gérées. Pour les utilisateurs existants ayant déjà activé la livraison de la surveillance, la configuration existante est migrée automatiquement, les données de surveillance de la plateforme sont livrées automatiquement vers l'instance Prometheus précédemment activée, et celle-ci ne peut pas être modifiée. Après l'activation de la livraison, les données de surveillance sont stockées à la fois côté plateforme et côté utilisateur.

Statut de la livraison

Après avoir configuré la livraison des données, un indicateur de statut s'affiche à côté de la livraison de la surveillance des modèles :

• Delivering (vert)
• Delivery failed (rouge)
• Delivery not configured (gris)

Le bouton bascule de livraison est Log delivery configuration. Les détails de l'autorisation sont développés par défaut.

Log delivery

L'entrée de configuration de la livraison des journaux se trouve dans le coin supérieur droit de la page des journaux. Sur la page de vue d'ensemble de la surveillance, sélectionnez un modèle pour accéder à sa page de détails, puis basculez vers la page des journaux pour voir cette entrée. La livraison des journaux livre automatiquement les audit logs et les inference logs des modèles Model Studio vers un Logstore d'Alibaba Cloud Simple Log Service pour une gestion unifiée des données. Pour livrer les journaux vers le service Simple Log Service de votre compte, activez la livraison des journaux et terminez la configuration.

Étapes de configuration

La configuration de la livraison des journaux pour la première fois nécessite les trois étapes suivantes :

1. Autorisez le rôle Simple Log Service.
2. Activez Simple Log Service.
3. Créez un Logstore.

Les utilisateurs existants ayant déjà activé la livraison des journaux n'ont pas besoin de reconfigurer ; la configuration originale est conservée automatiquement et le Logstore ne peut pas être modifié.

Livraison des audit logs

Après avoir activé ou désactivé la livraison des audit logs, un message de résultat s'affiche brièvement en haut de la page. Le processus d'autorisation et de configuration est identique aux étapes de configuration ci-dessus.

Livraison des inference logs

Avant d'activer la livraison des inference logs, vous devez d'abord activer la livraison des audit logs (la livraison des inference logs ne peut pas être activée si la livraison des audit logs n'est pas configurée). Le processus d'autorisation et de configuration pour la livraison des inference logs est identique à celui décrit ci-dessus.

Une fois la configuration terminée, un indicateur de statut s'affiche à côté de la configuration de la livraison des journaux ; les trois états ont la même signification que pour la livraison des données de surveillance.