مرجع معیارهای تجزیه و تحلیل، ابعاد و فیلترها

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

نحو API: tps

تعداد درخواست های موفق API که به جای پاسخ از سرویس هدف، از حافظه پنهان پاسخ استفاده می کنند.

نحو API: sum(cache_hit)

تعداد عناصر موجود در کش L1 (در حافظه) را در هر تراکنش در یک بازه زمانی معین برمی گرداند. به عنوان مثال، اگر max برای دوره یک روز انتخاب کنید و در آن روز بیشترین تعداد عناصر در حافظه پنهان برای یک تراکنش خاص 12 باشد، تعداد آن ها 12 خواهد بود. برای avg ، اگر سه تراکنش در آن زمان وجود داشته باشد. در دوره ای که در حال پرس و جو هستید، و تعداد کش آنها 5، 6 و 7 است، میانگین آن 6 است. کش L1 در مقابل حافظه پنهان پایگاه داده L2 است، همانطور که در کش داخلی توضیح داده شده است.

نحو API: avg(ax_cache_l1_count)

تعداد کل خطاهای خط مشی در بازه زمانی مشخص شده.

خطاهای خط مشی معمولاً با طراحی رخ می دهد. برای مثال، خط‌مشی Verify API Key زمانی که یک کلید API نامعتبر در درخواست ارسال می‌شود، خط‌مشی ایجاد می‌کند و اگر تعداد تماس‌های API از حد تعیین‌شده در خط‌مشی بیشتر شود، خط‌مشی Spike Arrest خطایی ایجاد می‌کند. بنابراین این معیار برای یافتن نقاط مشکل بالقوه در APIهای شما مفید است. برای مثال، معیارهای Policy_error، گروه‌بندی‌شده بر اساس بعد developer_app، ممکن است به شما کمک کند تا کشف کنید که یک کلید API یا نشانه OAuth برای یک برنامه خاص منقضی شده است. یا ممکن است متوجه شوید که یک پروکسی API خاص، خطاهای Spike Arrest زیادی ایجاد می‌کند، که باعث می‌شود متوجه شوید که محدودیت بازداشت پراکسی باعث افزایش ترافیک تعطیلات نمی‌شود.

خطای خط مشی تنها در صورتی در تجزیه و تحلیل ثبت می شود که خطا منجر به شکست پروکسی API شود. به عنوان مثال، اگر ویژگی continueOnError روی true تنظیم شود، پراکسی API به پردازش درخواست ادامه می‌دهد حتی اگر خط‌مشی با شکست مواجه شود. در آن صورت، خطای خط مشی در تجزیه و تحلیل ثبت نمی شود.

بعد نام خط مشی روی خطا (ax_execution_fault_policy_name) برای گروه بندی خطاهای خط مشی بر اساس نام خط مشی مفید است.

شکست هدف (مانند 404 یا 503) به عنوان شکست خط مشی حساب نمی شود. این موارد به عنوان خرابی های پراکسی API (is_error) به حساب می آیند.

نحو API: sum(policy_error)

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

بعد Proxy (apiproxy) برای گروه بندی خرابی های پروکسی API بر اساس پراکسی مفید است.

نحو API: sum(is_error)

مقدار زمانی (متوسط، حداقل یا حداکثر)، بر حسب میلی ثانیه ، که Edge برای پردازش درخواست‌های دریافتی طول می‌کشد. زمان با رسیدن درخواست به Edge شروع می شود و زمانی که Edge درخواست را به سرویس هدف ارسال می کند به پایان می رسد.

با استفاده از ابعاد مختلف، می‌توانید تأخیرهای پردازش درخواست را توسط پروکسی API، برنامه توسعه‌دهنده، منطقه و غیره بررسی کنید.

نحو API: max(request_processing_latency)

اندازه بار درخواستی دریافت شده توسط Edge، بر حسب بایت .

نحو API: avg(request_size)

تعداد کل دفعاتی که یک خط مشی کش پاسخ در بازه زمانی معین اجرا شده است.

از آنجایی که خط مشی Response Cache در دو مکان در یک پراکسی API متصل می شود (یک بار در درخواست و یک بار در پاسخ)، معمولاً دو بار در یک فراخوانی API اجرا می شود. یک کش «get» و یک کش «put» هر کدام به عنوان یک اجرا به حساب می آیند.

