Liens importants
*Le tableau de bord Service Health est actuellement disponible uniquement pour les clients Enterprise API.
Commencez avec les bons paramètres par défaut
Lorsque vous ouvrez le tableau de bord Service Health, les valeurs par défaut sont les suivantes :
Tous les projets
30 derniers jours
Résolution horaire
Cette vue est utile uniquement pour s’orienter. Un diagnostic pertinent nécessite toujours un filtrage.
Filtrez avant d’enquêter
Un filtrage correct est l’étape la plus importante. La plupart des erreurs d’interprétation proviennent du mélange des modèles, des niveaux de service ou des projets.
Filtrer par modèle (un à la fois)
Filtrez toujours sur un seul modèle.
Pourquoi :
Les problèmes sur les modèles à faible trafic peuvent être masqués par un trafic plus important
Les modèles à fort volume peuvent faire paraître des problèmes localisés comme globaux
Les différents modèles ont des objectifs de performance différents
Remarque : sélectionner plusieurs modèles les agrège — cela ne permet pas de basculer de l’un à l’autre.
Filtrer par niveau de service
Si vous utilisez plus d’un niveau (standard, priority, scale), filtrez toujours sur le niveau que vous examinez.
Pourquoi :
Les niveaux ont des caractéristiques de performance différentes
Les niveaux priority et scale ont des SLA définis
Mélanger les niveaux masque les performances des niveaux payants
Cela est particulièrement important pour l’analyse de la latence.
Filtrer par projet
Par défaut, Service Health affiche tous les projets.
Pour le diagnostic, filtrez sur le ou les projets où le problème a été observé.
Pourquoi :
Un seul projet à fort volume peut dominer les métriques
Les petits projets affectés peuvent être masqués par un trafic sans rapport
Ne laissez "Tous les projets" sélectionné que si vous pensez que le problème touche réellement toute l’organisation.
Diagnostic des erreurs
Utiliser la vue Requêtes HTTP
Pour analyser les erreurs :
Filtrez par modèle et par niveau
Pour passer de Uptime à Requêtes HTTP, cliquez sur l’onglet Requêtes HTTP
Cette vue affiche le total des requêtes et le nombre d’erreurs par code de statut HTTP. Zoomez jusqu’à une résolution à la minute pour identifier des pics ou changements précis.
Interpréter les taux d’erreur, pas les volumes
Certaines erreurs sont attendues dans tout système de production. Concentrez-vous sur le pourcentage d’erreurs, pas sur les totaux bruts.
Plus votre volume total est élevé, plus le nombre potentiel d’erreurs est important, même avec un taux d’erreur extrêmement faible.
Quand les erreurs sont absentes de Service Health
Si vous voyez des erreurs côté client mais aucune donnée correspondante dans Service Health :
Les requêtes n’ont probablement pas atteint OpenAI
Le problème se situe généralement en amont (timeouts, proxys, réseau)
C’est fréquent avec des timeouts côté client très agressifs.
Diagnostic de la latence
L’analyse de la latence est surtout pertinente sur les niveaux priority et scale, qui ont des SLA définis. Le niveau standard peut présenter une variation de latence plus large et n’offre pas de garantie de latence.
Métriques clés
Pour afficher chacune de ces métriques, cliquez sur l’onglet correspondant :
Vitesse des tokens
Tokens générés par seconde.
Indépendant de la taille du prompt.
Temps de requête
Durée totale de la requête.
Fortement influencé par la taille de la sortie et le raisonnement.
Temps jusqu’au premier token (TTFT)
Temps jusqu’à la génération du premier token.
Fortement influencé par la taille du prompt d’entrée non mis en cache et le raisonnement.
Examinez toujours les percentiles P50 / P75 / P95. Les moyennes peuvent masquer l’impact réel sur les utilisateurs.
6. Corréler la latence avec l’usage des tokens
Service Health montre quand le comportement a changé. Les données d’usage aident à expliquer pourquoi.
Dans le tableau de bord Usage, procédez comme suit pour vous assurer d’examiner les données pertinentes par rapport à votre vue dans le tableau de bord Service Health :
Filtrez sur le même projet, modèle
Regroupez par niveau de service le cas échéant
Concentrez-vous sur les tokens de sortie, qui ont le plus d’impact sur la latence
Pour une analyse plus poussée, exportez les données d’activité et examinez l’évolution du nombre de tokens par requête dans le temps.
7. Que partager avec le support (si nécessaire)
Si vous contactez le support, incluez :
Les ID d’organisation impactés (c’est important)
Les endpoints impactés (Chat Completions, Responses, etc.) (c’est important)
Les modèles impactés (c’est important)
Est-ce sur le niveau scale ou priority ? (c’est important)
Les plages horaires avec fuseau horaire pour la latence ou l’erreur (c’est important)
Le x-request-id ou X-Client-Request-Id pertinent (souvent important ; incluez-le si possible)
Horodatages avec fuseau horaire (ou au moins la date) des requêtes fournies
Latence - si vous partagez des exemples de requêtes lentes, indiquez combien de temps cela a pris de votre côté. Idéalement, incluez aussi les horodatages de l’envoi et de la réception de la requête.
Erreurs - veuillez indiquer le pourcentage approximatif de requêtes en échec/erronées, le ou les codes de réponse, le ou les messages d’erreur, et le temps nécessaire pour obtenir la réponse d’erreur
L’identifiant de projet lié aux requêtes
Cela affecte-t-il les demandes de résidence des données ? Si oui, lesquelles ?
Descriptions des tendances que vous observez
Erreurs : % approximatif des requêtes en échec/erronées
Latence : quels percentiles sont affectés (p50 / p90 / p95 / p99), et à quel point ils sont élevés par rapport à la base de référence du client
Les deux : captures d’écran ou tableau des données d’erreur ou de latence (comment avez-vous déterminé que les taux d’erreur ou la latence sont plus élevés que prévu ?)
Scénarios de diagnostic courants
Des timeouts se produisent mais Service Health semble normal
Cause possible : les requêtes expirent avant d’atteindre OpenAI.
Vérifiez :
Les paramètres de timeout du client ou du proxy
Les changements du réseau local ou de l’équilibreur de charge
La présence d’erreurs 499 dans le tableau de bord Service Health (elles peuvent apparaître comme des erreurs 5xx dans vos propres systèmes).
La latence a augmenté sans déploiement
Cause possible : la taille des tokens de sortie ou l’usage du raisonnement a augmenté et\ou le trafic s’est déplacé entre les niveaux de service
Vérifiez :
Le nombre moyen de tokens de sortie par requête dans le tableau de bord Usage (nécessite de télécharger les données et de diviser les tokens de sortie par le nombre total de requêtes).
Les percentiles du temps de requête et du TTFT dans le tableau de bord Service Health.
Le niveau Priority ou Scale semble lent
Cause possible : les métriques sont mélangées entre les niveaux (ce qui signifie que le trafic du niveau standard masque les performances des niveaux payants)
Vérifiez :
Les filtres sont limités à un seul niveau et modèle
La comparaison de la vitesse des tokens entre niveaux
Pic d’erreurs 5XX
Cause probable : des défaillances transitoires affectent un faible pourcentage du trafic.
Vérifiez :
Le pourcentage du taux d’erreur
Si le volume de trafic a changé au même moment
Le problème n’affecte qu’un seul projet
Cause probable : une configuration ou un schéma d’usage propre au projet.
Vérifiez :
Le filtrage au niveau du projet
La comparaison avec les projets non affectés
Points clés à retenir
Filtrez par modèle, niveau et, le cas échéant, par projet avant d’interpréter les métriques
Utilisez les percentiles, pas les moyennes, pour l’analyse de la latence
De faibles taux d’erreur sont attendus
L’absence de données indique généralement des problèmes en amont
Les données d’usage peuvent aider à expliquer pourquoi la latence a changé ; Service Health aide à montrer quand