LLM сұраулары үшін тұтас trace_id: ақтаңдақсыз бақылау

Инциденттің көрінісі қай жерде жоғалады

Пайдаланушы бір ғана ақауды көреді: чат ұзақ ойланып қалады, бос жауап береді немесе тапсырыстың қате статусын сенімді түрде жазады. Адам үшін бұл бір инцидент. Жүйе ішінде болса, бұл ондаған оқиғаға бөлінеді.

Олардың бір бөлігі қолданба логтарына түседі, бір бөлігі API шлюзіне, бір бөлігі іздеуге, бір бөлігі құрал шақырулары мен модель провайдеріне кетеді. Егер әр қабаттың өз идентификаторы болса, жалпы көрініс бөлшектеніп кетеді. Бір жерде request_id, басқа жерде chat_id, үшінші жерде tool_call_id тұрады, ал кейде команда тек уақыт бойынша іздеуге мәжбүр болады.

Сондықтан разбор тез арада қолмен құрастыратын пазлға айналады. Бір инженер backend логтарын қарайды, екіншісі модельдің жауабын тексереді, үшіншісі білім базасындағы іздеуге кіреді. Тіпті бірнеше секунд айырмашылықтың өзі кедергі жасайды: retry, streaming және параллель шақырулар ұқсас бірнеше жазба жасайды, ал енді қайсысы бір пайдаланушы репликасына тиесілі екенін түсіну қиын.

LLM бар сценарийлерде бұл мәселе одан да айқын. Жауап көбіне бөлшектеп құралады: модель іздеуден фрагменттер алды, кейін CRM шақырды, таймауттан соң резервтік жолға өтті. Сізде соңғы мәтін бар, бірақ оған дейінгі бүкіл жол жоқ. Жүйе не айтқанын білесіз, бірақ неге дәл солай айтқанын түсінбейсіз.

Көбіне бәрі қарапайым көрінеді. Қолдау қызметіне шағым түседі: «бот дерек жоқ деді». Қолданба логтарында ішкі құралдан 500 қатесі тұр. Іздеу логтарында нәтиже бос. Модель провайдерінде жауап мүлде сәтті. Ортақ тізбек жоқ кезде команда істің себебін талқылаудың орнына, бұл оқиға қай сұрауға тиесілі екенін анықтай алмай дауласады.

Сондықтан тұтас trace_id әдемі дашборд үшін керек емес. Ол бір пайдаланушы сұрауын жол бойындағы барлық қадаммен байланыстыру үшін қажет: жүйеге кіру, іздеу, құралдарды шақыру, модель жауабы және интерфейстегі хабарлама. Сонда сұраудың қай жерде бұзылғаны, жүйенің қай жерде резервтік сценарийге ауысқаны және пайдаланушы нақты нені көргені анық болады.

Бір идентификатормен нені байланыстыру керек

Бір trace_id тек HTTP логта емес, сұраудың бүкіл жолында жүруі керек. Тек модельдің соңғы жауабының өзі аса пайдалы емес. Жүйе неге қате жібергенін, баяулағанын немесе бос нәтиже қайтарғанын түсіну үшін жауапқа әсер еткен әр қадамға ортақ із керек.

Алдымен кіріс сұраудан бастаңыз. Мұнда әдетте HTTP-әдіс, маршрут, пайдаланушы немесе сервис, басталу уақыты, қолданба нұсқасы және сценарийдің қысқа белгісі керек: чат, іздеу, қысқаша мазмұндау, қолдау. Егер trace_id кіріске бірден қойылса, кейін қандай сұрау оқиғалар тізбегін іске қосқанын болжаудың қажеті болмайды.

Келесі қадам — модель шақыруы. Мұнда trace_id-ды ішкі request_id-мен және провайдердегі жауап идентификаторымен байланыстыру пайдалы. Әйтпесе күмәнді жауапта интерфейстегі мәтінді көресіз, бірақ шлюздегі, модель провайдеріндегі немесе өз retry кезегіңіздегі нақты шақыруды таба алмайсыз.