با این حال، اگر عنصر <SkipCacheLookup> در خط مشی به درستی (در درخواست) ارزیابی شود، اجرای کش پاسخ 0 است، و اگر عنصر <SkipCachePopulation> در خط مشی به درستی (در پاسخ) ارزیابی شود، 0 است.

در ابزار Trace ، می‌توانید روی نماد Response Cache در یک فراخوانی API اجرا شده کلیک کنید و متغیر جریان responsecache.executed را مشاهده کنید تا ببینید آیا یک کش اجرا شده است یا خیر (مقدار 1).

نحو API: sum(ax_cache_executed)

مقدار زمانی (متوسط، حداقل یا حداکثر)، بر حسب میلی ثانیه ، که Edge برای پردازش پاسخ‌های API طول می‌کشد. زمان زمانی شروع می شود که پراکسی API پاسخ سرویس هدف را دریافت می کند و زمانی پایان می یابد که Apigee پاسخ را به تماس گیرنده اصلی ارسال کند.

با استفاده از ابعاد مختلف، می توانید تأخیرهای پردازش پاسخ را توسط پراکسی API، منطقه و غیره بررسی کنید.

نحو API: min(response_processing_latency)

اندازه بار پاسخ به مشتری، بر حسب بایت .

نحو API: max(response_size)

تعداد کل پاسخ‌های 5xx از سرویس هدف. اینها خطاهای سرویس هدف هستند که توسط Apigee ایجاد نمی شوند.

نحو API: sum(target_error)

مقدار زمان (جمع، میانگین، حداقل یا حداکثر)، بر حسب میلی ثانیه ، برای پاسخگویی سرور مورد نظر به تماس. این معیار به شما می گوید که سرورهای هدف چگونه عمل می کنند. زمان زمانی شروع می شود که Edge یک درخواست را به سرویس هدف ارسال می کند و زمانی که Edge پاسخ را دریافت می کند به پایان می رسد.

توجه داشته باشید که اگر یک تماس API پاسخی را از حافظه پنهان برگرداند (مثلاً با استفاده از خط‌مشی حافظه پنهان پاسخ)، تماس هرگز به سرویس هدف نخواهد رسید و هیچ معیار زمان پاسخ هدف ثبت نمی‌شود.

نحو API: avg(target_response_time)

مقدار زمان (مجموع، میانگین، حداقل یا حداکثر)، بر حسب میلی ثانیه ، از زمانی که Edge درخواستی از مشتری دریافت می کند تا زمانی که Edge پاسخ را برای مشتری ارسال می کند. این زمان شامل سربار شبکه (مانند مدت زمانی است که متعادل کننده های بار و روترها برای انجام کار خود طول می کشد)، تأخیر پردازش درخواست، تأخیر پردازش پاسخ و زمان پاسخ هدف (اگر پاسخ به جای کش از سرویس هدف ارائه شود).

با استفاده از ابعاد مختلف، می‌توانید تأخیرهای پردازش را توسط پروکسی API، برنامه توسعه‌دهنده، منطقه و غیره بررسی کنید.

نحو API: avg(total_response_time)

تعداد کل تماس‌های API پردازش شده توسط Edge در بازه زمانی مشخص شده.

از ابعاد برای گروه‌بندی تعداد ترافیک به روش‌هایی استفاده کنید که برای شما معنادارتر است.

نحو API: sum(message_count)

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

اگر معیارهای بالا برآورده نشدند، مقدار "(تنظیم نشده)" را مشاهده خواهید کرد. همچنین ببینید یک مقدار موجودیت تحلیلی "(تنظیم نشده)" به چه معناست؟ .

کلید حاوی مقدار Response Cache که به آن دسترسی داشتید. برای اطلاعات بیشتر در مورد نحوه ساخت کلید برای حافظه پنهان پاسخ، به سیاست کش پاسخ مراجعه کنید.

در ابزار Trace ، وقتی یک خط‌مشی کش پاسخ را انتخاب می‌کنید که از حافظه پنهان خوانده یا نوشته شده است، می‌توانید این مقدار را در متغیر جریان responsecache.cachekey ببینید.

نام حافظه پنهان حاوی کلیدها/مقدارهای استفاده شده توسط خط مشی Response Cache، با پیشوند orgName__envName__ . به عنوان مثال، اگر org "foo" است، محیط "test" و نام حافظه پنهان "myCache" است، ax_cache_name foo__test__myCache است.

در ابزار Trace ، هنگامی که یک سیاست کش پاسخ را انتخاب می کنید، می توانید این مقدار را در متغیر جریان responsecache.cachename ببینید.

