API പിശകുകളും ലാറ്റൻസിയും ട്രബിൾഷൂട്ട് ചെയ്യൽ

പ്രധാനപ്പെട്ട ലിങ്കുകൾ

• സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡ് (നിലവിൽ എന്റർപ്രൈസ് API ഉപഭോക്താക്കൾക്ക് മാത്രം ലഭ്യമാണ്)

• ഉപയോഗ ഡാഷ്ബോർഡ്

ശരിയായ ഡിഫോൾട്ടുകളോടെ ആരംഭിക്കുക

നിങ്ങൾ സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡ് തുറക്കുമ്പോൾ, ഡിഫോൾട്ടായി ഇത് കാണിക്കും:

• എല്ലാ പ്രോജക്റ്റുകളും

• കഴിഞ്ഞ 30 ദിവസം

• മണിക്കൂർ റെസല്യൂഷൻ

ഈ കാഴ്ച ദിശാബോധത്തിന് മാത്രം ഉപയോഗപ്രദമാണ്. അർത്ഥവത്തായ ട്രബിൾഷൂട്ടിംഗിന് എല്ലായ്പ്പോഴും ഫിൽട്ടറിംഗ് ആവശ്യമാണ്.

അന്വേഷിക്കുന്നതിന് മുമ്പ് ഫിൽട്ടർ ചെയ്യുക

ശരിയായ ഫിൽട്ടറിംഗാണ് ഏറ്റവും പ്രധാനപ്പെട്ട ഘട്ടം. മോഡലുകൾ, ടയറുകൾ, അല്ലെങ്കിൽ പ്രോജക്റ്റുകൾ എന്നിവ കലർത്തുന്നതിൽ നിന്നാണ് മിക്ക തെറ്റായ വ്യാഖ്യാനങ്ങളും ഉണ്ടാകുന്നത്.

മോഡൽ പ്രകാരം ഫിൽട്ടർ ചെയ്യുക (ഒന്നൊന്നായി)

എല്ലായ്പ്പോഴും ഒരൊറ്റ മോഡലിലേക്ക് ഫിൽട്ടർ ചെയ്യുക.

എന്തുകൊണ്ട്:

• കുറഞ്ഞ ട്രാഫിക്കുള്ള മോഡലുകളിലെ പ്രശ്നങ്ങൾ ഉയർന്ന വോള്യമുള്ള ട്രാഫിക് മറയ്ക്കാം

• ഉയർന്ന വോള്യമുള്ള മോഡലുകൾ പ്രാദേശികമായ പ്രശ്നങ്ങൾ ആഗോളമെന്ന് തോന്നിപ്പിക്കാം

• വ്യത്യസ്ത മോഡലുകൾക്ക് വ്യത്യസ്ത പ്രകടന ലക്ഷ്യങ്ങളുണ്ട്

കുറിപ്പ്: ഒന്നിലധികം മോഡലുകൾ തിരഞ്ഞെടുക്കുന്നത് അവയെ അഗ്രഗേറ്റ് ചെയ്യുന്നു—അവയ്ക്കിടയിൽ മാറുന്നില്ല.

സർവീസ് ടയർ പ്രകാരം ഫിൽട്ടർ ചെയ്യുക

നിങ്ങൾ ഒന്നിലധികം ടയർ (സ്റ്റാൻഡേർഡ്, പ്രയോറിറ്റി, സ്കെയിൽ) ഉപയോഗിക്കുന്നുവെങ്കിൽ, അന്വേഷിക്കുന്ന ടയറിലേക്ക് എല്ലായ്പ്പോഴും ഫിൽട്ടർ ചെയ്യുക.

എന്തുകൊണ്ട്:

• ടയറുകൾക്ക് വ്യത്യസ്ത പ്രകടന സവിശേഷതകളുണ്ട്

• പ്രയോറിറ്റി, സ്കെയിൽ ടയറുകൾക്ക് നിർവചിച്ച SLA-കളുണ്ട്

• ടയറുകൾ കലർത്തുന്നത് പെയ്ഡ്-ടയർ പ്രകടനം മറയ്ക്കുന്നു

ലേറ്റൻസി വിശകലനത്തിന് ഇത് പ്രത്യേകിച്ച് പ്രധാനമാണ്.

