با استفاده از ابزار Trace

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید .
اطلاعات

ابزار ردیابی چیست؟

Trace ابزاری برای عیب‌یابی و نظارت بر پروکسی‌های API در حال اجرا بر روی Apigee Edge است. Trace به شما امکان می‌دهد جزئیات هر مرحله از جریان پروکسی API را بررسی کنید.

برای آشنایی با ابزار Trace، این ویدیو را تماشا کنید.

نحوه استفاده از ردیابی

استفاده از Trace ساده است. شما یک جلسه ردیابی را شروع می‌کنید، سپس یک فراخوانی API به پلتفرم Edge انجام می‌دهید و نتایج را می‌خوانید.

  1. همانطور که در زیر توضیح داده شده است، به صفحه پروکسی‌های API دسترسی پیدا کنید.

    لبه

    برای دسترسی به صفحه پروکسی‌های API با استفاده از رابط کاربری Edge:

    1. وارد apigee.com/edge شوید.
    2. در نوار ناوبری سمت چپ، گزینه‌ی Develop > API Proxies را انتخاب کنید.

    لبه کلاسیک (ابر خصوصی)

    برای دسترسی به صفحه پروکسی‌های API با استفاده از رابط کاربری کلاسیک اج:

    1. وارد آدرس http:// ms-ip :9000 شوید، که در آن ms-ip آدرس IP یا نام DNS گره سرور مدیریت است.
    2. در نوار پیمایش بالا، APIها > API Proxies را انتخاب کنید.
  2. یک پروکسی API را از صفحه پروکسی‌های API انتخاب کنید.
  3. مطمئن شوید که API مورد نظر برای ردیابی، مستقر شده است.
  4. برای رفتن به نمای ابزار Trace، روی Trace کلیک کنید.
  5. از منوی کشویی Deployment to Trace برای انتخاب محیط استقرار و نسخه پروکسی که می‌خواهید ردیابی کنید، استفاده کنید.
  6. روی شروع جلسه ردیابی کلیک کنید. وقتی جلسه ردیابی فعال است، پروکسی API جزئیات هر مرحله در خط لوله پردازش را ثبت می‌کند. در حالی که جلسه ردیابی در حال اجرا است، پیام‌ها و داده‌های زمینه‌ای از ترافیک زنده ضبط می‌شوند.

  7. اگر هیچ ترافیک زنده‌ای از طریق پروکسی شما جریان ندارد، کافیست یک درخواست به API ارسال کنید. می‌توانید از هر ابزاری که می‌خواهید برای ارسال درخواست استفاده کنید، مانند curl، Postman یا هر ابزار آشنایی. یا می‌توانید درخواست را مستقیماً از خود ابزار Trace ارسال کنید. فقط URL را وارد کنید و روی ارسال کلیک کنید. توجه: شما فقط می‌توانید یک درخواست GET از ابزار Trace ارسال کنید، اما نمی‌توانید یک درخواست POST ارسال کنید.

    توجه: یک جلسه ردیابی می‌تواند از طریق پروکسی API انتخاب شده، 10 تراکنش درخواست/پاسخ را به ازای هر پردازنده پیام پشتیبانی کند. در Edge cloud، با 2 پردازنده پیام که ترافیک را مدیریت می‌کنند، 20 تراکنش درخواست/پاسخ پشتیبانی می‌شود. اگر به صورت دستی آن را متوقف نکنید، یک جلسه ردیابی پس از 10 دقیقه به طور خودکار متوقف می‌شود.
  8. وقتی تعداد کافی درخواست را ثبت کردید، روی «توقف ردیابی جلسه» کلیک کنید.
  9. فهرستی از تراکنش‌های درخواست/پاسخ ثبت‌شده در منوی سمت چپ نمایش داده می‌شود. برای مشاهده نتایج دقیق، روی هر یک از تراکنش‌ها کلیک کنید.

چگونه یک ردپا را بخوانیم

ابزار ردیابی دو بخش اصلی دارد، نقشه تراکنش و جزئیات فاز:

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

در اینجا یک نمونه نقشه ابزار ردیابی با بخش‌های اصلی پردازش پروکسی با برچسب‌های زیر آمده است:

