أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info
Edge API Analytics هي ميزة مضمّنة فعّالة جدًا يوفّرها Apigee Edge. وهي تجمع وتحلّل مجموعة كبيرة من البيانات التي تنتقل عبر واجهات برمجة التطبيقات. ويمكن أن تقدّم بيانات الإحصاءات التي يتم جمعها إحصاءات مفيدة جدًا. على سبيل المثال، ما هو اتجاه حجم حركة بيانات واجهة برمجة التطبيقات خلال فترة زمنية معيّنة؟ ما هي واجهة برمجة التطبيقات الأكثر استخدامًا؟ ما هي واجهات برمجة التطبيقات التي تسجّل معدّلات أخطاء عالية؟
يمكن استخدام التحليل المنتظم لهذه البيانات والإحصاءات لاتّخاذ الإجراءات المناسبة، مثل التخطيط المستقبلي لسعة واجهات برمجة التطبيقات استنادًا إلى الاستخدام الحالي وقرارات الاستثمار التجارية والمستقبلية وغير ذلك الكثير.
بيانات الإحصاءات ومكان تخزينها
تجمع "إحصاءات واجهة برمجة التطبيقات" أنواعًا مختلفة من البيانات، مثل:
- معلومات عن واجهة برمجة التطبيقات: عنوان URI للطلب وعنوان IP للعميل ورموز حالة الرد وما إلى ذلك
- أداء خادم وكيل واجهة برمجة التطبيقات: معدّل النجاح/الإخفاق ووقت معالجة الطلب والرد وما إلى ذلك
- أداء الخادم المستهدَف: معدّل النجاح/الإخفاق ووقت المعالجة
- معلومات الخطأ: عدد الأخطاء ورمز الخطأ والسياسة التي تعذّر تنفيذها وعدد الأخطاء الناتجة عن Apigee والخادم المستهدَف
- معلومات أخرى: عدد الطلبات التي يقدّمها المطوّرون وتطبيقات المطوّرين وما إلى ذلك
يتم تخزين كل هذه البيانات في مخطط analytics analytics الذي تم إنشاؤه وإدارته ضمن قاعدة بيانات
Postgres بواسطة Apigee Edge.
في عملية تثبيت عادية لـ Edge، سيحتوي Postgres عادةً على المخططات التالية:
يستخدم Edge المخطط الذي يحمل الاسم analytics لتخزين جميع بيانات الإحصاءات لكل مؤسسة وبيئة. إذا تم تثبيت ميزة تحقيق الربح، سيكون هناك مخطط rkms. أما المخططات الأخرى، فهي مخصّصة لعمليات Postgres الداخلية.
سيستمر تغيير المخطط analytics لأنّ Apigee Edge سيضيف إليه بشكل ديناميكي جداول بيانات
جديدة في وقت التشغيل. سيجمع مكوّن خادم Postgres بيانات الحقائق في جداول مجمّعة
يتم تحميلها وعرضها على واجهة مستخدم New Edge.
ممارسات غير مستحسنة
لا يُنصح بإضافة أعمدة مخصّصة و/أو جداول و/أو طرق عرض مخصّصة إلى أي من المخططات التي تملكها Apigee في قاعدة بيانات Postgres على بيئات Private Cloud مباشرةً باستخدام طلبات بحث SQL، لأنّ ذلك قد يؤدي إلى آثار سلبية.
لنأخذ مثالاً لتوضيح ذلك بالتفصيل.
لنفترض أنّه تم إنشاء جدول مخصّص باسم account ضمن مخطط الإحصاءات كما هو
موضّح أدناه:
بعد فترة، لنفترض أنّه يجب ترقية 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مخطط.