მნიშვნელოვანი ბმულები
Service Health-ის საინფორმაციო დაფა (ამჟამად ხელმისაწვდომია მხოლოდ Enterprise API-ის მომხმარებლებისთვის)
დაიწყეთ სწორი ნაგულისხმევი პარამეტრებით
Service Health-ის საინფორმაციო დაფის გახსნისას ნაგულისხმევად ნაჩვენებია:
ყველა პროექტი
ბოლო 30 დღე
საათობრივი გარჩევადობა
ეს ხედი სასარგებლოა მხოლოდ ორიენტაციისთვის. აზრიანი პრობლემების აღმოფხვრა ყოველთვის გაფილტვრას მოითხოვს.
გაფილტრეთ მოკვლევამდე
სწორი გაფილტვრა ყველაზე მნიშვნელოვანი ნაბიჯია. არასწორი ინტერპრეტაციების უმეტესობა მოდელების, დონეების ან პროექტების შერევით არის გამოწვეული.
გაფილტვრა მოდელის მიხედვით (თითო ჯერზე ერთი)
ყოველთვის გაფილტრეთ ერთ მოდელამდე.
რატომ:
დაბალი ტრაფიკის მქონე მოდელებზე არსებული პრობლემები შეიძლება უფრო დიდი მოცულობის ტრაფიკმა დამალოს
დიდი მოცულობის მოდელებმა ლოკალიზებული პრობლემები შეიძლება გლობალურად წარმოაჩინოს
სხვადასხვა მოდელს განსხვავებული წარმადობის მიზნები აქვს
შენიშვნა: რამდენიმე მოდელის არჩევა მათ აერთიანებს — მათ შორის გადართვას არ ნიშნავს.
მომსახურების დონის მიხედვით გაფილტვრა
თუ ერთზე მეტ დონეს იყენებთ — სტანდარტულს, სწრაფ რეჟიმს (ყოფილი პრიორიტეტული დამუშავება) ან მასშტაბირების დონეს — ყოველთვის აირჩიეთ იმ დონის ფილტრი, რომელსაც იკვლევთ.
რატომ:
დონეებს წარმადობის განსხვავებული მახასიათებლები აქვს
სწრაფ რეჟიმსა და მასშტაბირების დონეს განსაზღვრული SLA-ები აქვს
დონეების შერევა ფასიანი დონის წარმადობას ფარავს
ეს განსაკუთრებით მნიშვნელოვანია დაყოვნების ანალიზისას.
არსებული მოდელებისთვის სწრაფი რეჟიმის ტრაფიკი მოხმარების დაფაზე კვლავ პრიორიტეტულად ჩანს.
გაფილტვრა პროექტის მიხედვით
ნაგულისხმევად, Service Health ყველა პროექტს აჩვენებს.
პრობლემების აღმოფხვრისთვის გაფილტრეთ იმ პროექტ(ებ)ზე, სადაც პრობლემა დაფიქსირდა.
რატომ:
ერთი დიდი მოცულობის პროექტს შეუძლია მეტრიკებზე დომინირება.
უფრო მცირე დაზარალებული პროექტები შეიძლება არარელევანტურმა ტრაფიკმა დაფაროს.
„ყველა პროექტი“ არჩეული დატოვეთ მხოლოდ მაშინ, თუ ფიქრობთ, რომ პრობლემა მართლაც მთელ ორგანიზაციას ეხება.
შეცდომების პრობლემების აღმოფხვრა
გამოიყენეთ HTTP Requests-ის ხედი
შეცდომების გამოსაკვლევად:
გაფილტრეთ მოდელისა და მომსახურების დონის მიხედვით.
გახსენით HTTP Requests ჩანართი Uptime ჩანართის ნაცვლად.
ეს ხედი აჩვენებს მოთხოვნების საერთო რაოდენობას და შეცდომების რაოდენობას HTTP სტატუსის კოდების მიხედვით. გაადიდეთ წუთის დონის გარჩევადობამდე, რათა დეტალური პიკები ან ცვლილებები ამოიცნოთ.
განმარტეთ შეცდომების სიხშირე და არა რაოდენობა
ზოგიერთი შეცდომა ნებისმიერ საწარმოო სისტემაში მოსალოდნელია. ყურადღება გაამახვილეთ შეცდომების პროცენტულ მაჩვენებელზე და არა დაუმუშავებელ ჯამებზე.
რაც უფრო დიდია თქვენი საერთო მოცულობა, მით უფრო დიდია შეცდომების პოტენციური რაოდენობა, თუნდაც შეცდომების სიხშირე უკიდურესად დაბალი იყოს.
როცა შეცდომები Service Health-ში არ ჩანს
თუ კლიენტის მხარეს ხედავთ შეცდომებს, მაგრამ Service Health-ში შესაბამისი მონაცემები არ არის:
მოთხოვნებმა, სავარაუდოდ, OpenAI-მდე ვერ მიაღწია.
პრობლემა, როგორც წესი, upstream-შია (ტაიმაუტები, პროქსიები, ქსელი).
ეს ხშირია კლიენტის მხარის აგრესიული ტაიმაუტების შემთხვევაში.
დაყოვნების პრობლემების მოგვარება
დაყოვნების ანალიზი ყველაზე ინფორმაციულია სწრაფი რეჟიმისა და მასშტაბირების დონისთვის, რადგან მათთვის განსაზღვრულია SLA-ები. სტანდარტულ დონეზე დაყოვნება შეიძლება უფრო მეტად მერყეობდეს და მისი მაჩვენებელი გარანტირებული არ არის.
ძირითადი მეტრიკები
თითოეული მეტრიკის სანახავად დააწკაპუნეთ შესაბამის ჩანართზე:
Token Velocity: წამში გენერირებული token-ები; მოთხოვნის ზომისგან დამოუკიდებელია.
Request Time: მოთხოვნის სრული ხანგრძლივობა; მასზე ძლიერ გავლენას ახდენს გამომავალი ზომა და მსჯელობა.
Time to First Token (TTFT): დრო პირველი token-ის გენერირებამდე; მასზე ძლიერ გავლენას ახდენს არაქეშირებული შეყვანის მოთხოვნის ზომა და მსჯელობა.
ყოველთვის გადახედეთ P50 / P75 / P95 პროცენტილებს. საშუალო მაჩვენებლებს შეუძლია დამალოს რეალურ მომხმარებლებზე გავლენა.
6. დაყოვნების კორელაცია token-ების გამოყენებასთან
Service Health აჩვენებს, როდის შეიცვალა ქცევა. გამოყენების მონაცემები გვეხმარება ავხსნათ, რატომ.
Usage-ის საინფორმაციო დაფაში გააკეთეთ შემდეგი, რათა დარწმუნდეთ, რომ Service Health-ის საინფორმაციო დაფაში თქვენს ხედთან შესაბამის მონაცემებს უყურებთ:
გაფილტრეთ იმავე პროექტითა და მოდელით.
დააჯგუფეთ მომსახურების დონის მიხედვით, თუ გამოიყენება.
ყურადღება გაამახვილეთ გამომავალ token-ებზე, რომლებიც დაყოვნებაზე ყველაზე ძლიერ გავლენას ახდენს.
უფრო ღრმა ანალიზისთვის გაიტანეთ Activity Data და დროთა განმავლობაში შეისწავლეთ token-ები თითო მოთხოვნაზე.
7. რა ინფორმაცია უნდა მიაწოდოთ მხარდაჭერის გუნდს (საჭიროების შემთხვევაში)
თუ მხარდაჭერის გუნდს დაუკავშირდებით, მიუთითეთ:
პრობლემის მქონე ორგანიზაციების ID-ები (მნიშვნელოვანია)
პრობლემის მქონე ენდპოინტები, მაგალითად Chat Completions ან Responses (მნიშვნელოვანია)
პრობლემის მქონე მოდელები (მნიშვნელოვანია)
გამოყენებულია სწრაფი რეჟიმი თუ მასშტაბირების დონე (მნიშვნელოვანია)
დაყოვნების ან შეცდომების დროის შუალედები, დროის სარტყლის მითითებით (მნიშვნელოვანია)
შესაბამისი x-request-id ან X-Client-Request-Id, თუ ხელმისაწვდომია
თქვენ მიერ მოწოდებული მოთხოვნების დროის ნიშნულები დროის სარტყლით, ან სულ მცირე, თარიღი
თუ ხელმისაწვდომია, ასევე მიუთითეთ:
მოთხოვნებთან დაკავშირებული პროექტის ID
ეხება თუ არა პრობლემა მონაცემთა ადგილმდებარეობის მოთხოვნებს და კონკრეტულად რომელს
თქვენ მიერ შემჩნეული ტენდენციების აღწერა
პრობლემის ტიპის მიხედვით მიუთითეთ:
შეცდომები: წარუმატებელი ან შეცდომით დასრულებული მოთხოვნების სავარაუდო პროცენტული წილი, პასუხის კოდები, შეცდომის შეტყობინებები და შეცდომის პასუხის მიღებამდე გასული დრო.
დაყოვნება: რომელ პროცენტილებს ეხება პრობლემა (P50 / P90 / P95 / P99), რამდენად აღემატება მათი მნიშვნელობები მომხმარებლის საბაზისო მაჩვენებელს და ნელი მოთხოვნების მაგალითები გაგზავნისა და მიღების დროის ნიშნულებით.
ორივე: შეცდომების ან დაყოვნების მონაცემების ეკრანის ანაბეჭდები ან ცხრილი და განმარტება, როგორ დაადგინეთ, რომ შეცდომების სიხშირე ან დაყოვნება მოსალოდნელზე მაღალი იყო.
პრობლემების აღმოფხვრის გავრცელებული სცენარები
ტაიმაუტები ხდება, მაგრამ Service Health ნორმალურად გამოიყურება
შესაძლო მიზეზი: მოთხოვნები OpenAI-მდე მიღწევამდე ტაიმაუტდება.
შეამოწმეთ:
კლიენტის ან პროქსის ტაიმაუტის პარამეტრები
ლოკალური ქსელის ან დატვირთვის ბალანსერის ცვლილებები
499 შეცდომების არსებობა Service Health-ის საინფორმაციო დაფაში (ისინი თქვენს სისტემებში შეიძლება 5xx შეცდომებად გამოჩნდეს).
დაყოვნება გაიზარდა დანერგვის გარეშე
შესაძლო მიზეზი: გაიზარდა გამომავალი token-ების ზომა ან მსჯელობის გამოყენება და/ან ტრაფიკი მომსახურების დონეებს შორის გადანაწილდა.
შეამოწმეთ:
საშუალო გამომავალი token-ები თითო მოთხოვნაზე Usage-ის საინფორმაციო დაფაში (საჭიროა მონაცემების ჩამოტვირთვა და გამომავალი token-ების გაყოფა მოთხოვნების საერთო რაოდენობაზე).
Request Time-ისა და TTFT-ის პროცენტილები Service Health-ის საინფორმაციო დაფაში.
სწრაფი რეჟიმი ან მასშტაბირების დონე ნელა მუშაობს
შესაძლო მიზეზი: სხვადასხვა დონის მეტრიკები გაერთიანებულია, ამიტომ სტანდარტული დონის ტრაფიკი ფასიანი დონის წარმადობას ფარავს.
შეამოწმეთ:
ფილტრებში არჩეულია მხოლოდ ერთი დონე და მოდელი.
ტოკენების სიჩქარის შედარება დონეებს შორის.
5XX შეცდომების მატება
სავარაუდო მიზეზი: დროებითი შეფერხებები, რომლებიც ტრაფიკის მცირე პროცენტზე მოქმედებს.
შეამოწმეთ:
შეცდომების სიხშირის პროცენტული მაჩვენებელი
შეიცვალა თუ არა ტრაფიკის მოცულობა იმავე დროს
პრობლემა მხოლოდ ერთ პროექტს ეხება
სავარაუდო მიზეზი: პროექტისთვის სპეციფიკური კონფიგურაცია ან გამოყენების ნიმუში.
შეამოწმეთ:
პროექტის დონის გაფილტვრა
შედარება პროექტებთან, რომლებსაც პრობლემა არ შეხებია
საბოლოო დასკვნები
მეტრიკების ინტერპრეტაციამდე, საჭიროებისამებრ, გაფილტრეთ მოდელის, დონისა და პროექტის მიხედვით.
დაყოვნების ანალიზისთვის გამოიყენეთ პროცენტილები და არა საშუალოები.
შეცდომების მცირე სიხშირე მოსალოდნელია.
მონაცემების არქონა, როგორც წესი, upstream პრობლემებზე მიუთითებს.
გამოყენების მონაცემები დაგეხმარებათ ახსნათ, რატომ შეიცვალა დაყოვნება; Service Health აჩვენებს, როდის შეიცვალა ქცევა.