نقشه تراکنش ابزار ردیابی

شرح نقشه تراکنش

جدول زیر هدف آیکون‌هایی را که در نقشه تراکنش مشاهده خواهید کرد، شرح می‌دهد. این آیکون‌ها هر یک از مراحل پردازش قابل توجه را در طول جریان پروکسی مشخص می‌کنند.

آیکون‌های نقشه تراکنش

برنامه کلاینت که درخواستی را به ProxyEndpoint مربوط به پروکسی API ارسال می‌کند.
دایره‌ها نقاط پایانی انتقالی را در جریان پروکسی مشخص می‌کنند. آن‌ها زمانی که درخواستی از کلاینت می‌رسد، زمانی که درخواست به هدف می‌رود، زمانی که پاسخ از هدف برمی‌گردد و زمانی که پاسخ به کلاینت برمی‌گردد، وجود دارند.

میله‌های بلند، آغاز یک بخش جریان در جریان پروکسی API را نشان می‌دهند. بخش‌های جریان عبارتند از: درخواست ProxyEndpoint، درخواست TargetEndpoint، پاسخ TargetEndpoint و پاسخ ProxyEndpoint. یک بخش شامل PreFlow، جریان‌های شرطی و PostFlow است.

برای اطلاعات بیشتر به پیکربندی جریان‌ها مراجعه کنید.

نشان می‌دهد که اقدامات Analytics در پس‌زمینه رخ داده‌اند.

یک جریان شرطی که به درست ارزیابی می‌شود. برای آشنایی با جریان‌های شرطی، به پیکربندی جریان‌ها مراجعه کنید.

توجه داشته باشید که برخی از شرایط توسط Edge ایجاد می‌شوند. برای مثال، عبارت زیر عبارتی است که Edge برای بررسی وقوع خطا در ProxyEndpoint استفاده می‌کند:

((error.state equals PROXY_REQ_FLOW) or (error.state equals PROXY_RESP_FLOW))

یک جریان شرطی که به نادرست ارزیابی می‌شود. برای مقدمه‌ای بر جریان‌های شرطی، به پیکربندی جریان‌ها مراجعه کنید.

توجه داشته باشید که برخی از شرایط توسط Edge تولید می‌شوند. برای مثال، عبارت زیر عبارتی است که Edge برای بررسی وقوع خطا در TargetEndpoint استفاده می‌کند:

(((error.state equals TARGET_REQ_FLOW) or (error.state equals TARGET_RESP_FLOW)) or ((error.state equals REQ_SENT) or (error.state equals RESP_START)))

سیاست‌ها. هر نوع سیاست یک آیکون منحصر به فرد دارد. این آیکون برای سیاست AssignMessage است. این آیکون‌ها به شما امکان می‌دهند ببینید که سیاست‌ها به ترتیب صحیح کجا اجرا می‌شوند و آیا موفق بوده‌اند یا خیر. می‌توانید روی آیکون یک سیاست کلیک کنید تا نتایج اجرای آن و اینکه آیا مورد انتظار بوده‌اند یا خیر را ببینید. به عنوان مثال، می‌توانید ببینید که آیا پیام به درستی تبدیل شده است یا خیر یا اینکه در حافظه پنهان ذخیره شده است.

اجرای صحیح سیاست‌ها با علامت‌های تیک به وضوح نشان داده می‌شود. در صورت بروز خطا، یک علامت تعجب قرمز روی آیکون نمایش داده می‌شود.

نکته: به راهنمای ابزار یا خط زمانی توجه کنید تا ببینید آیا اجرای هر سیاستی بیشتر از حد انتظار طول می‌کشد یا خیر.

زمانی ظاهر می‌شود که هدف backend یک برنامه Node.js باشد. به بررسی اجمالی Node.js در Apigee Edge مراجعه کنید.
هدفِ بک‌اند که توسط پروکسی API فراخوانی می‌شود.
خط زمانی نشان می‌دهد که زمان پردازش چقدر (برحسب میلی‌ثانیه) طول کشیده است. مقایسه بخش‌های زمانی سپری‌شده به شما کمک می‌کند تا سیاست‌هایی را که بیشترین زمان اجرا را دارند و باعث کند شدن فراخوانی‌های API شما می‌شوند، شناسایی کنید.
اپسیلون نشان دهنده بازه زمانی کوچکتر از میلی ثانیه است.