سطح حافظه پنهان (پایگاه داده "L1" در حافظه یا "L2") که کش پاسخ از آن بازیابی شده است. این بعد همچنین "CACHE_MISS" را هنگامی که پاسخ به جای حافظه پنهان از هدف تحویل داده می شود نشان می دهد (و حافظه پنهان پاسخ با پاسخ هدف به روز می شود). یا زمانی که یک کلید کش در درخواست نامعتبر است. اندازه کلیدهای کش به 2 کیلوبایت محدود شده است.

در ابزار Trace ، هنگامی که سیاست پاسخ کش را انتخاب می کنید، می توانید این مقدار را در متغیر جریان responsecache.cachesource مشاهده کنید.

برای اطلاعات بیشتر در مورد سطوح حافظه پنهان، به بخش داخلی کش مراجعه کنید.

کلید مصرف کننده (کلید API) برنامه توسعه دهنده که تماس های API را انجام می دهد، خواه در درخواست به عنوان کلیدهای API ارسال شود یا در نشانه های OAuth موجود باشد.

برای دریافت این بعد، پراکسی‌هایی که تماس‌ها را دریافت می‌کنند باید برای بررسی یک کلید API معتبر یا نشانه OAuth پیکربندی شوند. برنامه‌های توسعه‌دهنده کلیدهای API را دریافت می‌کنند که می‌توان از آن‌ها برای تولید نشانه‌های OAuth استفاده کرد، وقتی برنامه‌ها در Edge ثبت شوند. برای اطلاعات بیشتر، ابتدا به اولین چیزها مراجعه کنید: نحوه تولید داده های تجزیه و تحلیل کامل .

اگر معیارهای بالا برآورده نشدند، مقدار "(تنظیم نشده)" را مشاهده خواهید کرد. همچنین ببینید یک مقدار موجودیت تحلیلی "(تنظیم نشده)" به چه معناست؟ .

برنامه توسعه دهنده ثبت شده در Edge که تماس های API را انجام می دهد.

برای دریافت این بعد، برنامه‌ها باید با یک یا چند محصول API مرتبط شوند که حاوی پراکسی‌های API در حال فراخوانی هستند و پراکسی‌ها باید کلید API یا نشانه OAuth ارسال شده با تماس API را بررسی کنند. کلید یا نشانه برنامه توسعه دهنده را شناسایی می کند. برای اطلاعات بیشتر، ابتدا به اولین چیزها مراجعه کنید: نحوه تولید داده های تجزیه و تحلیل کامل .

اگر معیارهای بالا برآورده نشدند، مقدار "(تنظیم نشده)" را مشاهده خواهید کرد. همچنین ببینید یک مقدار موجودیت تحلیلی "(تنظیم نشده)" به چه معناست؟ .

ایمیل توسعه دهندگان ثبت شده در Edge که برنامه آنها با API تماس برقرار کرده است.

برای دریافت این بعد، توسعه‌دهندگان باید برنامه‌هایی مرتبط با یک یا چند محصول API داشته باشند که حاوی پراکسی‌های API در حال فراخوانی باشد، و پراکسی‌ها باید یک کلید API یا نشانه OAuth ارسال شده با تماس API را بررسی کنند. کلید یا نشانه برنامه توسعه دهنده را شناسایی می کند. برای اطلاعات بیشتر، ابتدا به اولین چیزها مراجعه کنید: نحوه تولید داده های تجزیه و تحلیل کامل .

اگر معیارهای بالا برآورده نشدند، مقدار "(تنظیم نشده)" را مشاهده خواهید کرد. همچنین ببینید یک مقدار موجودیت تحلیلی "(تنظیم نشده)" به چه معناست؟ .

شناسه توسعه‌دهنده منحصر به فرد ایجاد شده توسط Edge به شکل org_name @@@ unique_id .

برای دریافت این بعد، توسعه‌دهندگان باید برنامه‌هایی مرتبط با یک یا چند محصول API حاوی پراکسی‌های API در حال فراخوانی داشته باشند، و پراکسی‌ها باید یک کلید API یا نشانه OAuth ارسال شده با تماس‌های API را بررسی کنند. کلید یا توکن توسعه دهنده را شناسایی می کند. برای اطلاعات بیشتر، ابتدا به اولین چیزها مراجعه کنید: نحوه تولید داده های تجزیه و تحلیل کامل .