Бөлек қабат — білім базасындағы іздеу. Ерекше жауап көбіне модельдің өзінен емес, контекстке қандай құжаттардың түскенінен шығады. Сондықтан бір trace_id іздеу сұрауын, оның нормаланған түрін, document_id тізімін, индекс нұсқасын, таңдалған фрагменттер санын және бос нәтиже не төмен score фактісін байланыстыруы керек.

Сол қағида құралдарға да жүреді. Егер агент CRM, тариф калькуляторы, ішкі API немесе SQL-функцияны шақырса, trace_id сол шақыру жазбасына, аргументтерге, нәтижеге және орындау уақытына түсуі керек. Әйтпесе модель «қателесті» деген әсер қалады, ал шын мәнінде құрал ескі дерек қайтарған немесе бос параметр алған болуы мүмкін.

Қолданба қателерін де бөлек сақтауға болмайды. Таймауттар, retry, пайдаланушының сұрауды тоқтатуы, rate limit-тен асу, JSON-парсердің құлауы, модельге жіберер алдында PII-ды маскировкалау — мұның бәрі бір инциденттің бөлігі. Осы оқиғалар бір trace_id арқылы байланысса, разбор бірнеше минутқа ғана созылады: қандай сұрау келгені, іздеудің не тапқаны, қай құралдың қате істегені және провайдердің қандай жауап идентификаторын қайтарғаны көрінеді.

Бір сұрау жүйе арқылы қалай өтеді

Пайдаланушы чатқа, қолдау формасына немесе ішкі кабинетке сұрақ жазады. Жүйе үшін бұл — бір оқиғалар тізбегінің бастауы, сондықтан оны ең алғашқы кіру нүктесінде бірден белгілеу дұрыс.

Сервис trace_id-ды іздеуден, модель шақырудан және кез келген ережелерді тексеруден бұрын жасайды. Егер оны кейін құрсаңыз, оқиғалардың бір бөлігі басқа жазбалардан байланыссыз кетіп қалады. Сонда инцидент бөлшекке айналады: модельге сұрау бөлек, іздеу бөлек, құрал қатесі бөлек көрінеді.

Одан кейін қолданба сол trace_id-ды сұрау контекстіне салып, оны бүкіл маршрут бойымен өткізеді. Егер сізде API шлюзі, оркестратор, білім базасындағы іздеу, құжаттарды ранжирлеу, SQL, CRM немесе billing шақырулары болса, әр қадам осы бір идентификаторды алуы керек. OpenTelemetry-де бұл әдетте бір трасса және оған бағынған спандар болады, бірақ trace_id барлық жерде бірдей болса, қарапайым JSON логтарының өзі де көп көмектеседі.

Әдеттегі жол мынадай болады:

• интерфейс пайдаланушы сұрауын қабылдайды;
• backend trace_id жасайды да, кіріс логын жазады;
• іздеу мен құралдар сол идентификаторды алады;
• модель жауап құрастырады, ал қолданба соңғы статусын жазады.

Қарапайым жағдайды елестетіңіз. Клиент: неге төлем өтпеді? — деп жазады. Сервис кірісте trace_id жасайды. Содан кейін іздеу модулі қайтару ережелерін базаға қарап тексереді, ранжирлеу екі құжат таңдайды, құрал төлем жүйесінен транзакция статусын сұрайды, ал LLM операторға немесе клиентке арналған жауапты құрастырады. Егер төлем сервисі таймаут қайтарса, сіз оны осы бір тізбекте — промптпен, табылған құжаттармен және модельдің соңғы мәтінімен қатар көресіз.

Соңғы лог тарихты жабады. Онда әдетте trace_id, сұраудың нәтижесі, жауап коды, модель, өңдеу уақыты, токен саны және болса, ақау себебі болады. Осыдан кейін разбор бес түрлі экран бойынша емес, бір оқиғалар сызығы бойынша жүреді.

Егер команда сұрауларды AI Router сияқты ортақ шлюз арқылы жіберсе, логика өзгермейді. Сол trace_id api.airouter.kz-қа жасалған шақыруға дейін жетіп, кейін қолданба, іздеу және құрал логтарына қайта оралуы керек. Әйтпесе тізбек API шекарасында үзіледі.