غیرفعال. وقتی یک سیاست غیرفعال می‌شود، روی آیکون سیاست ظاهر می‌شود. یک سیاست را می‌توان با API عمومی غیرفعال کرد. به مرجع پیکربندی پروکسی API مراجعه کنید.

خطا. وقتی شرط مرحله سیاست ( Policy Step) به نادرست (false) ارزیابی شود، روی آیکون سیاست ظاهر می‌شود، یا هر زمان که یک سیاست RaiseFault اجرا شود، روی آیکون سیاست RaiseFault ظاهر می‌شود.
رد شد. وقتی خط‌مشی اجرا نشده باشد، روی نماد خط‌مشی ظاهر می‌شود زیرا شرط مرحله به نادرست ارزیابی شده است. برای اطلاعات بیشتر به متغیرها و شرایط جریان مراجعه کنید.

درک جزئیات فاز

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

جزئیات فاز توضیحات
نقطه پایانی پروکسی نشان می‌دهد که کدام جریان ProxyEndpoint برای اجرا انتخاب شده است. یک پروکسی API می‌تواند چندین نقطه پایانی پروکسی نامگذاری شده داشته باشد.
متغیرها

متغیرهای جریانی را که توسط یک سیاست خوانده شده و مقداری به آنها اختصاص داده شده است، فهرست می‌کند. همچنین به مدیریت وضعیت پروکسی با متغیرهای جریان مراجعه کنید.

نکته :

  • علامت مساوی (=) نشان دهنده مقداری است که به متغیر اختصاص داده شده است.
  • علامت مساوی (≠) که خط خورده است نشان می‌دهد که نمی‌توان به متغیر مقداری اختصاص داد زیرا فقط خواندنی است یا خطایی در اجرای سیاست رخ داده است.
  • یک فیلد خالی نشان می‌دهد که مقدار متغیر خوانده شده است.
سربرگ‌های درخواست هدرهای درخواست HTTP را فهرست می‌کند.
درخواست محتوا بدنه درخواست HTTP را نشان می‌دهد.
خواص ویژگی‌ها (Properties) وضعیت داخلی پروکسی API را نشان می‌دهند. این ویژگی‌ها به طور پیش‌فرض نمایش داده نمی‌شوند.
نقطه پایانی هدف نشان می‌دهد که کدام TargetEndpoint برای اجرا انتخاب شده است.
هدرهای پاسخ هدرهای پاسخ HTTP را فهرست می‌کند.
محتوای پاسخ بدنه پاسخ HTTP را نشان می‌دهد.
جریان پست کلاینت اطلاعات مربوط به PostClientFlow را نشان می‌دهد که پس از بازگشت درخواست به برنامه کلاینت درخواست‌کننده اجرا می‌شود. فقط سیاست‌های MessageLogging می‌توانند به PostClientFlow متصل شوند. PostClientFlow در حال حاضر عمدتاً برای اندازه‌گیری فاصله زمانی بین مهرهای زمانی شروع و پایان برای پیام پاسخ استفاده می‌شود.

اصلاح ضبط پیام با استفاده از فیلترها

شما می‌توانید با مشخص کردن مقادیر پارامترهای هدر و/یا پرس‌وجو، درخواست‌هایی را که در ابزار Trace نمایش داده می‌شوند، فیلتر کنید. فیلترها به شما این امکان را می‌دهند که تماس‌های خاصی را که ممکن است باعث ایجاد مشکل شوند، هدف قرار دهید. به عنوان مثال، ممکن است لازم باشد درخواست‌هایی را که محتوای خاصی دارند یا درخواست‌هایی که از شرکا یا برنامه‌های خاصی می‌آیند، هدف قرار دهید. می‌توانید موارد زیر را فیلتر کنید:

  • هدرهای HTTP - ردیابی را فقط به تماس‌هایی که حاوی یک هدر خاص هستند محدود کنید. این یک روش خوب برای کمک به شما در عیب‌یابی مشکلات است. می‌توانید یک هدر برای توسعه‌دهنده برنامه خود ارسال کنید و از او بخواهید که آن را در تماسی که باعث ایجاد مشکل می‌شود، لحاظ کند. سپس Apigee Edge فقط تماس‌هایی را با آن هدر خاص ضبط می‌کند تا بتوانید نتایج را بررسی کنید.
  • پارامترهای پرس‌وجو - فقط تماس‌هایی با مقدار مشخصی از یک پارامتر ضبط می‌شوند.