പ്രോജക്റ്റ് പ്രകാരം ഫിൽട്ടർ ചെയ്യുക

ഡിഫോൾട്ടായി, സർവീസ് ഹെൽത്ത് എല്ലാ പ്രോജക്റ്റുകളും കാണിക്കുന്നു.

ട്രബിൾഷൂട്ടിംഗിനായി, പ്രശ്നം കണ്ട പ്രോജക്റ്റുകളിലേക്ക് ഫിൽട്ടർ ചെയ്യുക.

എന്തുകൊണ്ട്:

• ഉയർന്ന വോള്യമുള്ള ഒരൊറ്റ പ്രോജക്റ്റിന് മെട്രിക്കുകളിൽ ആധിപത്യം പുലർത്താനാകും.

• ബാധിക്കപ്പെട്ട ചെറിയ പ്രോജക്റ്റുകൾ ബന്ധമില്ലാത്ത ട്രാഫിക് കാരണം മറഞ്ഞുപോകാം.

പ്രശ്നം യഥാർത്ഥത്തിൽ മുഴുവൻ സ്ഥാപനത്തെയും ബാധിക്കുന്നുവെന്ന് നിങ്ങൾ വിശ്വസിക്കുന്നുവെങ്കിൽ മാത്രം "എല്ലാ പ്രോജക്റ്റുകളും" തിരഞ്ഞെടുത്ത നിലയിൽ വിടുക.

പിശകുകൾ ട്രബിൾഷൂട്ട് ചെയ്യൽ

HTTP Requests കാഴ്ച ഉപയോഗിക്കുക

പിശകുകൾ അന്വേഷിക്കാൻ:

1. മോഡലും സർവീസ് ടയറും പ്രകാരം ഫിൽട്ടർ ചെയ്യുക.

2. Uptime ടാബിന് പകരം HTTP Requests ടാബ് തുറക്കുക.

ഈ കാഴ്ച HTTP സ്റ്റാറ്റസ് കോഡ് പ്രകാരം മൊത്തം അഭ്യർത്ഥനകളും പിശക് എണ്ണങ്ങളും കാണിക്കുന്നു. വിശദമായ സ്പൈക്കുകളോ മാറ്റങ്ങളോ തിരിച്ചറിയാൻ മിനിറ്റ്-തല റെസല്യൂഷനിലേക്ക് സൂം ചെയ്യുക.

എണ്ണമല്ല, പിശക് നിരക്കുകൾ വ്യാഖ്യാനിക്കുക

ഏത് പ്രൊഡക്ഷൻ സിസ്റ്റത്തിലും ചില പിശകുകൾ പ്രതീക്ഷിക്കാവുന്നതാണ്. അസംസ്കൃത ആകെത്തുകയല്ല, പിശക് ശതമാനത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.

നിങ്ങളുടെ മൊത്തം വോള്യം കൂടുന്തോറും, അത്യന്തം കുറഞ്ഞ പിശക് നിരക്കിലും സാധ്യതയുള്ള പിശകുകളുടെ എണ്ണം കൂടും.

സർവീസ് ഹെൽത്തിൽ പിശകുകൾ ഇല്ലാത്തപ്പോൾ

ക്ലയന്റ്-സൈഡ് പിശകുകൾ കാണുന്നുവെങ്കിലും സർവീസ് ഹെൽത്തിൽ അനുബന്ധ ഡാറ്റ ഇല്ലെങ്കിൽ:

• അഭ്യർത്ഥനകൾ OpenAI-യിൽ എത്തിയിരിക്കാനിടയില്ല.

• പ്രശ്നം സാധാരണയായി അപ്സ്ട്രീമിലാണ് (ടൈംഔട്ടുകൾ, പ്രോക്സികൾ, നെറ്റ്‌വർക്കിംഗ്).

കടുത്ത ക്ലയന്റ്-സൈഡ് ടൈംഔട്ടുകളിൽ ഇത് സാധാരണമാണ്.

ലേറ്റൻസി ട്രബിൾഷൂട്ട് ചെയ്യൽ