trace_id-ды қадам-қадаммен қалай енгізуге болады

Тұтас trace_id-ды лог деңгейінде емес, ең алғашқы кіріс нүктесінде енгізген дұрыс. Егер адам UI-де батырманы басса, идентификаторды сонда жасаңыз. Егер сұрау бірден API-ге келсе, оны gateway-де немесе бірінші backend-сервисте жасаңыз. Одан кейін бір ғана trace_id бүкіл жолмен жүруі тиіс: оркестратор, модель шақыруы, іздеу, tool calls және қолданба логтары арқылы.

Әдетте мына рет жеткілікті:

1. Сұраудың алғашқы кірісінде trace_id жасау.
2. Оны қолданба ішіндегі request context-ке салу.
3. Әр ішкі және сыртқы шақыруда оны headers арқылы өткізу.
4. Оны user_id, session_id және request path-пен бірге құрылымдалған логтарға жазу.
5. Әр қадам үшін жеке span_id жасау, сонда тек тізбек емес, ақау орны да көрінеді.

Trace_id мына сұраққа жауап береді: бұл бір сұрау ма, жоқ па. Span_id басқа сұраққа жауап береді: тізбектің қай қадамында бәрі бұзылды. Сондықтан білім базасындағы іздеу, CRM шақыруы, модель сұрауы және сыртқы API-ге жүгіну ортақ trace_id-қа, бірақ әртүрлі span_id-қа ие болуы керек.

Егер сізде OpenTelemetry already бар болса, идентификатордың екінші форматын ойлап таппаңыз. Бұл жиі жіберілетін қате. Қазірдің өзінде traceparent ішінде бар trace_id-ды алыңыз да, оны логтарға сол күйі жазыңыз. Әйтпесе түнгі инцидент кезінде ешкім қолмен біріктіргісі келмейтін екіге ұқсас тізбек аласыз.

Жеке жағдай — retry. Егер жүйе таймаут немесе 429 себебімен бір сұрауды қайта жіберсе, trace_id-ды өзгертпеңіз. Бұл бәрібір бір пайдаланушы сұрауы. Жаңа span_id немесе бұл қайталама әрекет екенін көрсететін retry_count жеткілікті.

Тағы бір пайдалы ереже — барлық сервиске ортақ headers жиыны. Бұл, әсіресе, LLM сұрауларын OpenAI-үйлесімді шлюз арқылы жіберіп, трассировка үшін бөлек схема ойлап таппай-ақ қазіргі SDK мен кодты сақтағыңыз келгенде ыңғайлы. Онда инцидент солдан оңға қарай оқылады: UI-ге кіру, іздеу, модель шақыруы, провайдер жауабы, қолдау логтарына жазба.

Іске қоспас бұрын үш нәрсені тексеріңіз:

• кез келген логты trace_id бойынша табуға болады;
• кез келген сыртқы шақыруда сол бірдей trace_id headers ішінде бар;
• retry себепсіз жаңа trace_id жасамайды.

Егер бұл ереже бірінші күннен орындалса, ақауларды талдау жарты күн емес, бірнеше минут алады.

Әр логқа қандай өрістерді жазу керек

Бір ғана trace_id бір сұрауға қатысты барлық оқиғаларда болуы тиіс: кіріс HTTP шақыруында, модельге сұрауда, іздеуде, құралдарда және пайдаланушыға жауапта. Оның қасына span_id жазыңыз, сонда тізбектің өзін ғана емес, оның ішіндегі жеке қадамды да көресіз.

Егер клиент көп болып, сессиялар ұзақ болса, бұл жеткіліксіз. session_id, tenant_id және қауіпсіз user_id хэшын қосыңыз. Шынайы user_id-ды логта сақтамаған дұрыс: хэш бір пайдаланушыға қатысты оқиғаларды байланыстырып, талдауға артық жеке дерек әкелмейді.

Модель шақыруы үшін көбіне бірдей өрістер керек болады: model, provider, latency_ms, кіріс және шығыс токен шығыны, провайдердің request_id-ы және prompt_version. Осы жинақ бірден қарапайым сұраққа жауап береді: не болды және қай жерде болды.