نکاتی که باید در مورد فیلترشکن بدانید

  • پس از مشخص کردن پارامترهای فیلتر در فیلدهای فیلتر، باید جلسه ردیابی خود را مجدداً راه‌اندازی کنید.
  • پارامترهای فیلتر با هم AND می‌شوند. برای تطابق موفقیت‌آمیز، تمام جفت‌های نام/مقدار پرس‌وجو و/یا سرآیند مشخص‌شده باید در درخواست وجود داشته باشند.
  • تطبیق الگو در ابزار فیلترها پشتیبانی نمی‌شود.
  • پارامترها و مقادیر فیلتر به حروف بزرگ و کوچک حساس هستند.

نحوه ایجاد فیلتر ردیابی

  1. اگر یک جلسه ردیابی در حال اجرا است، با کلیک روی «توقف جلسه ردیابی» آن را متوقف کنید.
  2. برای باز کردن فیلد فیلترها، روی فیلترها در گوشه سمت چپ بالای ابزار Trace کلیک کنید.

    در ابزار Trace، برچسب نوار کناری Filters دایره شده است.
  3. در فیلد فیلترها، پارامتر پرس‌وجو و/یا مقادیر هدر مورد نظر برای فیلتر کردن را مشخص کنید. در این مثال، ما دو پارامتر پرس‌وجو را برای فیلتر کردن مشخص می‌کنیم. برای تطابق موفقیت‌آمیز، هر دو پارامتر باید در درخواست وجود داشته باشند.

    در ابزار Trace، در قسمت Filters، در قسمت Query Parameter، دو نام و مقدار نمونه تنظیم شده‌اند.
  4. جلسه ردیابی را شروع کنید.
  5. API های خود را فراخوانی کنید. فقط درخواست‌هایی که شامل تمام هدر(های) مشخص شده و/یا پارامتر(های) پرس و جو هستند، تطابق موفقیت‌آمیزی ایجاد می‌کنند.

در بخش تراکنش‌ها، چهار نتیجه نشان داده می‌شود که با دو پارامتر از پیش تعیین‌شده‌ی جستجو مطابقت دارند.

در مثال بالا، این فراخوانی API در Trace نمایش داده می‌شود:

http://docs-test.apigee.net/cats?name=Penny&breed=Calico

اما این نخواهد شد:

http://docs-test.apigee.net/cats?name=Penny

اشکال‌زدایی با ردیابی

Trace به شما امکان می‌دهد جزئیات داخلی زیادی در مورد یک پروکسی API مشاهده کنید. برای مثال:

  • شما می‌توانید با یک نگاه ببینید که کدام سیاست‌ها به درستی اجرا می‌شوند یا شکست می‌خورند.
  • فرض کنید از طریق یکی از داشبوردهای آنالیتیکس متوجه شده‌اید که یکی از APIهای شما دچار کاهش غیرمعمول عملکرد شده است. اکنون می‌توانید از Trace برای شناسایی محل وقوع گلوگاه استفاده کنید. Trace زمان لازم برای تکمیل هر مرحله پردازش را بر حسب میلی‌ثانیه نشان می‌دهد. اگر متوجه شدید که یک مرحله بیش از حد طول می‌کشد، می‌توانید اقدامات اصلاحی را انجام دهید.
  • با مشاهده جزئیات فاز، می‌توانید هدرهایی را که به backend ارسال می‌شوند بررسی کنید، متغیرهای تنظیم‌شده توسط سیاست‌ها را مشاهده کنید و غیره.
  • با تأیید مسیر پایه، می‌توانید مطمئن شوید که یک سیاست، پیام را به سرور صحیح هدایت می‌کند.

انتخاب گزینه‌های نمایش

گزینه‌های مشاهده برای جلسه ردیابی را انتخاب کنید.