നിർവചിച്ച SLA-കളുള്ള പ്രയോറിറ്റി, സ്കെയിൽ ടയറുകളിലാണ് ലേറ്റൻസി വിശകലനം ഏറ്റവും അർത്ഥവത്താകുന്നത്. സ്റ്റാൻഡേർഡ് ടയറിൽ കൂടുതൽ വ്യാപകമായ ലേറ്റൻസി വ്യത്യാസം കാണാം, കൂടാതെ ഉറപ്പുനൽകിയ ലേറ്റൻസി ഇല്ല.

പ്രധാന മെട്രിക്കുകൾ

ഓരോ മെട്രിക്കും കാണാൻ, ബന്ധപ്പെട്ട ടാബിൽ ക്ലിക്ക് ചെയ്യുക:

• ടോക്കൺ വേഗത: സെക്കൻഡിൽ സൃഷ്ടിക്കുന്ന ടോക്കണുകൾ; പ്രോംപ്റ്റ് വലുപ്പത്തിൽ നിന്ന് സ്വതന്ത്രം.

• Request Time: മൊത്തം അഭ്യർത്ഥന ദൈർഘ്യം; ഔട്ട്പുട്ട് വലുപ്പവും റീസണിംഗും ശക്തമായി ബാധിക്കുന്നു.

• ആദ്യ ടോക്കണിലേക്കുള്ള സമയം (TTFT): ആദ്യ ടോക്കൺ സൃഷ്ടിക്കപ്പെടുന്നതുവരെ ഉള്ള സമയം; കാഷ് ചെയ്യാത്ത ഇൻപുട്ട് പ്രോംപ്റ്റ് വലുപ്പവും റീസണിംഗും ശക്തമായി ബാധിക്കുന്നു.

P50 / P75 / P95 പെർസന്റൈലുകൾ എല്ലായ്പ്പോഴും അവലോകനം ചെയ്യുക. ശരാശരികൾ യഥാർത്ഥ ഉപയോക്തൃ സ്വാധീനം മറയ്ക്കാം.

6. ലേറ്റൻസിയെ ടോക്കൺ ഉപയോഗവുമായി ബന്ധിപ്പിക്കൽ

പെരുമാറ്റം എപ്പോൾ മാറിയെന്ന് സർവീസ് ഹെൽത്ത് കാണിക്കുന്നു. എന്തുകൊണ്ട് എന്ന് വിശദീകരിക്കാൻ ഉപയോഗ ഡാറ്റ സഹായിക്കുന്നു.

Service Health Dashboard-ലെ നിങ്ങളുടെ കാഴ്ചയ്ക്ക് പ്രസക്തമായ ഡാറ്റയാണ് കാണുന്നതെന്ന് ഉറപ്പാക്കാൻ, Usage dashboard-ൽ ഇനിപ്പറയുന്നവ ചെയ്യുക:

• അതേ പ്രോജക്റ്റിലേക്കും മോഡലിലേക്കും ഫിൽട്ടർ ചെയ്യുക.

• ബാധകമാണെങ്കിൽ, സർവീസ് ടയർ പ്രകാരം ഗ്രൂപ്പ് ചെയ്യുക.

• ലേറ്റൻസിയെ ഏറ്റവും ശക്തമായി ബാധിക്കുന്ന ഔട്ട്പുട്ട് ടോക്കണുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.

കൂടുതൽ ആഴത്തിലുള്ള വിശകലനത്തിന്, Activity Data എക്സ്പോർട്ട് ചെയ്ത് കാലക്രമത്തിൽ ഓരോ അഭ്യർത്ഥനയ്ക്കുമുള്ള ടോക്കണുകൾ പരിശോധിക്കുക.

7. പിന്തുണയുമായി പങ്കിടേണ്ടത് (ആവശ്യമെങ്കിൽ)

നിങ്ങൾ പിന്തുണയുമായി ബന്ധപ്പെടുകയാണെങ്കിൽ, ഉൾപ്പെടുത്തുക:

• ബാധിച്ച Org ID-കൾ (പ്രധാനം)

• Chat Completions അല്ലെങ്കിൽ Responses പോലുള്ള ബാധിച്ച എൻഡ്‌പോയിന്റുകൾ (പ്രധാനം)

• ബാധിച്ച മോഡലുകൾ (പ്രധാനം)

• ഇത് സ്കെയിൽ അല്ലെങ്കിൽ പ്രയോറിറ്റി ടയറിലാണോ എന്ന് (പ്രധാനം)