Егер сұрау шлюз арқылы түрлі провайдерлерге жіберілсе, provider мен request_id іздеуді бірден тарылтады. Сіз желіге, лимитке, нақты модельге немесе промпттың қате нұсқасына тірелдіңіз бе — болжаудың қажеті болмайды.

Құралдар мен іздеу үшін сол trace_id-пен, бірақ өз өрістерімен бөлек оқиғалар жазыңыз. Әдетте tool_name, status, error_code, retry_count және өз кідірісі жеткілікті. Егер құрал іздеуге жүгінсе, табылған құжаттар санын, дереккөзді және индекс сұрауының қысқа идентификаторын қосқан пайдалы. Сонда модельдің өзі қателесті ме, әлде бос контекст алды ма — көрінеді.

Status қысқа әрі түсінікті болғаны жақсы: ok, timeout, rate_limited, validation_error, provider_error. Командалар логтарда қате кодының орнына еркін мәтін жазса, разбор шашырап кетеді. Бір инженер 429 іздейді, екіншісі too many requests, үшіншісі quota exceeded, ал бұл — бір ғана жағдай.

Кэшті де ұмытпаңыз. cache_hit немесе cache_status өрісі кідіріс пен құндағы түсініксіз айырманы жиі түсіндіреді. Бір жауап 300 мс, ал екіншісі 4 секунд болса, себеп көбіне біріншісі prompt cache-ке түсті де, екіншісі түспеді дегенге саяды.

Жақсы жазба шешім қабылдау үшін он жол оқу қажет етпейтіндей болуы тиіс. Мысалы: tenant_id=bank-a, trace_id=abc123, model=gpt-4.1, provider=openai, tool_name=crm_lookup, status=timeout, retry_count=2, latency_ms=1810, prompt_version=v17, cache_hit=false. Осындай жолдан-ақ бірінші қайда қарау керегі анық.

Егер өріс инцидент кезінде шешім қабылдауға көмектеспесе, оны әр логқа тықпалаудың қажеті жоқ. Бірақ оқиғаларды байланыстыратын, сұрау маршрутын, құнын және қатені сипаттайтын өрістер әрдайым болуы тиіс. Дәл солар разборды болжамдар жиынтығы емес, біртұтас көрініс етеді.

Іздеу мен құралдарды қалай байланыстыруға болады

Мәселе көбіне модельдің бір жауабында емес, қадамдардың түйіскен жерінде жасырынып тұрады. Модель іздеу сұрады, іздеу дұрыс емес құжаттарды қайтарды, кейін құрал сыртқы жүйеге ескі параметрмен барды — ал логта бұлар үш бөлек, байланыссыз оқиға болып көрінеді. Бір trace_id оларды бір тізбекке жинайды.

Retrieval кезінде тек шақыру фактісін емес, жауапқа шынымен әсер еткен нәрсені де жазыңыз. Көбіне бастапқы сұрау, top_k мәні, document_id тізімі және орындалу уақыты жеткілікті. Осы арқылы модель дұрыс құжаттарға сүйенді ме, әлде іздеу басқа жаққа кетті ме — тез түсінесіз.

Егер іздеу нәтижесі кэштен келсе, оны анық белгілеңіз. Әйтпесе команда жарты күн индекс ішіндегі ақауды іздейді, ал жүйе тек ескі таңдауды қайтарған болып шығады. Мұнда cache_hit көп уақыт үнемдейді.

Құралдарда нені сақтау керек

Әр құрал шақыруында сол trace_id және өз span_id-ы болуы керек. Логқа кіріс параметрлері мен жұмыс нәтижесін жазған дұрыс, бірақ артық жеке дерексіз. Егер құрал телефон нөмірі, ЖСН немесе мекенжай алса, жазар алдында оларды жасырыңыз. Талдау үшін сұрау құрылымы, статус, қате коды және қысқа нәтиже көбіне жеткілікті.

Құрал үшін ең төменгі жинақ мынадай:

• құрал атауы;
• тазартылған енгізу;
• орындалу статусы;
• нәтиже немесе қате коды;
• latency.