اگر معیارهای بالا برآورده نشدند، مقدار "(تنظیم نشده)" را مشاهده خواهید کرد. همچنین ببینید یک مقدار موجودیت تحلیلی "(تنظیم نشده)" به چه معناست؟ .

کد خطای خطا به عنوان مثال: messaging.adaptors.http.flow.GatewayTimeout

جریان نامگذاری شده در یک پروکسی API که خطایی را ایجاد کرد. به عنوان مثال، «PreFlow»، «PostFlow» یا نام یک جریان شرطی که ایجاد کرده‌اید.

توجه داشته باشید که نام کامل مورد استفاده در API مدیریت ax_execution_fault_flow_name است، بدون خط شکنی.

در جایی که هیچ خطایی رخ نداده است، مقدار "(تنظیم نشده)" را خواهید دید.

نام جریان پراکسی API بیان می کند که خطاهایی مانند "PROXY_REQ_FLOW" یا "TARGET_RESP_FLOW" ایجاد شده است.

توجه داشته باشید که نام کامل مورد استفاده در API مدیریت ax_execution_fault_flow_state است، بدون خط شکنی.

نام خط‌مشی که خطایی ایجاد کرد و باعث شکست فراخوانی API شد.

توجه داشته باشید که نام کامل مورد استفاده در API مدیریت ax_execution_fault_policy_name است، بدون خط شکنی.

اگر خط‌مشی خطایی ایجاد کند اما ویژگی ریشه سیاست continueOnError روی true تنظیم شود، جریان پراکسی API بدون شکست ادامه می‌یابد و شکست خط‌مشی در این بعد محاسبه نمی‌شود.

BasePath روی پروکسی API ProxyEndpoint پیکربندی شده است. مسیر پایه شامل دامنه و بخش پورت URL پروکسی API نیست. به عنوان مثال، اگر URL پایه یک پروکسی API https://apigeedocs-test.apigee.net/releasenotes/ باشد، مسیر پایه /releasenotes است.

مقدار نیز در متغیر جریان proxy.basepath ذخیره می شود.

مسیر منبع به مسیر پایه پروکسی API اضافه شده است. برای مثال، اگر نشانی وب پایه یک پروکسی API https://apigeedocs-test.apigee.net/hello/ باشد و با https://apigeedocs-test.apigee.net/hello/json تماس گرفته شود، پسوند مسیر است. /json .

اگر از پسوند مسیر استفاده نشود، مقدار خالی است.

مقدار نیز در متغیر جریان proxy.pathsuffix ذخیره می شود.

حاوی آدرس IP مشتری اصلی است. مقدار بعد ax_resolved_client_ip از مقادیر موجود در ابعاد ax_true_client_ip و x_forwarded_for_ip محاسبه می‌شود.

توجه داشته باشید که هنگام استفاده از محصولات مسیریابی مانند Akamai برای گرفتن آدرس های IP واقعی کلاینت ها، IP کلاینت در هدر HTTP True-Client-IP به Edge ارسال می شود، که سپس برای تنظیم بعد ax_true_client_ip استفاده می شود.

مقدار بعد ax_resolved_client_ip به صورت زیر محاسبه می شود:

1. اگر ax_true_client_ip null نیست و حاوی آدرس IP محلی نیست، ax_resolved_client_ip را روی ax_true_client_ip قرار دهید.
2. در غیر این صورت، ax_resolved_client_ip را روی اولین آدرس IP غیر محلی در x_forwarded_for_ip تنظیم کنید.
3. اگر هر دو ax_true_client_ip و x_forwarded_for_ip فقط حاوی آدرس‌های IP محلی هستند، ax_resolved_client_ip روی اولین آدرس IP محلی در x_forwarded_for_ip تنظیم کنید.
4. اگر هر دو ax_true_client_ip و x_forwarded_for_ip تهی هستند، ax_resolved_client_ip روی (not set) قرار دهید.
5. اگر ax_true_client_ip یک آدرس IP محلی است و x_forwarded_for_ip پوچ است، ax_resolved_client_ip را روی (not set) قرار دهید.

نسخه سیستم عامل دستگاهی که تماس برقرار می کند.

استفاده از این به عنوان دومین بعد "تحلیلی" با خانواده سیستم عامل (ax_ua_os_family) برای دیدن نسخه های سیستم عامل مفید است.

