പ്രധാനപ്പെട്ട ലിങ്കുകൾ
സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡ് (നിലവിൽ എന്റർപ്രൈസ് API ഉപഭോക്താക്കൾക്ക് മാത്രം ലഭ്യമാണ്)
ശരിയായ ഡിഫോൾട്ടുകളോടെ ആരംഭിക്കുക
നിങ്ങൾ സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡ് തുറക്കുമ്പോൾ, ഡിഫോൾട്ടായി ഇത് കാണിക്കും:
എല്ലാ പ്രോജക്റ്റുകളും
കഴിഞ്ഞ 30 ദിവസം
മണിക്കൂർ റെസല്യൂഷൻ
ഈ കാഴ്ച ദിശാബോധത്തിന് മാത്രം ഉപയോഗപ്രദമാണ്. അർത്ഥവത്തായ ട്രബിൾഷൂട്ടിംഗിന് എല്ലായ്പ്പോഴും ഫിൽട്ടറിംഗ് ആവശ്യമാണ്.
അന്വേഷിക്കുന്നതിന് മുമ്പ് ഫിൽട്ടർ ചെയ്യുക
ശരിയായ ഫിൽട്ടറിംഗാണ് ഏറ്റവും പ്രധാനപ്പെട്ട ഘട്ടം. മോഡലുകൾ, ടയറുകൾ, അല്ലെങ്കിൽ പ്രോജക്റ്റുകൾ എന്നിവ കലർത്തുന്നതിൽ നിന്നാണ് മിക്ക തെറ്റായ വ്യാഖ്യാനങ്ങളും ഉണ്ടാകുന്നത്.
മോഡൽ പ്രകാരം ഫിൽട്ടർ ചെയ്യുക (ഒന്നൊന്നായി)
എല്ലായ്പ്പോഴും ഒരൊറ്റ മോഡലിലേക്ക് ഫിൽട്ടർ ചെയ്യുക.
എന്തുകൊണ്ട്:
കുറഞ്ഞ ട്രാഫിക്കുള്ള മോഡലുകളിലെ പ്രശ്നങ്ങൾ ഉയർന്ന വോള്യമുള്ള ട്രാഫിക് മറയ്ക്കാം
ഉയർന്ന വോള്യമുള്ള മോഡലുകൾ പ്രാദേശികമായ പ്രശ്നങ്ങൾ ആഗോളമെന്ന് തോന്നിപ്പിക്കാം
വ്യത്യസ്ത മോഡലുകൾക്ക് വ്യത്യസ്ത പ്രകടന ലക്ഷ്യങ്ങളുണ്ട്
കുറിപ്പ്: ഒന്നിലധികം മോഡലുകൾ തിരഞ്ഞെടുക്കുന്നത് അവയെ അഗ്രഗേറ്റ് ചെയ്യുന്നു—അവയ്ക്കിടയിൽ മാറുന്നില്ല.
സർവീസ് ടയർ അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുക
ഒന്നിലധികം ടയറുകൾ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ (സാധാരണ, ഫാസ്റ്റ് മോഡ് (മുമ്പ് മുൻഗണനാ പ്രോസസ്സിങ്), സ്കെയിൽ ടയർ), നിങ്ങൾ പരിശോധിക്കുന്ന ടയർ മാത്രം ഉൾപ്പെടുത്തി എപ്പോഴും ഫിൽട്ടർ ചെയ്യുക.
എന്തുകൊണ്ട്:
ടയറുകളുടെ പ്രകടന സവിശേഷതകൾ വ്യത്യസ്തമാണ്
ഫാസ്റ്റ് മോഡിനും സ്കെയിൽ ടയറിനും നിർവചിക്കപ്പെട്ട SLA-കളുണ്ട്
ടയറുകൾ കലർത്തുന്നത് പണമടച്ചുള്ള ടയറിന്റെ പ്രകടനം വ്യക്തമാകാതാക്കുന്നു
കാലതാമസ വിശകലനത്തിന് ഇത് പ്രത്യേകിച്ചും പ്രധാനമാണ്.
നിലവിലുള്ള മോഡലുകളിൽ, ഫാസ്റ്റ് മോഡ് ട്രാഫിക് ഇപ്പോഴും ഉപയോഗ ഡാഷ്ബോർഡിൽ മുൻഗണനാ ട്രാഫിക്കായി ദൃശ്യമാകുന്നു.
പ്രോജക്റ്റ് പ്രകാരം ഫിൽട്ടർ ചെയ്യുക
ഡിഫോൾട്ടായി, സർവീസ് ഹെൽത്ത് എല്ലാ പ്രോജക്റ്റുകളും കാണിക്കുന്നു.
ട്രബിൾഷൂട്ടിംഗിനായി, പ്രശ്നം കണ്ട പ്രോജക്റ്റുകളിലേക്ക് ഫിൽട്ടർ ചെയ്യുക.
എന്തുകൊണ്ട്:
ഉയർന്ന വോള്യമുള്ള ഒരൊറ്റ പ്രോജക്റ്റിന് മെട്രിക്കുകളിൽ ആധിപത്യം പുലർത്താനാകും.
ബാധിക്കപ്പെട്ട ചെറിയ പ്രോജക്റ്റുകൾ ബന്ധമില്ലാത്ത ട്രാഫിക് കാരണം മറഞ്ഞുപോകാം.
പ്രശ്നം യഥാർത്ഥത്തിൽ മുഴുവൻ സ്ഥാപനത്തെയും ബാധിക്കുന്നുവെന്ന് നിങ്ങൾ വിശ്വസിക്കുന്നുവെങ്കിൽ മാത്രം "എല്ലാ പ്രോജക്റ്റുകളും" തിരഞ്ഞെടുത്ത നിലയിൽ വിടുക.
പിശകുകൾ ട്രബിൾഷൂട്ട് ചെയ്യൽ
HTTP Requests കാഴ്ച ഉപയോഗിക്കുക
പിശകുകൾ അന്വേഷിക്കാൻ:
മോഡലും സർവീസ് ടയറും പ്രകാരം ഫിൽട്ടർ ചെയ്യുക.
Uptime ടാബിന് പകരം HTTP Requests ടാബ് തുറക്കുക.
ഈ കാഴ്ച HTTP സ്റ്റാറ്റസ് കോഡ് പ്രകാരം മൊത്തം അഭ്യർത്ഥനകളും പിശക് എണ്ണങ്ങളും കാണിക്കുന്നു. വിശദമായ സ്പൈക്കുകളോ മാറ്റങ്ങളോ തിരിച്ചറിയാൻ മിനിറ്റ്-തല റെസല്യൂഷനിലേക്ക് സൂം ചെയ്യുക.
എണ്ണമല്ല, പിശക് നിരക്കുകൾ വ്യാഖ്യാനിക്കുക
ഏത് പ്രൊഡക്ഷൻ സിസ്റ്റത്തിലും ചില പിശകുകൾ പ്രതീക്ഷിക്കാവുന്നതാണ്. അസംസ്കൃത ആകെത്തുകയല്ല, പിശക് ശതമാനത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.
നിങ്ങളുടെ മൊത്തം വോള്യം കൂടുന്തോറും, അത്യന്തം കുറഞ്ഞ പിശക് നിരക്കിലും സാധ്യതയുള്ള പിശകുകളുടെ എണ്ണം കൂടും.
സർവീസ് ഹെൽത്തിൽ പിശകുകൾ ഇല്ലാത്തപ്പോൾ
ക്ലയന്റ്-സൈഡ് പിശകുകൾ കാണുന്നുവെങ്കിലും സർവീസ് ഹെൽത്തിൽ അനുബന്ധ ഡാറ്റ ഇല്ലെങ്കിൽ:
അഭ്യർത്ഥനകൾ OpenAI-യിൽ എത്തിയിരിക്കാനിടയില്ല.
പ്രശ്നം സാധാരണയായി അപ്സ്ട്രീമിലാണ് (ടൈംഔട്ടുകൾ, പ്രോക്സികൾ, നെറ്റ്‌വർക്കിംഗ്).
കടുത്ത ക്ലയന്റ്-സൈഡ് ടൈംഔട്ടുകളിൽ ഇത് സാധാരണമാണ്.
കാലതാമസം സംബന്ധിച്ച പ്രശ്നപരിഹാരം
നിർവചിക്കപ്പെട്ട SLA-കളുള്ള ഫാസ്റ്റ് മോഡ്, സ്കെയിൽ ടയർ എന്നിവയിലാണ് കാലതാമസ വിശകലനം ഏറ്റവും അർഥവത്താകുന്നത്. സാധാരണ ടയറിൽ കാലതാമസത്തിൽ കൂടുതൽ വ്യതിയാനം ഉണ്ടാകാം; കാലതാമസത്തിന് ഉറപ്പുമില്ല.
പ്രധാന മെട്രിക്കുകൾ
ഓരോ മെട്രിക്കും കാണാൻ, ബന്ധപ്പെട്ട ടാബിൽ ക്ലിക്ക് ചെയ്യുക:
ടോക്കൺ വേഗത: സെക്കൻഡിൽ സൃഷ്ടിക്കുന്ന ടോക്കണുകൾ; പ്രോംപ്റ്റ് വലുപ്പത്തിൽ നിന്ന് സ്വതന്ത്രം.
Request Time: മൊത്തം അഭ്യർത്ഥന ദൈർഘ്യം; ഔട്ട്പുട്ട് വലുപ്പവും റീസണിംഗും ശക്തമായി ബാധിക്കുന്നു.
ആദ്യ ടോക്കണിലേക്കുള്ള സമയം (TTFT): ആദ്യ ടോക്കൺ സൃഷ്ടിക്കപ്പെടുന്നതുവരെ ഉള്ള സമയം; കാഷ് ചെയ്യാത്ത ഇൻപുട്ട് പ്രോംപ്റ്റ് വലുപ്പവും റീസണിംഗും ശക്തമായി ബാധിക്കുന്നു.
P50 / P75 / P95 പെർസന്റൈലുകൾ എല്ലായ്പ്പോഴും അവലോകനം ചെയ്യുക. ശരാശരികൾ യഥാർത്ഥ ഉപയോക്തൃ സ്വാധീനം മറയ്ക്കാം.
പ്രതികരണ കാലതാമസവും ടോക്കൺ ഉപയോഗവും തമ്മിലുള്ള ബന്ധം കണ്ടെത്തൽ
പ്രവർത്തനരീതിയിൽ മാറ്റം വന്നത് എപ്പോഴാണെന്ന് സേവനനില കാണിക്കുന്നു. അത് എന്തുകൊണ്ടാണെന്ന് വിശദീകരിക്കാൻ ഉപയോഗ ഡാറ്റ സഹായിക്കുന്നു.
സേവനനില ഡാഷ്ബോർഡിൽ നിങ്ങൾ കാണുന്ന വിവരങ്ങളുമായി ബന്ധപ്പെട്ട ഡാറ്റയാണ് പരിശോധിക്കുന്നതെന്ന് ഉറപ്പാക്കാൻ, ഉപയോഗ ഡാഷ്ബോർഡിൽ ഇനിപ്പറയുന്നവ ചെയ്യുക:
അതേ പ്രോജക്റ്റും മോഡലും മാത്രം കാണാൻ ഫിൽട്ടർ ചെയ്യുക.
ബാധകമെങ്കിൽ, സർവീസ് ടയർ അനുസരിച്ച് ഗ്രൂപ്പുകളാക്കുക.
പ്രതികരണ കാലതാമസത്തെ ഏറ്റവുമധികം സ്വാധീനിക്കുന്ന ഔട്ട്പുട്ട് ടോക്കണുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.
കൂടുതൽ ആഴത്തിലുള്ള വിശകലനത്തിനായി, പ്രവർത്തന ഡാറ്റ എക്‌സ്‌പോർട്ട് ചെയ്ത് ഓരോ അഭ്യർത്ഥനയിലുമുള്ള ടോക്കണുകളുടെ എണ്ണം കാലക്രമത്തിൽ എങ്ങനെ മാറുന്നുവെന്ന് പരിശോധിക്കുക.
സഹായ വിഭാഗവുമായി പങ്കിടേണ്ട വിവരങ്ങൾ (ആവശ്യമെങ്കിൽ)
സഹായ വിഭാഗത്തെ ബന്ധപ്പെടുകയാണെങ്കിൽ, ഇനിപ്പറയുന്നവ ഉൾപ്പെടുത്തുക:
പ്രശ്നം ബാധിച്ച സ്ഥാപനങ്ങളുടെ ഐഡികൾ (പ്രധാനം)
പ്രശ്നം ബാധിച്ച എൻഡ്‌പോയിന്റുകൾ, ഉദാഹരണത്തിന് Chat Completions അല്ലെങ്കിൽ Responses (പ്രധാനം)
പ്രശ്നം ബാധിച്ച മോഡലുകൾ (പ്രധാനം)
പ്രശ്നം ഫാസ്റ്റ് മോഡിലാണോ സ്കെയിൽ ടയറിലാണോ ഉണ്ടാകുന്നത് (പ്രധാനം)
കാലതാമസമോ പിശകുകളോ ഉണ്ടായ സമയപരിധികൾ, സമയമേഖല സഹിതം (പ്രധാനം)
ലഭ്യമെങ്കിൽ, ബന്ധപ്പെട്ട x-request-id അല്ലെങ്കിൽ X-Client-Request-Id
നിങ്ങൾ നൽകുന്ന അഭ്യർത്ഥനകളുടെ സമയമുദ്രകൾ, സമയമേഖല സഹിതം; അല്ലെങ്കിൽ കുറഞ്ഞത് തീയതിയെങ്കിലും
ലഭ്യമെങ്കിൽ, ഇവയും ഉൾപ്പെടുത്തുക:
അഭ്യർത്ഥനകളുമായി ബന്ധപ്പെട്ട പ്രോജക്റ്റ് ഐഡി
ഡാറ്റ റെസിഡൻസി അഭ്യർത്ഥനകളെ പ്രശ്നം ബാധിച്ചിട്ടുണ്ടോ, ഉണ്ടെങ്കിൽ ഏതെല്ലാം
നിങ്ങൾ നിരീക്ഷിക്കുന്ന പ്രവണതകളുടെ വിവരണങ്ങൾ
പ്രശ്നത്തിന്റെ തരം അനുസരിച്ച്, ഇനിപ്പറയുന്നവ ഉൾപ്പെടുത്തുക:
പിശകുകൾ: പരാജയപ്പെടുന്നതോ പിശകുകൾ ഉണ്ടാകുന്നതോ ആയ അഭ്യർത്ഥനകളുടെ ഏകദേശ ശതമാനം, പ്രതികരണ കോഡുകൾ, പിശക് സന്ദേശങ്ങൾ, പിശക് പ്രതികരണം ലഭിക്കാൻ എടുത്ത സമയം.
പ്രതികരണ കാലതാമസം: ഏതൊക്കെ പെർസെന്റൈലുകളെയാണ് ബാധിച്ചിരിക്കുന്നത് (P50 / P90 / P95 / P99), ഉപഭോക്താവിന്റെ അടിസ്ഥാന നിലയുമായി താരതമ്യം ചെയ്യുമ്പോൾ അവ എത്രത്തോളം ഉയർന്നിരിക്കുന്നു, അയച്ചതും പ്രതികരണം ലഭിച്ചതുമായ സമയമുദ്രകൾ സഹിതം മന്ദഗതിയിലുള്ള അഭ്യർത്ഥനകളുടെ ഉദാഹരണങ്ങൾ.
രണ്ടും: പിശക് അല്ലെങ്കിൽ പ്രതികരണ കാലതാമസ ഡാറ്റയുടെ സ്‌ക്രീൻഷോട്ടുകളോ പട്ടികയോ, ഒപ്പം പിശക് നിരക്കുകളോ പ്രതികരണ കാലതാമസമോ പ്രതീക്ഷിച്ചതിലും കൂടുതലാണെന്ന് നിങ്ങൾ എങ്ങനെ നിർണയിച്ചു എന്നതും.
സാധാരണ ട്രബിൾഷൂട്ടിംഗ് സാഹചര്യങ്ങൾ
ടൈംഔട്ടുകൾ സംഭവിക്കുന്നു, എന്നാൽ സർവീസ് ഹെൽത്ത് സാധാരണയായി തോന്നുന്നു
സാധ്യമായ കാരണം: അഭ്യർത്ഥനകൾ OpenAI-യിൽ എത്തുന്നതിന് മുമ്പ് ടൈംഔട്ട് ചെയ്യുന്നു.
പരിശോധിക്കുക:
ക്ലയന്റ് അല്ലെങ്കിൽ പ്രോക്സി ടൈംഔട്ട് ക്രമീകരണങ്ങൾ
ലോക്കൽ നെറ്റ്‌വർക്ക് അല്ലെങ്കിൽ ലോഡ് ബാലൻസർ മാറ്റങ്ങൾ
സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡിൽ 499 പിശകുകളുടെ സാന്നിധ്യം (നിങ്ങളുടെ സ്വന്തം സിസ്റ്റങ്ങളിൽ ഇവ 5xx പിശകുകളായി കാണപ്പെട്ടേക്കാം).
ഡിപ്ലോയ്‌മെന്റ് ഇല്ലാതെ ലേറ്റൻസി വർധിച്ചു
സാധ്യമായ കാരണം: ഔട്ട്പുട്ട് ടോക്കൺ വലുപ്പം അല്ലെങ്കിൽ റീസണിംഗ് ഉപയോഗം വർധിച്ചു കൂടാതെ/അല്ലെങ്കിൽ ട്രാഫിക് സർവീസ് ടയറുകൾക്കിടയിൽ മാറി.
പരിശോധിക്കുക:
ഉപയോഗ ഡാഷ്ബോർഡിലെ ഓരോ അഭ്യർത്ഥനയ്ക്കുമുള്ള ശരാശരി ഔട്ട്പുട്ട് ടോക്കണുകൾ (ഡാറ്റ ഡൗൺലോഡ് ചെയ്ത് ഔട്ട്പുട്ട് ടോക്കണുകൾ മൊത്തം അഭ്യർത്ഥനകളാൽ വിഭജിക്കണം).
സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡിലെ Request Time, TTFT പെർസന്റൈലുകൾ.
ഫാസ്റ്റ് മോഡ് അല്ലെങ്കിൽ സ്കെയിൽ ടയർ മന്ദഗതിയിലാണെന്ന് തോന്നുന്നു
സാധ്യമായ കാരണം: വിവിധ ടയറുകളിലെ മെട്രിക്കുകൾ കലർന്നതിനാൽ, സാധാരണ ടയറിലെ ട്രാഫിക് പണമടച്ചുള്ള ടയറിന്റെ പ്രകടനം മറയ്ക്കുന്നു.
പരിശോധിക്കുക:
ഫിൽട്ടറുകൾ ഒരൊറ്റ ടയറിലേക്കും മോഡലിലേക്കും പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.
ടയറുകൾ തമ്മിലുള്ള ടോക്കൺ വേഗതയുടെ താരതമ്യം.
5XX പിശകുകളിൽ വർധന
സാധ്യതയുള്ള കാരണം: ട്രാഫിക്കിന്റെ ചെറിയ ശതമാനത്തെ ബാധിക്കുന്ന ക്ഷണികമായ പരാജയങ്ങൾ.
പരിശോധിക്കുക:
പിശക് നിരക്കിന്റെ ശതമാനം
അതേ സമയം ട്രാഫിക് വോള്യം മാറിയിട്ടുണ്ടോ എന്ന്
പ്രശ്നം ഒരു പ്രോജക്റ്റിനെ മാത്രം ബാധിക്കുന്നു
സാധ്യതയുള്ള കാരണം: പ്രോജക്റ്റ്-നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ അല്ലെങ്കിൽ ഉപയോഗ പാറ്റേൺ.
പരിശോധിക്കുക:
പ്രോജക്റ്റ്-തല ഫിൽട്ടറിംഗ്
ബാധിക്കപ്പെടാത്ത പ്രോജക്റ്റുകളുമായുള്ള താരതമ്യം
അവസാന നിഗമനങ്ങൾ
മെട്രിക്കുകൾ വ്യാഖ്യാനിക്കുന്നതിന് മുമ്പ്, പ്രസക്തമായിടത്ത് മോഡൽ, ടയർ, പ്രോജക്റ്റ് എന്നിവ പ്രകാരം ഫിൽട്ടർ ചെയ്യുക.
ലേറ്റൻസി വിശകലനത്തിന് ശരാശരികളല്ല, പെർസന്റൈലുകൾ ഉപയോഗിക്കുക.
ചെറിയ പിശക് നിരക്കുകൾ പ്രതീക്ഷിക്കാവുന്നതാണ്.
ഡാറ്റ ഇല്ലാത്തത് സാധാരണയായി അപ്സ്ട്രീം പ്രശ്നങ്ങൾ സൂചിപ്പിക്കുന്നു.
ലേറ്റൻസി എന്തുകൊണ്ട് മാറിയെന്ന് വിശദീകരിക്കാൻ ഉപയോഗ ഡാറ്റ സഹായിക്കും; പെരുമാറ്റം എപ്പോൾ മാറിയെന്ന് സർവീസ് ഹെൽത്ത് കാണിക്കുന്നു.