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

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

سینتکس API: tps

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

نحو API: sum(cache_hit)

تعداد عناصر موجود در حافظه پنهان سطح ۱ (درون حافظه) به ازای هر تراکنش در یک بازه زمانی مشخص را برمی‌گرداند. برای مثال، اگر برای دوره یک روز max انتخاب کنید و در آن روز بیشترین تعداد عناصر موجود در حافظه پنهان برای یک تراکنش خاص ۱۲ باشد، تعداد عناصر ۱۲ خواهد بود. برای avg ، اگر در دوره زمانی که شما در حال پرس و جو هستید، سه تراکنش وجود داشته باشد و تعداد حافظه پنهان آنها ۵، ۶ و ۷ باشد، میانگین ۶ است. حافظه پنهان سطح ۱، حافظه پنهان در حافظه است، برخلاف حافظه پنهان پایگاه داده سطح ۲، همانطور که در Cache internals توضیح داده شده است.

سینتکس API: avg(ax_cache_l1_count)

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

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

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

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

یک خطای هدف (مانند خطای ۴۰۴ یا ۵۰۳) به عنوان خطای خط‌مشی (policy failure) محسوب نمی‌شود. این خطاها به عنوان خطای پروکسی API (is_error) محسوب می‌شوند.

نحو API: sum(policy_error)

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

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

نحو API: sum(is_error)

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

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

نحو API: max(request_processing_latency)

اندازه‌ی درخواست ارسالی (payload) دریافت شده توسط Edge، بر حسب بایت .

سینتکس API: avg(request_size)

تعداد کل دفعاتی که یک سیاست کش پاسخ (Response Cache) در طول دوره زمانی مشخص اجرا شده است.

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

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

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

نحو 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 پاسخی را از حافظه پنهان (cache) برگرداند (برای مثال، با استفاده از خط‌مشی Response Cache)، این فراخوانی هرگز به سرویس هدف نخواهد رسید و هیچ معیار زمان پاسخ هدف ثبت نمی‌شود.

نحو API: avg(target_response_time)

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

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

سینتکس API: avg(total_response_time)

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

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

نحو API: sum(message_count)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ایمیل توسعه‌دهندگان ثبت‌شده در اج که برنامه‌ی آن‌ها فراخوانی‌های 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. برای مثال، اگر URL پایه یک پروکسی 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 واقعی کلاینت‌ها، True-Client-IP کلاینت در هدر HTTP به 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 تهی (null) باشند، ax_resolved_client_ip روی (not set) تنظیم کنید.
5. اگر ax_true_client_ip یک آدرس IP محلی است و x_forwarded_for_ip مقدار null دارد، ax_resolved_client_ip روی (not set) تنظیم کنید.

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

استفاده از این به عنوان بُعد دوم «مرور» با خانواده سیستم عامل (ax_ua_os_family) برای دیدن نسخه‌های سیستم عامل‌ها مفید است.

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

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

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

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

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

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

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

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

• یک پیکسل XL در حال برقراری تماس از طریق کروم: 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
• یک آیپد که از طریق کروم تماس برقرار می‌کند: 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

نسخه عامل کاربری.

استفاده از این به عنوان بُعد دوم «مرور» با 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 برابر با null خواهد بود.

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

کد وضعیت پاسخ HTTP که توسط سرویس هدف به پروکسی API برگردانده می‌شود، مانند ۲۰۰، ۴۰۴، ۵۰۳ و غیره.

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

این با بُعد کد وضعیت پاسخ (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 در پروکسی فراخوانی‌کننده، null است.

فهرست آدرس‌های IP موجود در هدر X-Forwarded-For .

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

بر اساس ساعت ۲۴ ساعته، ساعت دو رقمی که فراخوانی‌های API در آن انجام شده است. برای مثال، فراخوانی‌های API که در ساعت بین ۱۰ شب تا ۱۱ شب انجام شده‌اند، ax_hour_of_day برابر با ۲۲ خواهد بود.

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