آدرس IP مشتری تماس گیرنده، ذخیره شده در متغیر جریان proxy.client.ip . این اغلب آدرس X-Forwarded-For تماس ورودی است، که آدرس IP Edge دریافت شده از آخرین دست دادن TCP خارجی است. این می تواند مشتری تماس گیرنده یا متعادل کننده بار باشد. هنگامی که چندین IP در هدر X-Forwarded-For وجود دارد، این آخرین IP لیست شده است.

هنگامی که از محصولات مسیریابی مانند Akamai برای گرفتن آدرس های IP واقعی کلاینت ها استفاده می کنید، IP های کلاینت در هدر HTTP True-Client-IP به Edge ارسال می شود. این بعد IP های مشتری واقعی را از آن هدر می گیرد.

برای تعیین آدرس IP مشتری اصلی، که از طریق بعد ax_resolved_client_ip قابل دسترسی است، Edge از ابعاد ax_true_client_ip و x_forwarded_for_ip استفاده می‌کند.

مسیر منبع (بدون احتساب دامنه) به سرویس هدف، به استثنای پارامترهای پرس و جو.

به عنوان مثال، هدف نمونه Apigee http://mocktarget.apigee.net شامل چندین منبع از جمله /user است که یک تبریک را برمی‌گرداند. صرف نظر از نحوه فراخوانی پروکسی API شما http://mocktarget.apigee.net/user ، request_path /user است.

مسیر منبع (بدون احتساب دامنه) به سرویس هدف، از جمله پارامترهای پرس و جو.

به عنوان مثال، هدف نمونه Apigee http://mocktarget.apigee.net شامل چندین منبع، از جمله منبع /user?user={name} و پارامتر query برای برگرداندن یک تبریک سفارشی به نام ارائه شده است. صرف نظر از نحوه تماس پراکسی API شما http://mocktarget.apigee.net/user?user=Dude ، request_uri /user?user=Dude است.

نام عامل کاربر یا عامل نرم افزاری که برای برقراری تماس API استفاده می شود. مثال ها:

• تماس Pixel XL از طریق Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• یک iPad که از طریق کروم تماس برقرار می کند: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL از ترمینال: curl/7.51.0

نسخه useragent.

برای دریافت نسخه خانواده عامل، استفاده از آن به‌عنوان دومین بعد «تحقیقی» با User Agent Family (ax_ua_agent_family) مفید است.

مسیر منبع (بدون شامل دامنه) به سرویس هدف، به استثنای پارامترهای پرس و جو، که در <TargetEndpoint> پروکسی تعریف شده است.

به عنوان مثال، فرض کنید یک پروکسی API هدف زیر را فراخوانی می کند:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

در این مثال، target_basepath /user است.

اگر هدف این بود:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

target_basepath صفر خواهد بود.

در ابزار Trace ، وقتی نماد AX را در انتهای نمودار جریان انتخاب می‌کنید، متغیر جریان target.basepath به بعد target_basepath نگاشت می‌شود.

کد وضعیت پاسخ HTTP که توسط سرویس هدف به پراکسی API مانند 200، 404، 503 و غیره بازگردانده می شود.

مقدار "null" به این معنی است که درخواست هرگز به سرویس هدف نرسیده است. این زمانی اتفاق می‌افتد که پاسخ توسط خط‌مشی حافظه پنهان پاسخ ارائه می‌شود یا زمانی که پردازش درخواست با مشکل مواجه می‌شود.

این با بعد کد وضعیت پاسخ (response_status_code) متفاوت است.

URL کامل سرویس هدف که در TargetEndpoint یک پروکسی API تعریف شده است.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

در این مثال، target_url http://mocktarget.apigee.net/user?user=Dude است.

توجه داشته باشید که URL را می‌توان در طول پردازش پراکسی API با متغیر جریان target.url لغو کرد.

در زنجیره پراکسی و هنگام استفاده از اهداف اسکریپت (Node.js) ، target_url در پراکسی فراخوان تهی است.

لیست آدرس های IP در هدر X-Forwarded-For .

برای تعیین آدرس IP مشتری اصلی، که از طریق بعد ax_resolved_client_ip قابل دسترسی است، Edge از ابعاد ax_true_client_ip و x_forwarded_for_ip استفاده می‌کند.

بر اساس ساعت 24 ساعته، ساعت 2 رقمی که در آن تماس های API برقرار شده است. به عنوان مثال، تماس‌های API بین ساعت 10 شب تا 11 شب، ax_hour_of_day 22 خواهد بود.

مقدار زمان بر حسب UTC است.