Сыртқы API-лерді бөлек белгілеңіз. Осындай әр шығу үшін жеке дочерний спан жасаңыз, тіпті шақыру біреу-ақ болса да және қарапайым көрінсе де. Сонда кідіріс қай жерде өскені көрінеді: модельде, іздеуде, CRM-де, төлем сервисінде немесе өз кодыңызда.

trace_id жиі қай жерде жоғалады

Тізбек көбіне кезектер мен фондық тапсырмаларда үзіледі. LLM бар қолданба жауапты толықтыру үшін тапсырма қояды, worker оны орындайды, бірақ payload-қа trace_id берілмейді. Сол сәттен бастап инцидентті жинау мүмкін болмай қалады.

Үш жерді тексеріңіз:

• trace_id кезек payload-ына түседі;
• worker тапсырма басталғанда оны жаңа спанға көтереді;
• фондық тапсырманың нәтижесі сол trace_id-мен логқа жазылады.

Қарапайым мысал: қолдау боты нұсқаулық іздейді, содан кейін жеткізу сервисін шақырады, сосын клиентке жауап жібереді. Егер іздеу document_id 184 пен 221-ді қайтарса, жеткізу сервисі 504 берсе, ал retrieval кэштен келсе — сіз бүкіл тізбекті бірден көресіз. Ортақ идентификаторсыз бұл жай ғана үш бөлек жазба болып қалады.

Қолдау қызметіндегі ақауды талдау мысалы

Клиент чатқа: «Қосылуға берген өтінімім қайда?» — деп жазады. Сырттай бұл кәдімгі сұрау, бірақ жауап екі ақаудың әсерінен дұрыс жаққа кетпей қалды. Іздеу ескі карточканы алып келді, ал CRM нақты статусын қайтаруға үлгермеді.

Ортақ идентификаторсыз команда тек бөлшектерді көрер еді: чаттағы сұрақ мәтіні, CRM логындағы 504 және дайын модель жауабы. Бір trace_id арқылы сурет бір минутта жиналады.

Нақты разборда тізбек былай көрінді:

• 10:14:03 — чат клиент сұрауын қабылдап, бүкіл өңдеу үшін trace_id жасады;
• 10:14:04 — іздеу сервисі телефон нөмірі бойынша карточка тапты, бірақ екі ай бұрынғы жазбаны таңдады;
• 10:14:05 — оркестратор CRM-ге жаңарған статус үшін сұрау жіберді, бірақ таймауттан 504 алды;
• 10:14:06 — құралдар қабаты қате қайтарды, ал модель контекстіне тек ескі карточка деректері түсті;
• 10:14:08 — модель клиентке өтінім «жауап күтіп тұр» деп жауап берді, ал шын мәнінде ол монтажға беріліп қойған еді.

Мұндай ақау көбіне «модель ойдан шығарды» сияқты көрінеді. Негізінде модель өзіне не берілсе, соны жинап жауап құрастырды. Егер логта іздеу, CRM шақыруы және соңғы жауап арасында байланыс жоқ болса, команда қате жерді жөндей бастайды: промптты, температураны немесе модельді. Бұл — уақытты босқа кетіру.

Бір trace_id оқиғалардың ретін көрсетіп, шешім қабылдауға сүйеніш болады. Журналдан қателік мәтін генерациясынан басталмағаны көрінеді: іздеу ескі жазбаны өткізіп жіберді, ал CRM тым қысқа таймаутқа сыймады. Соның нәтижесінде модель толық емес контекст алып, ескі деректерге сүйеніп жауапты толықтырды.

Разбордан кейін команда үш нәрсені өзгертті. Алдымен CRM таймаутын шынайы деңгейге дейін көтерді және 5xx үшін бір retry қосты. Сосын іздеуге жаңалық сүзгісін енгізді: ескі карточкалар енді негізгі контекстке белгісіз кірмейді. Соңында модельге ереже қосты: егер статус көзі қолжетімсіз болса, статусты қазір растай алмайтынын ашық айту керек, архивтік жазбаға сүйеніп жауап бермеу керек.

