شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
Edge API Analytics یک ویژگی داخلی بسیار قدرتمند است که توسط Apigee Edge ارائه شده است. این ویژگی طیف گستردهای از دادههایی را که در APIها جریان دارند، جمعآوری و تجزیه و تحلیل میکند. دادههای تحلیلی جمعآوریشده میتوانند بینشهای بسیار مفیدی ارائه دهند. به عنوان مثال، روند حجم ترافیک API در یک دوره زمانی چگونه است؟ کدام API بیشترین استفاده را دارد؟ کدام APIها نرخ خطای بالایی دارند؟
تحلیل منظم این دادهها و بینشها میتواند برای انجام اقدامات مناسب مانند برنامهریزی ظرفیت آینده APIها بر اساس میزان استفاده فعلی، تصمیمات تجاری و سرمایهگذاریهای آینده و بسیاری موارد دیگر مورد استفاده قرار گیرد.
دادههای تحلیلی و ذخیرهسازی آن
API Analytics انواع مختلفی از دادهها را ثبت میکند، مانند:
- اطلاعات مربوط به یک API - درخواست URI، آدرس IP کلاینت، کدهای وضعیت پاسخ و غیره
- عملکرد پروکسی API - نرخ موفقیت/شکست، زمان پردازش درخواست و پاسخ و غیره
- عملکرد سرور هدف - میزان موفقیت/شکست، زمان پردازش
- اطلاعات خطا - تعداد خطاها، کد خطا، خطمشی شکست، تعداد خطاهای ایجاد شده توسط Apigee و سرور هدف.
- سایر اطلاعات - تعداد درخواستهای انجام شده توسط توسعهدهندگان، برنامههای توسعهدهندگان و غیره
تمام این دادهها در یک طرح analytics ذخیره میشوند که توسط Apigee Edge در پایگاه داده Postgres ایجاد و مدیریت میشود.
معمولاً، در نصب Vanilla Edge، Postgres طرحوارههای زیر را خواهد داشت:
طرحوارهای به نام analytics توسط Edge برای ذخیره تمام دادههای تحلیلی برای هر سازمان و محیط استفاده میشود. اگر monetization نصب شود، یک طرحواره rkms وجود خواهد داشت. طرحوارههای دیگر برای داخلیهای Postgres در نظر گرفته شدهاند.
طرحواره analytics همچنان تغییر خواهد کرد زیرا Apigee Edge به صورت پویا جداول واقعیت جدیدی را در زمان اجرا به آن اضافه میکند. مؤلفه سرور Postgres دادههای واقعیت را در جداول تجمیعی جمعآوری میکند که در رابط کاربری Edge بارگذاری و نمایش داده میشوند.
ضدالگو
اضافه کردن ستونها، جداول و/یا نماهای سفارشی به هر یک از طرحوارههای متعلق به Apigee در محیطهای پایگاه داده Postgres در فضای ابری خصوصی، مستقیماً با استفاده از کوئریهای SQL توصیه نمیشود، زیرا میتواند پیامدهای نامطلوبی داشته باشد.
برای توضیح دقیق این موضوع، مثالی میزنیم.
در نظر بگیرید که یک جدول سفارشی به نام account تحت طرح تحلیلی (analytics schema) مطابق شکل زیر ایجاد شده است:
پس از مدتی، فرض کنید نیاز به ارتقاء Apigee Edge از نسخه پایینتر به نسخه بالاتر وجود دارد. ارتقاء Private Cloud Apigee Edge شامل ارتقاء Postgres در کنار بسیاری از اجزای دیگر است. اگر ستونها، جداول یا نماهای سفارشی به پایگاه داده Postgres اضافه شده باشد، ارتقاء Postgres با خطاهایی در ارجاع به اشیاء سفارشی مواجه میشود زیرا آنها توسط Apigee Edge ایجاد نشدهاند. بنابراین، ارتقاء Apigee Edge نیز با شکست مواجه میشود و نمیتواند تکمیل شود.
به طور مشابه، خطاهایی میتوانند در طول فعالیتهای نگهداری Apigee Edge رخ دهند که در آنها پشتیبانگیری و بازیابی اجزای Edge از جمله پایگاه داده Postgres انجام میشود.
تأثیر
- ارتقاء Apigee Edge نمیتواند تکمیل شود زیرا ارتقاء مؤلفه Postgres با خطاهایی که به اشیاء سفارشی ایجاد نشده توسط Apigee Edge اشاره میکنند، با شکست مواجه میشود.
- ناسازگاریها (و خرابیها) هنگام انجام تعمیر و نگهداری سرویس Apigee Analytics (پشتیبانگیری/بازیابی).
بهترین روش
- هیچ اطلاعات سفارشی را به شکل ستونها، جداول، نماها، توابع و رویهها مستقیماً به هیچ یک از طرحهای متعلق به Apigee مانند
analyticsو غیره اضافه نکنید. - اگر نیاز به پشتیبانی از اطلاعات سفارشی باشد، میتوان آن را به عنوان ستون (فیلد) با استفاده از سیاست جمعآوری آمار به طرح
analyticsاضافه کرد.