Σημαντικοί σύνδεσμοι
*Ο πίνακας ελέγχου Service Health είναι προς το παρόν διαθέσιμος μόνο σε πελάτες Enterprise API.
Ξεκινήστε με τις σωστές προεπιλογές
Όταν ανοίγετε τον πίνακα ελέγχου Service Health, η προεπιλεγμένη ρύθμιση είναι:
Όλα τα έργα
Τελευταίες 30 ημέρες
Ωριαία ανάλυση
Αυτή η προβολή είναι χρήσιμη μόνο για προσανατολισμό. Η ουσιαστική αντιμετώπιση προβλημάτων απαιτεί πάντα φιλτράρισμα.
Φιλτράρετε πριν ερευνήσετε
Το σωστό φιλτράρισμα είναι το πιο σημαντικό βήμα. Οι περισσότερες παρερμηνείες προκύπτουν από την ανάμειξη μοντέλων, βαθμίδων ή έργων.
Φιλτράρισμα κατά μοντέλο (ένα κάθε φορά)
Να φιλτράρετε πάντα σε ένα μόνο μοντέλο.
Γιατί:
Προβλήματα σε μοντέλα με χαμηλή κίνηση μπορεί να κρυφτούν από κίνηση μεγαλύτερου όγκου
Μοντέλα μεγάλου όγκου μπορεί να κάνουν τοπικά προβλήματα να φαίνονται καθολικά
Διαφορετικά μοντέλα έχουν διαφορετικούς στόχους απόδοσης
Σημείωση: η επιλογή πολλών μοντέλων τα συγκεντρώνει· δεν κάνει εναλλαγή μεταξύ τους.
Φιλτράρισμα κατά βαθμίδα υπηρεσίας
Αν χρησιμοποιείτε περισσότερες από μία βαθμίδες (standard, priority, scale), να φιλτράρετε πάντα στη βαθμίδα που ερευνάτε.
Γιατί:
Οι βαθμίδες έχουν διαφορετικά χαρακτηριστικά απόδοσης
Οι βαθμίδες priority και scale έχουν καθορισμένα SLA
Η ανάμειξη βαθμίδων αποκρύπτει την απόδοση των επί πληρωμή βαθμίδων
Αυτό είναι ιδιαίτερα σημαντικό για την ανάλυση καθυστέρησης.
Φιλτράρισμα κατά έργο
Από προεπιλογή, το Service Health εμφανίζει όλα τα έργα.
Για την αντιμετώπιση προβλημάτων, φιλτράρετε στο/στα έργο(-α) όπου παρατηρήθηκε το πρόβλημα.
Γιατί:
Ένα μόνο έργο μεγάλου όγκου μπορεί να κυριαρχεί στις μετρήσεις
Μικρότερα επηρεασμένα έργα μπορεί να καλύπτονται από άσχετη κίνηση
Αφήστε επιλεγμένο το "Όλα τα έργα" μόνο αν πιστεύετε ότι το πρόβλημα αφορά πραγματικά ολόκληρο τον οργανισμό.
Αντιμετώπιση σφαλμάτων
Χρησιμοποιήστε την προβολή HTTP Requests
Για να διερευνήσετε σφάλματα:
Φιλτράρετε κατά μοντέλο και βαθμίδα
Για να μεταβείτε από το Uptime στο HTTP Requests, κάντε κλικ στην καρτέλα HTTP Requests
Αυτή η προβολή εμφανίζει τα συνολικά αιτήματα και τις μετρήσεις σφαλμάτων ανά κωδικό κατάστασης HTTP. Κάντε ζουμ σε ανάλυση επιπέδου λεπτού για να εντοπίσετε λεπτομερείς αιχμές ή αλλαγές.
Ερμηνεύστε ποσοστά σφαλμάτων, όχι μετρήσεις
Ορισμένα σφάλματα είναι αναμενόμενα σε κάθε σύστημα παραγωγής. Εστιάστε στο ποσοστό σφαλμάτων, όχι στα ακατέργαστα σύνολα.
Όσο μεγαλύτερος είναι ο συνολικός όγκος σας, τόσο μεγαλύτερος είναι και ο πιθανός αριθμός σφαλμάτων ακόμη και με εξαιρετικά χαμηλό ποσοστό σφαλμάτων.
Όταν λείπουν σφάλματα από το Service Health
Αν βλέπετε σφάλματα στην πλευρά του πελάτη αλλά δεν υπάρχουν αντίστοιχα δεδομένα στο Service Health:
Τα αιτήματα πιθανότατα δεν έφτασαν στην OpenAI
Το πρόβλημα συνήθως βρίσκεται ανάντη (λήξεις χρονικού ορίου, proxy, δικτύωση)
Αυτό είναι συνηθισμένο με επιθετικές λήξεις χρονικού ορίου στην πλευρά του πελάτη.
Αντιμετώπιση καθυστέρησης
Η ανάλυση καθυστέρησης έχει περισσότερο νόημα στις βαθμίδες priority και scale, οι οποίες έχουν καθορισμένα SLA. Η βαθμίδα standard μπορεί να εμφανίζει μεγαλύτερη διακύμανση στην καθυστέρηση και δεν έχει εγγυημένη καθυστέρηση.
Βασικές μετρήσεις
Για να δείτε καθεμία από αυτές τις μετρήσεις, κάντε κλικ στη σχετική καρτέλα:
Ταχύτητα token
Tokens που δημιουργούνται ανά δευτερόλεπτο.
Ανεξάρτητα από το μέγεθος της προτροπής.
Χρόνος αιτήματος
Συνολική διάρκεια αιτήματος.
Επηρεάζεται έντονα από το μέγεθος της εξόδου και τη συλλογιστική.
Χρόνος μέχρι το πρώτο token (TTFT)
Χρόνος έως ότου δημιουργηθεί το πρώτο token.
Επηρεάζεται έντονα από το μέγεθος της μη αποθηκευμένης στην cache προτροπής εισόδου και τη συλλογιστική.
Να εξετάζετε πάντα τα εκατοστημόρια P50 / P75 / P95. Οι μέσοι όροι μπορούν να αποκρύψουν τον αντίκτυπο στους πραγματικούς χρήστες.
6. Συσχέτιση καθυστέρησης με τη χρήση token
Το Service Health δείχνει πότε άλλαξε η συμπεριφορά. Τα δεδομένα Usage βοηθούν να εξηγηθεί το γιατί.
Στον πίνακα ελέγχου Usage, κάντε τα εξής για να διασφαλίσετε ότι εξετάζετε τα δεδομένα που είναι σχετικά με την προβολή σας στον πίνακα ελέγχου Service Health:
Φιλτράρετε στο ίδιο έργο, μοντέλο
Ομαδοποιήστε κατά βαθμίδα υπηρεσίας αν εφαρμόζεται
Εστιάστε στα output tokens, τα οποία επηρεάζουν περισσότερο την καθυστέρηση
Για βαθύτερη ανάλυση, εξαγάγετε τα Activity Data και εξετάστε τα token ανά αίτημα με την πάροδο του χρόνου.
7. Τι να μοιραστείτε με την υποστήριξη (αν χρειάζεται)
Αν επικοινωνήσετε με την υποστήριξη, συμπεριλάβετε:
Αναγνωριστικά οργανισμού που επηρεάζονται (αυτό είναι σημαντικό)
Τελικά σημεία που επηρεάζονται (Chat Completions, Responses κ.λπ.) (αυτό είναι σημαντικό)
Μοντέλα που επηρεάζονται (αυτό είναι σημαντικό)
Είναι αυτό στη βαθμίδα scale ή priority; (αυτό είναι σημαντικό)
Χρονικά εύρη με ζώνη ώρας για καθυστέρηση ή σφάλμα (αυτό είναι σημαντικό)
Σχετικό x-request-id ή X-Client-Request-Id (συχνά σημαντικό· συμπεριλάβετε το αν είναι δυνατόν)
Χρονικές σημάνσεις με ζώνη ώρας (ή τουλάχιστον την ημερομηνία) των παρεχόμενων αιτημάτων
Καθυστέρηση - αν μοιράζεστε παραδείγματα αργών αιτημάτων, μοιραστείτε πόσο χρόνο χρειάστηκε από την πλευρά σας. Ιδανικά, συμπεριλάβετε επίσης τις χρονικές σημάνσεις για το πότε στάλθηκε το αίτημα και πότε παραλήφθηκε.
Σφάλματα - παρακαλούμε μοιραστείτε το κατά προσέγγιση ποσοστό αιτημάτων που αποτυγχάνουν/επιστρέφουν σφάλμα, τους κωδικούς απόκρισης, τα μηνύματα σφάλματος και πόσο χρόνο χρειάστηκε για να ληφθεί η απόκριση σφάλματος
Αναγνωριστικό έργου που σχετίζεται με τα αιτήματα
Επηρεάζει αυτό αιτήματα γεωγραφικής διαμονής δεδομένων; Αν ναι, ποια;
Περιγραφές των τάσεων που παρατηρείτε
Σφάλματα: Κατά προσέγγιση % αιτημάτων που αποτυγχάνουν/επιστρέφουν σφάλμα
Καθυστέρηση: Ποια εκατοστημόρια επηρεάζονται (p50 / p90 / p95 / p99) και πόσο υψηλά είναι σε σύγκριση με τη βασική γραμμή του πελάτη
Και τα δύο: Στιγμιότυπα οθόνης ή πίνακας δεδομένων σφάλματος ή καθυστέρησης (Πώς προσδιορίσατε ότι τα ποσοστά σφαλμάτων ή η καθυστέρηση είναι υψηλότερα από το αναμενόμενο;)
Συνήθη σενάρια αντιμετώπισης προβλημάτων
Προκύπτουν λήξεις χρονικού ορίου αλλά το Service Health φαίνεται φυσιολογικό
Πιθανή αιτία: τα αιτήματα λήγουν χρονικά πριν φτάσουν στην OpenAI.
Ελέγξτε:
Ρυθμίσεις λήξης χρονικού ορίου πελάτη ή proxy
Αλλαγές στο τοπικό δίκτυο ή στον load balancer
Παρουσία σφαλμάτων 499 στον πίνακα ελέγχου Service Health (αυτά μπορεί να εμφανίζονται ως σφάλματα 5xx στα δικά σας συστήματα).
Η καθυστέρηση αυξήθηκε χωρίς ανάπτυξη
Πιθανή αιτία: αυξήθηκε το μέγεθος των output token ή η χρήση συλλογιστικής και\or η κίνηση μετατοπίστηκε μεταξύ βαθμίδων υπηρεσίας
Ελέγξτε:
Μέσο αριθμό output token ανά αίτημα στον πίνακα ελέγχου Usage (απαιτεί λήψη δεδομένων και διαίρεση των output token με το σύνολο των αιτημάτων).
Εκατοστημόρια Request Time και TTFT στον πίνακα ελέγχου Service Health.
Η βαθμίδα Priority ή Scale φαίνεται αργή
Πιθανή αιτία: οι μετρήσεις αναμειγνύονται μεταξύ βαθμίδων (δηλαδή η κίνηση της βαθμίδας standard καλύπτει την απόδοση των επί πληρωμή βαθμίδων)
Ελέγξτε:
Τα φίλτρα περιορίζονται σε μία μόνο βαθμίδα και μοντέλο
Σύγκριση ταχύτητας token μεταξύ βαθμίδων
Αιχμή σε σφάλματα 5XX
Πιθανή αιτία: παροδικές αστοχίες που επηρεάζουν μικρό ποσοστό της κίνησης.
Ελέγξτε:
Ποσοστό σφαλμάτων
Αν ο όγκος της κίνησης άλλαξε την ίδια στιγμή
Το πρόβλημα επηρεάζει μόνο ένα έργο
Πιθανή αιτία: διαμόρφωση ή μοτίβο χρήσης ειδικό για το έργο.
Ελέγξτε:
Φιλτράρισμα σε επίπεδο έργου
Σύγκριση με έργα που δεν επηρεάζονται
Τελικά συμπεράσματα
Φιλτράρετε κατά μοντέλο, βαθμίδα και, όπου χρειάζεται, έργο πριν ερμηνεύσετε τις μετρήσεις
Χρησιμοποιήστε εκατοστημόρια, όχι μέσους όρους, για ανάλυση καθυστέρησης
Μικρά ποσοστά σφαλμάτων είναι αναμενόμενα
Τα δεδομένα που λείπουν συνήθως υποδεικνύουν προβλήματα ανάντη
Τα δεδομένα Usage μπορούν να βοηθήσουν να εξηγηθεί το γιατί άλλαξε η καθυστέρηση· το Service Health βοηθά να δείξει το πότε