Нәтижені тексеру оңай. Егер ұқсас инцидент қайталанса, trace_id тағы да бүкіл тізбекті көрсетеді: клиент сұрауы, табылған құжаттар, құрал шақырулары, CRM қателері және чатқа кеткен мәтін. Разборға жарты күн емес, 10-15 минут кетеді.

Жиі жіберілетін қателер

Ең жиі мәселе қарапайым: команда трассировка бар деп ойлайды, өйткені trace_id логта анда-санда көрінеді. Шын мәнінде ол тек бір жерде ғана өмір сүреді де, сервис аралық бірінші ауысуда үзіліп қалады. Сонда разбор қайтадан уақыт, пайдаланушы және жорамалдар бойынша іздеуге тіреледі.

Тұтас trace_id-пен олай болмайды. Бірдей идентификатор кіріс HTTP сұрауынан, оркестратордан, модель шақыруынан, іздеуден, құралдардан, кезектен және фондық тапсырмадан өтуі тиіс. Егер тізбек кез келген қадамда үзіліп қалса, бүкіл маршрутты енді көрмейсіз.

Тізбек қай жерде үзіледі

Бірінші қате — әр микросервис өз trace_id-ын жасайды. Жергілікті деңгейде бұл ыңғайлы, бірақ тергеу үшін пайдасыз. Соның нәтижесінде бір сұрауға арналған бес «дұрыс» идентификатор шығады, бірақ олардың ешқайсысы бүкіл тарихты байланыстырмайды.

Екінші қате — trace_id тек API-шлюздің access logs-ына жазылады. Онда сұрау келгені мен кеткені көрінеді, бірақ оркестратор қандай промпт құрастырғаны, retriever қайтарған бос нәтиже қандай болғаны және қай құрал қате бергені көрінбейді.

Үшінші қате — идентификатор кезектерде, webhook-тарда және фондық тапсырмаларда жоғалады. Бұл ең жиі проблемалық аймақ: синхронды бөлік әлі де байланысқан сияқты көрінеді, ал асинхронды өңдеуге кеткеннің бәрі жалпы көріністен түсіп қалады.

Егер сіз модельдер үшін ортақ шлюз қолдансаңыз да, бұл мәселені өзі шешпейді. Шлюз модель шақыруларын бір жерге жинауға көмектеседі, бірақ кезек, CRM-webhook және постөңдеудегі worker бәрібір сол бір trace_id-ды алып, өзінде жазуы керек.

Кейін разборға не кедергі болады

Тағы бір қате — құралдың шығуын промпт нұсқасы, шаблон немесе маршрутсыз сақтау. Сіз модельдің біртүрлі жауабын көресіз, бірақ не өзгергенін түсіне алмайсыз: іздеу ме, промпт па, құралдар жиыны ма, әлде модель таңдауы ма.

Соңғы қателік — логқа тұрақты пайдаланушы немесе сессия идентификаторының орнына жеке деректерді жазу. Бұл қосымша қауіп тудырады да, диагностикаға мардымсыз көмектеседі. user_id, session_id, conversation_id сақтап, оларды trace_id-пен байланыстыру әлдеқайда пайдалы. Сонда OpenTelemetry-дегі және қарапайым логтардағы оқиғаларды корреляциялау сезімтал деректерді қолмен тазартусыз жұмыс істейді.

Қысқасы, қате көбіне біреу-ақ: команда сұраудың өзін емес, жүйенің жеке бөлшектерін трассалайды. LLM үшін бұл жеткіліксіз.

Іске қоспас бұрын жылдам тексеру

Релизге дейін қағаздағы схеманы емес, бір тірі сценарийді тексеріңіз. Іздеу, модель және кемінде бір құралдан өтетін сұрауды алыңыз. Егер тұтас trace_id дұрыс бапталса, бүкіл тізбек бірнеше минут ішінде, еш жорамалыз жиналады.

Тест қарапайым: пайдаланушы сұрақ қояды, жүйе іздеуге барады, кейін модель құрал шақырады, содан соң қадамдардың біреуі қате алады немесе retry-ға түседі. Осындай прогон сіздің қай жерде байланыс үзіліп жатқанын тез көрсетеді.

Не сәйкес келуі тиіс:

• бір пайдаланушы сұрауы бір trace_id алады және соңғы жауапқа дейін өзгермейді;
• іздеу, модель, құрал және қолданба логтары уақыт бойынша түсінікті ретпен жүреді;
• retry жаңа спан немесе attempt_id жасайды, бірақ бастапқы trace_id-ды сақтайды;
• 5xx қатесі бірден байланысты промптты, құрал атауын және модель провайдерін ашады;
• кезекші инженер инцидентті бір идентификатор бойынша, бірнеше жүйе аралап іздемей-ақ жинай алады.

Мұны нақты мысалмен тексеріңіз. Айталық, қолдау чаты база ішінен тапсырысты іздейді, кейін жеткізу статусына арналған құралды шақырады, ал модельге сұрау сыртқы провайдер арқылы кетеді. Егер құрал қадамында 500 келсе, сіз access logs-та, іздеу логтарында, құрал шақыру жазбасында және LLM-шлюз оқиғасында бірдей trace_id-ды көруіңіз керек.

Ретрайларға бөлек назар аударыңыз. Жиі қате өте қарапайым: бірінші әрекет бір идентификатор жазады, екіншісі басқа идентификатор жазады да, тарих бөлшектерге бөлінеді. Сонда разбор қайтадан уақыт бойынша салыстыруға айналады, ал бұл ұзақ әрі тітіркендіргіш.

Егер тесттен кейін инженер әлі де модельге қандай промпт кеткенін, қандай құрал шақырылғанын және бәрі қай провайдерде сынғанын сұрап жүрсе, онда іске қосуға әлі ерте. Алдымен логтарды бір trace_id шынымен бүкіл тізбекпен алып өтетін деңгейге жеткізіңіз.

Әрі қарай не істеу керек

Тұтас trace_id бірінші күннен-ақ үлкен қайта құруды талап етпейді. Бір ғана идентификатор форматынан және міндетті өрістердің қысқа жиынтығынан бастаңыз. Әдетте request_id, user_id немесе session_id, модель атауы, құрал атауы, статус, кідіріс, токен шығыны және қате коды жеткілікті. Егер әр сервис өз жиынын жазса, разбор қайтадан бөлшектерге ыдырайды.

Сосын бір нақты сценарийді алып, оны толық өткізіңіз. Қолдау бөліміндегі әдеттегі диалог та жарайды: пайдаланушы UI-де сұрақ жазады, қолданба құжаттарды іздейді, ішкі құралды шақырады, модельге сұрау жібереді және жауапты сақтайды. Мақсат қарапайым: бір trace_id арқылы сұраудың жолын экраннан ішкі жүйеге дейін тез жинау.

Ең аз жоспар мынадай:

• барлық сервис үшін trace_id форматын және міндетті өрістер тізімін келісу;
• жеке қадамдар емес, бір жұмыс сценарийін тұтастай тексеру;
• trace_id бос, кесілген немесе жолда өзгеретін сұрауларға алерт қосу;
• қолданба логтарын, трассировканы, іздеу оқиғаларын және құрал шақыруларын бір тізбекке біріктіру.

Сыртқы LLM-шлюз шекарасын бөлек тексеріңіз. Егер сіз AI Router арқылы жұмыс істесеңіз, trace_id-ды api.airouter.kz-қа сұрауда қалай беру және кейін аудит логындағы жазбаны қолданба логымен қалай сәйкестендіру керегін алдын ала келісіп алған жөн. Бұл әсіресе команда бір OpenAI-үйлесімді endpoint арқылы бірнеше модель мен провайдерді қолданса және сыртқы шақыруда тізбекті жоғалтқысы келмесе өте пайдалы.

Соңғы тексеру — ең практикалықсы. Кез келген жаңа сұрауды ашыңыз, оның trace_id-ын алыңыз да, бес минут ішінде үш сұраққа жауап беріп көріңіз: пайдаланушы не сұрады, қандай құжаттар немесе құралдар қатысты, ақау дәл қай жерде болды. Егер команда мұны тез істей алмаса, жаңа өрістер қоспаңыз. Алдымен бар өрістердің жоғалмай, соңына дейін жетуін қамтамасыз етіңіз.