მნიშვნელოვანი ბმულები
Service Health-ის საინფორმაციო დაფა (ამჟამად ხელმისაწვდომია მხოლოდ Enterprise API-ის მომხმარებლებისთვის)
დაიწყეთ სწორი ნაგულისხმევი პარამეტრებით
Service Health-ის საინფორმაციო დაფის გახსნისას ნაგულისხმევად ნაჩვენებია:
ყველა პროექტი
ბოლო 30 დღე
საათობრივი გარჩევადობა
ეს ხედი სასარგებლოა მხოლოდ ორიენტაციისთვის. აზრიანი პრობლემების აღმოფხვრა ყოველთვის გაფილტვრას მოითხოვს.
გაფილტრეთ მოკვლევამდე
სწორი გაფილტვრა ყველაზე მნიშვნელოვანი ნაბიჯია. არასწორი ინტერპრეტაციების უმეტესობა მოდელების, დონეების ან პროექტების შერევით არის გამოწვეული.
გაფილტვრა მოდელის მიხედვით (თითო ჯერზე ერთი)
ყოველთვის გაფილტრეთ ერთ მოდელამდე.
რატომ:
დაბალი ტრაფიკის მქონე მოდელებზე არსებული პრობლემები შეიძლება უფრო დიდი მოცულობის ტრაფიკმა დამალოს
დიდი მოცულობის მოდელებმა ლოკალიზებული პრობლემები შეიძლება გლობალურად წარმოაჩინოს
სხვადასხვა მოდელს განსხვავებული წარმადობის მიზნები აქვს
შენიშვნა: რამდენიმე მოდელის არჩევა მათ აერთიანებს — მათ შორის გადართვას არ ნიშნავს.
გაფილტვრა მომსახურების დონის მიხედვით
თუ ერთზე მეტ დონეს იყენებთ (standard, priority, scale), ყოველთვის გაფილტრეთ იმ დონემდე, რომელსაც იკვლევთ.
რატომ:
დონეებს განსხვავებული წარმადობის მახასიათებლები აქვთ
პრიორიტეტულ და მასშტაბირების დონეებს განსაზღვრული 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. რა უნდა გაუზიაროთ მხარდაჭერას (საჭიროების შემთხვევაში)
თუ მხარდაჭერას დაუკავშირდებით, მიუთითეთ:
ზემოქმედების ქვეშ მყოფი Org ID-ები (მნიშვნელოვანი)
ზემოქმედების ქვეშ მყოფი საბოლოო წერტილები, როგორიცაა Chat Completions ან Responses (მნიშვნელოვანი)
ზემოქმედების ქვეშ მყოფი მოდელები (მნიშვნელოვანი)
არის თუ არა ეს Scale ან Priority დონეზე (მნიშვნელოვანი)
დაყოვნების ან შეცდომების დროის დიაპაზონები დროის სარტყლით (მნიშვნელოვანი)
შესაბამისი x-request-id ან X-Client-Request-Id, თუ ხელმისაწვდომია
დროის ნიშნულები დროის სარტყლით, ან მინიმუმ თარიღი, იმ მოთხოვნებისთვის, რომლებსაც გვაწვდით
თუ ხელმისაწვდომია, ასევე მიუთითეთ:
მოთხოვნებთან დაკავშირებული Project ID
ზემოქმედების ქვეშ არის თუ არა მონაცემთა ადგილმდებარეობის მოთხოვნები და რომლები
იმ ტენდენციების აღწერები, რომლებსაც ხედავთ
პრობლემის ტიპისთვის მიუთითეთ:
შეცდომები: წარუმატებელი ან შეცდომიანი მოთხოვნების მიახლოებითი პროცენტი, პასუხის კოდები, შეცდომის შეტყობინებები და რამდენი დრო დასჭირდა შეცდომის პასუხის მიღებას.
დაყოვნება: რომელ პროცენტილებზეა გავლენა (P50 / P90 / P95 / P99), რამდენად მაღალია ისინი მომხმარებლის საბაზისო მაჩვენებელთან შედარებით, და ნელი მოთხოვნების მაგალითები გაგზავნისა და მიღების დროის ნიშნულებით.
ორივე: შეცდომების ან დაყოვნების მონაცემების ეკრანის ანაბეჭდები ან ცხრილი, ასევე როგორ დაადგინეთ, რომ შეცდომების სიხშირე ან დაყოვნება მოსალოდნელზე მაღალი იყო.
პრობლემების აღმოფხვრის გავრცელებული სცენარები
ტაიმაუტები ხდება, მაგრამ Service Health ნორმალურად გამოიყურება
შესაძლო მიზეზი: მოთხოვნები OpenAI-მდე მიღწევამდე ტაიმაუტდება.
შეამოწმეთ:
კლიენტის ან პროქსის ტაიმაუტის პარამეტრები
ლოკალური ქსელის ან დატვირთვის ბალანსერის ცვლილებები
499 შეცდომების არსებობა Service Health-ის საინფორმაციო დაფაში (ისინი თქვენს სისტემებში შეიძლება 5xx შეცდომებად გამოჩნდეს).
დაყოვნება გაიზარდა დანერგვის გარეშე
შესაძლო მიზეზი: გაიზარდა გამომავალი token-ების ზომა ან მსჯელობის გამოყენება და/ან ტრაფიკი მომსახურების დონეებს შორის გადანაწილდა.
შეამოწმეთ:
საშუალო გამომავალი token-ები თითო მოთხოვნაზე Usage-ის საინფორმაციო დაფაში (საჭიროა მონაცემების ჩამოტვირთვა და გამომავალი token-ების გაყოფა მოთხოვნების საერთო რაოდენობაზე).
Request Time-ისა და TTFT-ის პროცენტილები Service Health-ის საინფორმაციო დაფაში.
Priority ან Scale Tier ნელი ჩანს
შესაძლო მიზეზი: მეტრიკები დონეებს შორის არის შერეული, რაც ნიშნავს, რომ სტანდარტული დონის ტრაფიკი ფასიანი დონის წარმადობას ფარავს.
შეამოწმეთ:
ფილტრები შეზღუდულია ერთი დონითა და მოდელით.
token-ების სიჩქარის შედარება დონეებს შორის.
5XX შეცდომების მატება
სავარაუდო მიზეზი: დროებითი შეფერხებები, რომლებიც ტრაფიკის მცირე პროცენტზე მოქმედებს.
შეამოწმეთ:
შეცდომების სიხშირის პროცენტული მაჩვენებელი
შეიცვალა თუ არა ტრაფიკის მოცულობა იმავე დროს
პრობლემა მხოლოდ ერთ პროექტს ეხება
სავარაუდო მიზეზი: პროექტისთვის სპეციფიკური კონფიგურაცია ან გამოყენების ნიმუში.
შეამოწმეთ:
პროექტის დონის გაფილტვრა
შედარება პროექტებთან, რომლებსაც პრობლემა არ შეხებია
საბოლოო დასკვნები
მეტრიკების ინტერპრეტაციამდე, საჭიროებისამებრ, გაფილტრეთ მოდელის, დონისა და პროექტის მიხედვით.
დაყოვნების ანალიზისთვის გამოიყენეთ პროცენტილები და არა საშუალოები.
შეცდომების მცირე სიხშირე მოსალოდნელია.
მონაცემების არქონა, როგორც წესი, upstream პრობლემებზე მიუთითებს.
გამოყენების მონაცემები დაგეხმარებათ ახსნათ, რატომ შეიცვალა დაყოვნება; Service Health აჩვენებს, როდის შეიცვალა ქცევა.