نمای کلی مشاهدهپذیری و پایش
مشاهدهپذیری در گدارAI کمک میکند بعد از اتصال محصولتان به درگاه، رفتار واقعی درخواستها را ببینید: کدام مدل پاسخ داده، چه مقدار توکن مصرف شده، هزینه چقدر بوده، پاسخ از کش آمده یا نه، چه خطایی رخ داده و هر مرحله چقدر زمان برده است.
این دسته برای عیبیابی روزمره، پایش هزینه، بررسی کیفیت مسیرهای مدل و تصمیمگیری عملیاتی طراحی شده است. اگر هنوز اولین درخواست را نفرستادهاید، ابتدا شروع سریع و ارسال درخواست از مسیر درگاه را کامل کنید.
لاگ، ردیابی و متریک سه زاویه متفاوت از یک واقعیتاند. لاگ برای بررسی یک درخواست مشخص، ردیابی برای دیدن مسیر و مراحل اجرا، و متریک برای تحلیل روند و الگوهای تجمیعی استفاده میشود.
از کجا شروع کنید؟
| نیاز شما | صفحه مناسب | نتیجهای که میگیرید |
|---|---|---|
| یک درخواست خاص کند، گران یا ناموفق شده است | لاگ درخواستها | جزئیات درخواست، وضعیت، هزینه، توکن، محتوا و لینک ردیابی را بررسی میکنید. |
| میخواهید مسیر اجرای یک درخواست را مرحلهبهمرحله ببینید | ردیابی درخواستها | تلاشها، خط زمانی آبشاری، خطاها، مصرف و ارتباط با متریکها را میبینید. |
| دنبال روند کلی مصرف، تاخیر، خطا و اثربخشی کش هستید | متریکهای مدل | درخواستها را در بازه زمانی و بر اساس مدل، ارائهدهنده، تیم یا حساب مجازی تحلیل میکنید. |
| باید داده لاگ را در ابزار تحلیلی یا گزارش بیرونی استفاده کنید | خروجی گرفتن از لاگها | خروجی CSV یا JSONL از لاگها میگیرید. |
| چند سرویس دارید و میخواهید درخواست مدل را در کنار بقیه سیستم ببینید | OpenTelemetry برای مشاهدهپذیری | داده گدارAI را با ردیابی و سنجههای سرویسهای خودتان همبسته میکنید. |
ارتباط لاگ، ردیابی و متریک
در یک جریان معمول، هر درخواست از درگاه گدارAI چند شناسه و داده عملیاتی تولید میکند:
request_idبرای دنبالکردن یک درخواست در لاگ و متریک.trace_idبرای بازکردن ردیابی همان درخواست.- دادههای مصرف مثل توکن ورودی، توکن خروجی و هزینه.
- دادههای کیفیت اجرا مثل کد وضعیت، نوع خطا، تاخیر، کش، تلاش دوباره و مسیر جایگزین.
وقتی این دادهها کنار هم باشند، بهجای حدسزدن میتوانید مسیر را مرحلهبهمرحله بررسی کنید. برای مثال، اگر هزینه یک قابلیت ناگهان بالا رفت، از متریکهای مدل بازه و مدل درگیر را پیدا میکنید، از لاگ درخواستها نمونههای واقعی را باز میکنید و در صورت نیاز با ردیابی درخواستها تلاشها و خطاها را دقیقتر میبینید.
پیشنیازهای دسترسی
برای دیدن همه جزئیات، سطح دسترسی کاربر مهم است. گدارAI میان فراداده لاگ، محتوای درخواست/پاسخ، خروجی گرفتن، نماهای ذخیرهشده و بازپخش آزمایشی تفاوت میگذارد.
محتوای درخواست و پاسخ میتواند داده شخصی، محرمانه یا سازمانی داشته باشد. اگر فقط برای پایش هزینه و عملکرد به داده نیاز دارید، حالتهای فرادادهمحور را ترجیح دهید و محتوای کامل را فقط برای مسیرهای واقعاً لازم فعال کنید.
تنظیمات داده و حریم خصوصی
دو تنظیم اصلی روی مقدار داده قابل مشاهده اثر میگذارند:
| تنظیم | مسیر UI | کاربرد |
|---|---|---|
| تنظیمات لاگ درخواست | «تنظیمات لاگ درخواست» | مشخص میکند در لاگها محتوای درخواست و پاسخ ذخیره شود یا فقط فراداده نگه داشته شود. |
| حریم خصوصی ردیابی درخواستها | «حریم خصوصی ردیابی درخواستها» | مشخص میکند payload در ردیابیها ثبت نشود، فقط فراداده ثبت شود، نمونه حذفحساسشده ثبت شود یا محتوای رمزنگاریشده نگهداری شود. |
مقدار پیشفرض در نبود تنظیم اختصاصی، ثبت فراداده است. این انتخاب معمولاً برای شروع امنتر است، چون تاخیر، هزینه، توکن، مدل، ارائهدهنده و وضعیت مسیر را نگه میدارد، اما payload خام را در دسترس قرار نمیدهد.
مسیر پیشنهادی عیبیابی
- در لاگ درخواستها، بازه زمانی و شناسه درخواست یا مدل را فیلتر کنید.
- وضعیت، کد خطا، تاخیر، هزینه، توکن و وضعیت کش یا fallback را بررسی کنید.
- اگر لاگ
trace_idدارد، ردیابی همان درخواست را باز کنید و خط زمانی، تلاشها و خطاها را ببینید. - اگر مشکل تکرارشونده است، در متریکهای مدل همان بازه را بر اساس مدل، ارائهدهنده، تیم یا حساب مجازی تحلیل کنید.
- اگر مسئله بیرون از گدارAI هم ادامه دارد، داده را با OpenTelemetry در سرویسهای خودتان همبسته کنید.
برای رخدادهای پرتکرار، فقط نمونه خطادار را بررسی نکنید. درخواستهای موفق اما کند یا گران هم معمولاً بهترین سرنخ برای بهینهسازی مدل، کش، محدودیت نرخ یا مسیر جایگزین هستند.
پرسشهای پرتکرار
اگر فقط یک درخواست را میخواهم بررسی کنم، از کدام صفحه شروع کنم؟
از لاگ درخواستها شروع کنید. اگر به جزئیات مرحلهای نیاز داشتید، از همان لاگ به ردیابی درخواست بروید.
آیا متریکها جای لاگ را میگیرند؟
خیر. متریکها روند و الگو را نشان میدهند، اما برای دیدن جزئیات یک درخواست خاص باید لاگ یا ردیابی را باز کنید.
چه زمانی OpenTelemetry لازم میشود؟
وقتی چند سرویس، صف، job غیرهمزمان یا ابزار مشاهدهپذیری بیرونی دارید و میخواهید درخواست مدل را در کنار بقیه مسیر محصول ببینید.