Request ID — tizimga kirgan bitta so‘rovni log, trace va xizmatlar bo‘ylab aniqlash uchun beriladigan noyob identifikator. U foydalanuvchi xatosi yoki sekinlikni tekshirishda bir requestga tegishli yozuvlarni topishga yordam beradi. Request ID biznes obyekt identifikatori emas; u bir bajarilish oqimining texnik kuzatuv kalitidir.
Yaratish
Edge proxy yoki birinchi ishonchli servis request ID yaratadi. UUID, ULID yoki yetarlicha tasodifiy boshqa format ishlatilishi mumkin. Global noyoblik foydali, lekin kriptografik secret talab qilinmaydi. Ketma-ket oddiy raqam trafik hajmi va tizim faoliyati haqida ma’lumot ochishi mumkin.
Client yuborgan ID’ni ko‘r-ko‘rona qabul qilish log injection, haddan tashqari uzun label va kolliziya xavfini beradi. Gateway format va uzunlikni tekshiradi yoki o‘z identifikatorini yaratadi. Tashqi client ID’si kerak bo‘lsa client_request_id sifatida alohida saqlanadi. Ichki canonical request ID barcha keyingi xizmatlarga forward qilinadi.
Xizmatlar orasida uzatish
HTTP header, RPC metadata va message envelope request ID’ni olib yuradi. Asinxron xabar yangi processing requestiga ega bo‘lishi mumkin, original oqim bilan correlation ID orqali bog‘lanadi. Bitta kiruvchi request parallel bir nechta downstream chaqiruv qilsa, ularning request ID’si bir xil qolishi yoki child ID olishi mumkin; tracing bu iyerarxiyani span ID bilan aniqroq ifodalaydi.
Header nomi tashkilot bo‘yicha standartlashtiriladi. Reverse proxy bir nom, ilova boshqa nom ishlatsa zanjir uziladi. OpenTelemetry’da trace ID request oqimini bog‘laydi; alohida request ID saqlansa ikkalasi logda birga bo‘ladi. Request ID trace sampling qilinmagan holatda ham minimal qidiruv kaliti bo‘lib xizmat qiladi.
Log va response
Structured log’da request ID alohida maydon sifatida yoziladi, matn ichiga qo‘shilib ketmaydi. Access log, application log va error report bir xil qiymatni oladi. Metric label sifatida request ID ishlatilmaydi, chunki har request uchun yangi label time-series cardinality’sini cheksiz oshiradi.
Server request ID’ni response header va foydalanuvchiga ko‘rsatiladigan xato sahifasida qaytarishi mumkin. Support murojaatida foydalanuvchi shu qiymatni yuboradi. Biroq ID orqali umumiy log endpointidan ma’lumot olishga ruxsat berilmaydi; u autentifikatsiya tokeni emas. Log access tenant va xodim roli bo‘yicha himoyalanadi.
Hayot sikli va xavfsizlik
Request ID log retention muddaticha qidirilishi kerak. Agar loglar turli region yoki tizimda bo‘lsa, indeks formatni saqlaydi. PII’ni ID ichiga kodlash taqiqlanadi; email, user ID yoki IP’dan hash yasash ham qayta bog‘lash xavfini saqlaydi. Tasodifiy opaque qiymat ma’qul.
Duplicate ID aniqlansa barcha yozuvni bir oqim deb noto‘g‘ri birlashtirish mumkin. Generator va qabul qilish qoidasi test qilinadi. Juda uzun yoki control belgili ID log formatini buzmasligi uchun limit va sanitization qo‘llanadi. Security incident’da request ID authentikatsiya, session va audit event bilan server tomonida bog‘lanadi, lekin tashqi javobda maxfiy tafsilot berilmaydi.
Gateway va batch so‘rovlari
Bitta batch request ichida ko‘plab element qayta ishlansa, umumiy request ID bilan birga har element uchun sub-operation ID beriladi. Shunda bitta muvaffaqiyatsiz yozuvni butun batch logidan topish mumkin. Gateway qayta urinish qilsa yangi attempt ID yaratib, original request ID’ni saqlashi mumkin; bu takroriy bajarilishlarni bitta foydalanuvchi amaliga bog‘laydi.
Serverless muhitda platforma execution ID berishi mumkin. U request ID o‘rnini to‘liq bosmaydi, chunki bitta request bir nechta invocationga yoki aksincha batch invocation ko‘plab requestga mos kelishi mumkin. Ikkala qiymat strukturali logda alohida maydon bo‘ladi.
Bog‘liq tushunchalar
Correlation ID, Trace ID, Distributed tracing, Structured logging, HTTP header, Observability, UUID