• ലേറ്റൻസി അല്ലെങ്കിൽ പിശകുകൾക്കുള്ള സമയമേഖലയോടുകൂടിയ സമയപരിധികൾ (പ്രധാനം)

• ലഭ്യമാണെങ്കിൽ, പ്രസക്തമായ x-request-id അല്ലെങ്കിൽ X-Client-Request-Id

• നിങ്ങൾ നൽകുന്ന അഭ്യർത്ഥനകൾക്കായി സമയമേഖലയോടുകൂടിയ ടൈംസ്റ്റാമ്പുകൾ, അല്ലെങ്കിൽ കുറഞ്ഞത് തീയതി

ലഭ്യമാണെങ്കിൽ, ഇവയും ഉൾപ്പെടുത്തുക:

• അഭ്യർത്ഥനകളുമായി ബന്ധപ്പെട്ട പ്രോജക്റ്റ് ID

• ഡാറ്റ റെസിഡൻസി അഭ്യർത്ഥനകൾ ബാധിക്കപ്പെട്ടിട്ടുണ്ടോ, ഏവയാണ് ബാധിച്ചിരിക്കുന്നത്

• നിങ്ങൾ കാണുന്ന ട്രെൻഡുകളുടെ വിവരണങ്ങൾ

പ്രശ്നത്തിന്റെ തരം സംബന്ധിച്ച്, ഉൾപ്പെടുത്തുക:

• പിശകുകൾ: പരാജയപ്പെടുന്ന അല്ലെങ്കിൽ പിശകുള്ള അഭ്യർത്ഥനകളുടെ ഏകദേശ ശതമാനം, റെസ്പോൺസ് കോഡുകൾ, പിശക് സന്ദേശങ്ങൾ, പിശക് റെസ്പോൺസ് ലഭിക്കാൻ എടുത്ത സമയം.

• ലേറ്റൻസി: ഏത് പെർസന്റൈലുകളാണ് ബാധിച്ചിരിക്കുന്നത് (P50 / P90 / P95 / P99), ഉപഭോക്താവിന്റെ ബേസ്‌ലൈനുമായി താരതമ്യം ചെയ്യുമ്പോൾ അവ എത്ര ഉയർന്നതാണ്, അയച്ചതും സ്വീകരിച്ചതുമായ ടൈംസ്റ്റാമ്പുകളോടുകൂടിയ മന്ദഗതിയിലുള്ള അഭ്യർത്ഥനകളുടെ ഉദാഹരണങ്ങൾ.

• രണ്ടും: പിശക് അല്ലെങ്കിൽ ലേറ്റൻസി ഡാറ്റയുടെ സ്ക്രീൻഷോട്ടുകളോ പട്ടികയോ, കൂടാതെ പിശക് നിരക്കുകളോ ലേറ്റൻസിയോ പ്രതീക്ഷിച്ചതിലും കൂടുതലാണെന്ന് നിങ്ങൾ നിർണ്ണയിച്ച വിധം.

സാധാരണ ട്രബിൾഷൂട്ടിംഗ് സാഹചര്യങ്ങൾ

ടൈംഔട്ടുകൾ സംഭവിക്കുന്നു, എന്നാൽ സർവീസ് ഹെൽത്ത് സാധാരണയായി തോന്നുന്നു

സാധ്യമായ കാരണം: അഭ്യർത്ഥനകൾ OpenAI-യിൽ എത്തുന്നതിന് മുമ്പ് ടൈംഔട്ട് ചെയ്യുന്നു.

പരിശോധിക്കുക:

• ക്ലയന്റ് അല്ലെങ്കിൽ പ്രോക്സി ടൈംഔട്ട് ക്രമീകരണങ്ങൾ

• ലോക്കൽ നെറ്റ്‌വർക്ക് അല്ലെങ്കിൽ ലോഡ് ബാലൻസർ മാറ്റങ്ങൾ

• സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡിൽ 499 പിശകുകളുടെ സാന്നിധ്യം (നിങ്ങളുടെ സ്വന്തം സിസ്റ്റങ്ങളിൽ ഇവ 5xx പിശകുകളായി കാണപ്പെട്ടേക്കാം).

ഡിപ്ലോയ്‌മെന്റ് ഇല്ലാതെ ലേറ്റൻസി വർധിച്ചു

