پرش به مطلب اصلی

لاگ درخواست‌ها

«لاگ درخواست‌ها» نقطه شروع عیب‌یابی در گدارAI است. در این صفحه می‌توانید درخواست‌های عبوری از درگاه را به‌ترتیب زمان ببینید، فیلتر کنید و برای هر درخواست بفهمید چه مدلی استفاده شده، چه هزینه‌ای ثبت شده، چه مقدار توکن مصرف شده و مسیر با چه وضعیتی تمام شده است.

از این صفحه وقتی استفاده کنید که یک کاربر پاسخ غیرمنتظره گرفته، درخواست کند شده، هزینه بالا رفته، کش عمل نکرده یا یک خطای مدل/ارائه‌دهنده را باید سریع بررسی کنید.

اطلاع

لاگ درخواست‌ها روی رفتار خود گدارAI و درخواست‌های مدل تمرکز دارد. اگر می‌خواهید مراحل داخلی یک درخواست را ببینید، از ردیابی درخواست‌ها استفاده کنید؛ اگر دنبال روند کلی هستید، متریک‌های مدل مناسب‌تر است.

چه چیزی در لاگ دیده می‌شود؟

هر لاگ می‌تواند این داده‌ها را داشته باشد:

دادهکاربرد
شناسه لاگ، شناسه درخواست و شناسه ردیابی درخواستپیگیری یک درخواست در لاگ، ردیابی و متریک.
زمان، اندپوینت، مدل، مدل مجازی و ارائه‌دهندهفهمیدن مسیر واقعی درخواست.
کد وضعیت و نوع خطاتشخیص خطای درگاه، ارائه‌دهنده یا سیاست اجرایی.
تاخیر، توکن ورودی، توکن خروجی و هزینهتحلیل عملکرد و هزینه.
وضعیت کش، تلاش دوباره، جایگزینی و توازن باربررسی اثر سیاست‌های عملیاتی روی همان درخواست.
حالت محتوا و visibility محتوافهمیدن اینکه payload قابل مشاهده است یا به دلیل مجوز/سیاست پنهان شده است.

فیلترهای کاربردی

در فهرست لاگ‌ها می‌توانید بازه زمانی و فیلترهای عملیاتی را تنظیم کنید. فیلترهای رایج عبارت‌اند از:

  • مدل، مدل مجازی، ارائه‌دهنده و اندپوینت.
  • کد وضعیت، نوع خطا، وضعیت کش، fallback و توازن بار.
  • شناسه لاگ، Request ID و Trace ID.
  • بازیگر، تیم، واحد سازمانی و نوع بازیگر.
  • حداقل یا حداکثر تاخیر، توکن و هزینه.
نکته

برای شروع عیب‌یابی، بازه زمانی را کوچک نگه دارید و اول با Request ID یا Trace ID جست‌وجو کنید. اگر شناسه ندارید، از مدل، ارائه‌دهنده، کد وضعیت و بازه تاخیر کمک بگیرید.

خواندن کارت‌ها و نمودارها

بالای صفحه چند شاخص سریع نمایش داده می‌شود؛ مثل تعداد درخواست‌ها، نرخ خطا، تاخیر P95، هزینه، نرخ پاسخ از کش و retry. این شاخص‌ها برای تشخیص جهش‌های سریع مفیدند.

نمودارهای ترافیک، تاخیر/هزینه، تفکیک ارائه‌دهندگان و Cache Hit / Miss به شما کمک می‌کنند ببینید مشکل فقط یک درخواست بوده یا الگوی بزرگ‌تری در بازه انتخاب‌شده وجود دارد.

بازکردن جزئیات لاگ

وقتی یک لاگ را باز می‌کنید، معمولاً این بخش‌ها مهم‌اند:

  • خلاصه درخواست: وضعیت، ارائه‌دهنده، مدل، مسیر، تاخیر، توکن، هزینه و Trace.
  • محتوای درخواست و پاسخ، اگر سیاست ثبت و مجوز شما اجازه دهد.
  • فراداده، actor و scope برای فهمیدن اینکه درخواست از کدام کاربر، تیم یا حساب مجازی آمده است.
  • لینک به ردیابی درخواست، اگر trace_id موجود باشد.
  • پیش‌نویس بازپخش، اگر مسیر و سطح دسترسی پشتیبانی کند.