گزینه توضیحات
نمایش سیاست‌های غیرفعال نمایش هرگونه خط‌مشی غیرفعال. یک خط‌مشی می‌تواند با API عمومی غیرفعال شود. به مرجع پیکربندی پروکسی API مراجعه کنید.
نمایش مراحل رد شده هر مرحله‌ای که نادیده گرفته شده است را نشان دهید. مرحله نادیده گرفته شده زمانی رخ می‌دهد که سیاست به دلیل نادرست بودن شرط مرحله اجرا نشده باشد. برای اطلاعات بیشتر به متغیرها و شرایط جریان مراجعه کنید.
نمایش همه اطلاعات جریان نمایش گذارها در یک بخش جریان.
مقایسه خودکار فاز انتخاب شده فاز انتخاب شده را با فاز قبلی مقایسه می‌کند. برای دیدن فقط فاز انتخاب شده، این گزینه را خاموش کنید.
نمایش متغیرها نمایش یا پنهان کردن متغیرهایی که خوانده شده‌اند و/یا مقداری به آنها اختصاص داده شده است.
نمایش املاک ویژگی‌ها (Properties) وضعیت داخلی پروکسی API را نشان می‌دهند. (به طور پیش‌فرض پنهان هستند.)

دانلود نتایج ردیابی

شما می‌توانید یک فایل XML از نتایج خام ردیابی را برای مشاهده و جستجوی آفلاین در یک ویرایشگر متن دانلود کنید. این فایل جزئیات کامل جلسه شنود، شامل محتوای تمام هدرها، متغیرها و سیاست‌ها را نشان می‌دهد.

برای دانلود، روی دانلود جلسه ردیابی کلیک کنید.

نمایش درخواست‌ها به صورت curl

پس از ردیابی یک فراخوانی API که به سرور هدف ارسال شده است، می‌توانید درخواست را به عنوان یک دستور curl مشاهده کنید. این امر به ویژه برای اشکال‌زدایی به چند دلیل مفید است:

  • پروکسی API ممکن است درخواست را تغییر دهد، بنابراین مشاهده اینکه درخواست از پروکسی به سرور هدف چه تفاوتی با درخواست اصلی دارد، مفید است. دستور curl نشان دهنده درخواست تغییر یافته است.
  • برای پیام‌های با حجم بالا، curl به شما امکان می‌دهد هدرهای HTTP و محتوای پیام را در یک مکان واحد مشاهده کنید. (در حال حاضر محدودیتی حدود ۱۰۰۰ کاراکتر وجود دارد. برای راهنمایی در مورد عبور از این محدودیت، به این پست انجمن مراجعه کنید.)

برای امنیت، ویژگی curl هدر HTTP Authorization را می‌پوشاند.

برای مشاهده درخواست‌ها به صورت curl پس از دریافت یک فراخوانی API در Trace، مرحله "درخواست ارسال شده به سرور هدف" را در نمودار Transaction Map انتخاب کنید، سپس روی دکمه Show curl در ستون "درخواست ارسال شده به سرور هدف" در پنجره Phase Details کلیک کنید.

حاشیه‌نویسی‌های تصویر، دکمه‌ی Show Curl و یکی از دایره‌های موجود در نمودار Transaction Map را نشان می‌دهند.

پشتیبانی Apigee از استفاده از Trace

به طور پیش فرض، Apigee Edge به پشتیبانی Apigee اجازه می دهد تا از ابزار Trace در پراکسی های API شما برای ارائه پشتیبانی استفاده کند. شما می توانید این گزینه را در هر زمان غیرفعال کنید. با این حال، غیرفعال کردن این گزینه ممکن است توانایی Apigee Support را برای ارائه پشتیبانی به شما محدود کند.

برای غیرفعال کردن پشتیبانی Apigee از استفاده از ابزار Trace:

  1. به https://apigee.com/edge وارد شوید.
  2. Admin > Privacy & Security را در نوار ناوبری سمت چپ انتخاب کنید.
  3. برای غیرفعال کردن استفاده از ابزار Trace توسط پشتیبانی Apigee، روی دکمه فعال کردن پشتیبانی برای ردیابی Apigee کلیک کنید.