സാധ്യമായ കാരണം: ഔട്ട്പുട്ട് ടോക്കൺ വലുപ്പം അല്ലെങ്കിൽ റീസണിംഗ് ഉപയോഗം വർധിച്ചു കൂടാതെ/അല്ലെങ്കിൽ ട്രാഫിക് സർവീസ് ടയറുകൾക്കിടയിൽ മാറി.

പരിശോധിക്കുക:

• ഉപയോഗ ഡാഷ്ബോർഡിലെ ഓരോ അഭ്യർത്ഥനയ്ക്കുമുള്ള ശരാശരി ഔട്ട്പുട്ട് ടോക്കണുകൾ (ഡാറ്റ ഡൗൺലോഡ് ചെയ്ത് ഔട്ട്പുട്ട് ടോക്കണുകൾ മൊത്തം അഭ്യർത്ഥനകളാൽ വിഭജിക്കണം).

• സർവീസ് ഹെൽത്ത് ഡാഷ്ബോർഡിലെ Request Time, TTFT പെർസന്റൈലുകൾ.

പ്രയോറിറ്റി അല്ലെങ്കിൽ സ്കെയിൽ ടയർ മന്ദഗതിയിലാണെന്ന് തോന്നുന്നു

സാധ്യമായ കാരണം: മെട്രിക്കുകൾ ടയറുകളിലുടനീളം കലർന്നിരിക്കുന്നു, അതായത് സ്റ്റാൻഡേർഡ്-ടയർ ട്രാഫിക് പെയ്ഡ്-ടയർ പ്രകടനത്തെ മറയ്ക്കുന്നു.

പരിശോധിക്കുക:

• ഫിൽട്ടറുകൾ ഒരൊറ്റ ടയറിലേക്കും മോഡലിലേക്കും പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

• ടയറുകൾ തമ്മിലുള്ള ടോക്കൺ വേഗത താരതമ്യം.

5XX പിശകുകളിൽ വർധന

സാധ്യതയുള്ള കാരണം: ട്രാഫിക്കിന്റെ ചെറിയ ശതമാനത്തെ ബാധിക്കുന്ന ക്ഷണികമായ പരാജയങ്ങൾ.

പരിശോധിക്കുക:

• പിശക് നിരക്കിന്റെ ശതമാനം

• അതേ സമയം ട്രാഫിക് വോള്യം മാറിയിട്ടുണ്ടോ എന്ന്

പ്രശ്നം ഒരു പ്രോജക്റ്റിനെ മാത്രം ബാധിക്കുന്നു

സാധ്യതയുള്ള കാരണം: പ്രോജക്റ്റ്-നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ അല്ലെങ്കിൽ ഉപയോഗ പാറ്റേൺ.

പരിശോധിക്കുക:

• പ്രോജക്റ്റ്-തല ഫിൽട്ടറിംഗ്

• ബാധിക്കപ്പെടാത്ത പ്രോജക്റ്റുകളുമായുള്ള താരതമ്യം

അവസാന നിഗമനങ്ങൾ

• മെട്രിക്കുകൾ വ്യാഖ്യാനിക്കുന്നതിന് മുമ്പ്, പ്രസക്തമായിടത്ത് മോഡൽ, ടയർ, പ്രോജക്റ്റ് എന്നിവ പ്രകാരം ഫിൽട്ടർ ചെയ്യുക.

• ലേറ്റൻസി വിശകലനത്തിന് ശരാശരികളല്ല, പെർസന്റൈലുകൾ ഉപയോഗിക്കുക.

• ചെറിയ പിശക് നിരക്കുകൾ പ്രതീക്ഷിക്കാവുന്നതാണ്.

• ഡാറ്റ ഇല്ലാത്തത് സാധാരണയായി അപ്സ്ട്രീം പ്രശ്നങ്ങൾ സൂചിപ്പിക്കുന്നു.

• ലേറ്റൻസി എന്തുകൊണ്ട് മാറിയെന്ന് വിശദീകരിക്കാൻ ഉപയോഗ ഡാറ്റ സഹായിക്കും; പെരുമാറ്റം എപ്പോൾ മാറിയെന്ന് സർവീസ് ഹെൽത്ത് കാണിക്കുന്നു.