هشدار

اگر پیام «محتوا به‌خاطر permission یا سیاست logging پنهان است» می‌بینید، این رفتار عمدی است. برای دیدن payload باید هم مجوز خواندن محتوا داشته باشید و هم حالت ثبت لاگ اجازه ذخیره محتوا را داده باشد.

حالت‌های ثبت لاگ درخواست

«تنظیمات لاگ درخواست» مشخص می‌کند چه مقدار از payload در لاگ ذخیره شود:

حالت ثبتمقدار فنیرفتار
عدم ثبتnoneمحتوای درخواست و پاسخ ذخیره نمی‌شود و فقط حداقل شمارنده‌های عملیاتی حفظ می‌شود.
فقط فرادادهmetadata-onlyفراداده، نتیجه مسیریابی، تاخیر، توکن و هزینه بدون payload خام ذخیره می‌شود. مقدار پیش‌فرض در نبود تنظیم اختصاصی است.
محتوای حذف‌حساس‌شدهredacted-contentنمونه payload پس از حذف داده حساس و با سقف حجمی برای عیب‌یابی ذخیره می‌شود.
محتوای کاملfull-contentpayload درخواست و پاسخ تا سقف تعریف‌شده ذخیره می‌شود.

برای بیشتر محیط‌های عملیاتی، «فقط فراداده» یا «محتوای حذف‌حساس‌شده» نقطه شروع امن‌تری است. «محتوای کامل» را فقط وقتی فعال کنید که نیاز عیب‌یابی و سیاست داخلی نگهداری داده روشن است.

پیش‌نویس بازپخش

در بعضی لاگ‌ها می‌توانید «تکرار این درخواست (آزمایشی)» را باز کنید. این قابلیت یک پیش‌نویس امن برای اجرای دستی می‌سازد؛ هدرهای حساس و اطلاعات محرمانه حذف می‌شوند و هیچ درخواستی به‌صورت خودکار اجرا نمی‌شود.

اگر بازپخش پشتیبانی نشود، معمولاً یکی از این علت‌ها مطرح است:

  • نوع اندپوینت برای بازپخش پشتیبانی نمی‌شود.
  • محتوای درخواست به دلیل مجوز یا سیاست ثبت در دسترس نیست.
  • ساخت پیش‌نویس برای این لاگ ممکن نیست.

عیب‌یابی سریع

نشانهعلت‌های محتملبررسی پیشنهادی
لاگ‌ها خالی‌اندبازه زمانی محدود است، فیلترها سخت‌گیرانه‌اند یا ذخیره‌گاه لاگ فعال نیست.فیلترها را پاک کنید، بازه را بزرگ‌تر کنید و پیام خطای بارگذاری را بررسی کنید.
محتوا پنهان استمجوز خواندن محتوا ندارید یا حالت ثبت payload را ذخیره نکرده است.تنظیمات لاگ درخواست و سطح دسترسی خود را بررسی کنید.
هزینه غیرمنتظره استمدل گران‌تر، خروجی طولانی، نبود کش یا fallback باعث افزایش هزینه شده است.مدل، توکن، وضعیت کش و ردیابی درخواست را کنار هم بررسی کنید.
درخواست کند استارائه‌دهنده کند بوده، retry رخ داده یا مسیر جایگزین فعال شده است.تاخیر، retry، fallback و خط زمانی ردیابی را ببینید.

گام بعدی

پرسش‌های پرتکرار

آیا از روی لاگ می‌توان فهمید کش عمل کرده است؟

بله. ستون‌ها و جزئیات لاگ وضعیت کش، retry، fallback و توازن بار را برای همان درخواست نشان می‌دهند.

چرا بعضی لاگ‌ها payload ندارند؟

یا حالت ثبت لاگ payload را ذخیره نکرده، یا شما مجوز خواندن محتوا ندارید، یا payload به دلیل سقف حجمی/سیاست داده کامل ذخیره نشده است.

آیا بازپخش لاگ درخواست را فوراً دوباره اجرا می‌کند؟

خیر. بازپخش فقط پیش‌نویس امن می‌سازد و اجرای آن باید دستی انجام شود.