Endpoints
تقوم نقاط النهاية بتعريف API للخدمة وتقديم مشاهدة تفصيلية في العمليات التي يتم عرضها بواسطة الخدمات. كل استدعاء لخدمة يحدث في نقطة نهاية واحدة. كل نقطة طرفية لها نوع منفرد ، يتم اكتشافه آليا :BATCH,SHELL,DATABASE,HTTP,MESSAGING,RPC. مثل الخدمات ، يمكن مشاهدة نقاط النهاية من خلال عدسة الشكل العام للتطبيق.
يمكن تحديد نقطة النهاية بشكل ثابت أو يمكن أن تعتمد على شارات تعليم الاستدعاء (على النقيض من الخدمة ، التي يتم تحديدها باستخدام علامات البنية التحتية ، مثل اسم SpringBoot). على سبيل المثال ، مجموعة من{call.http.method} {call.http.path}سيكون نقطة نهاية نموذجية لخدمة HTTP.
وثمة فائدة أخرى لتحديد نقاط نهاية منفصلة للخدمة وهي أن الخدمات يمكن أن تشمل في المقام الأول العديد من الأطر والتكنولوجيات المختلفة ؛ و HTTP/REST APIs ، وإمكانية الوصول إلى قاعدة البيانات ، ودمج ناقل الرسائل ، وما إلى ذلك. عن طريق تكوين نقاط نهاية على الأقل لكل نوع من برامج API ، ومن المحتمل أن يتم تقسيم تفاصيل مثل البروتوكول والمقاييس المترية والاحصائيات لكل نوع API.
يقوم InRass آليا بتحديد نقاط النهاية بناءا على القواعد المفترضة. للحصول على مزيد من المعلومات ، ارجع الى مناظرة نقطة النهاية.
- مناظرة نقطة النهاية
- تهيئة مناظرة نقطة النهاية
- نقاط نهاية اصطناعية
- مكالمات صناعية
- نقاط نهاية غير محددة
- نقاط نهاية أخرى
- نقاط نهاية Trigger الداخلية
مناظرة نقطة نهاية
يتم تنظيم نقاط النهاية آليا بناءا على نوع نقطة النهاية.
على سبيل المثال ، يقوم Intana آليا بمجموعات HTTP endpoints بناءا على قالب المسار اذا كان يمكن التوصل اليه.
/hospital/1948/patient/291148
/hospital/728/patient/924892
/hospital/47/patient/25978
/hospital/108429/patient/1847
في المثال أعلاه ، سيتم تجميع نقاط النهاية السابقة ، التي يتم استخدامها بواسطة نفس كود التطبيق وبذلك يكون لها ملف مواصفات للأداء المشترك ، وسيتم تسجيلها معا مثلما يلي :
/hospital/{hid}/patient/{pid}
يتم تنفيذ ذلك آليا ولا توجد خطوات للمستخدم مطلوبة للأطر المعروفة.
عندما يكون نموذج المسار غير متاح ، سيتم مناظرة نقاط النهاية الى مقطع المسار الأول أو يمكن أن تكون توصيف كما هو مطلوب
اذا كنت تقوم بكتابة كود التتبع الخاص بك ، ارجع الى تتبع أفضل الممارسات كيف يمكنك تحقيق نفس النتائج.
تهيئة مناظرة نقطة النهاية
بالنسبة لكل خدمة ، يسمح Intana بوجود توصيف واحد يتحكم في كيفية استخراج نقاط نهاية الخدمات. للتوصل الى التوصيف ، قم بالتجول الى واجهة تعامل الخدمات ، اذهب الى علامة تبويب نقاط النهاية واضغط "توصيف نقاط النهاية".
لاحظ أن توصيفات نقطة النهاية المهيأة تكون متاحة لخدمات تعتمد على http فقط.
قواعد نقطة نهاية Custom
ويأتي هذا الاستطاع مع قواعد HTTP الثلاثة المفترضة التي تكون دائما جزءا من سلسلة الاستخراج :
- اطار عمل تم اكتشافه: يقوم باستخراج نقاط النهاية كما هو محدد في الاطار الذي تم اكتشافه (اذا كان يمكن التوصل اليه).
- /*: لاستخراج نقاط النهاية بناءا على معامل المسار الأول.
- غير محدد: الاستدعاءات التي لا تتفق مع القاعدة السابقة يتم تخصيصها الى نقطة النهاية هذه.
لتحديد توصيف اضافي ، يمكنك تعريف قواعد مهيأة متعددة. للقيام بذلك ، قم بالتوصل الى حوار توصيف نقطة النهاية المهيأة من أي خدمة HTTP وقم بضرب "Add Custom HTTP Rule". سيقدم لك مربع الحوار القادم امكانية تعريف مسار معين (القاعدة الفعلية) والعديد من حالات الاختبار للتحقق مما اذا كان المسار المعرف يعمل كما هو متوقع. بالنسبة للمسار الذي يمكنك استخدام مقاطع استاتيكية مثل/apiأو/myShopEndpoint، معاملات المسار مثل/{productId}، أو تطابق أي مقطع مع/*.
في الجزء الخاص بتطبيق القواعد من مربع الحوار ، يمكنك تعريف العديد من حالات الاختبار للتحقق من القواعد. على سبيل المثال ، تم تحديد استعلام/api/*/{version}، حالة الاختبار التالية/api/anyName/123سيتطابق ، أثناء/otherApi/anyName/123لن.
تقييم Sequential
يتم تطبيق القواعد من أعلى الى أسفل ، ويتم تخصيص الاتصالات لأول قاعدة مطابقة. تسلسل التغيير ، ببساطة إعادة ترتيب القواعد ولكن فقط قم بالسحب والوضع. يمكن الغاء اتاحة القواعد المفترضة الى Inasuret ، ولكن لا يمكن اعادة طلبها.
نقاط نهاية صناعية
نقاط النهاية التي تستقبل المرور الاصطناعي فقط ، مثل الاستدعاءات لنقاط النهاية للتحقق من الصحة ، يمكن أن تقوم بانحراف مؤشرات الأداء الرئيسية للتطبيقات والخدمات الخاصة بك. يكتشف Incass-auto-نقاط النهاية هذه ويقوم بتعليمها على أنها اصطناعي لمنعها من التأثير على التطبيقات ومؤشرات الأداء الرئيسية للخدمة.
كيف يتم استخدام نقاط النهاية الاصطناعية في Intana
يتم وضع علامة على كل استدعاء تم حفظه تحت نقطة نهاية اصطناعية على أنه إصطناعي في تحليلات غير محللا ولا يعتمد على مؤشرات الأداء الرئيسية لمشاهدات الشكل العام للتطبيق والخدمة ونقطة النهاية.
على الرغم من مناشداتهم لا تعتمد على مؤشرات الأداء الرئيسية الخاصة بالتطبيقات والخدمات العامة ، فإن نقاط النهاية الاصطناعية لديها لوحات بيانية خاصة بها مثل نظرائها غير الاصطناعية.
نقاط النهاية المركبة المفترضة الى
وبصفة مفترضة ، يتم تعريف نقاط النهاية الاصطناعية بواسطة نماذج عناوين URL التالية :
/healthcheck/health-check/heartbeat/ping/ready/robots.txt(يتم استخدام هذا الشخص بواسطة محركات البحث لفهرسة المواقع)/actuator/health-لتغطية Spring Boot Actuator Health Endpoints
يمكن الغاء اتاحة القاعدة الداخلية المذكورة أعلاه ، ويمكن تحديد قواعد مهيأة لتحديد نقاط نهاية اضافية على أنها صناعية ، أنظر المطبوعات الفنية الى قواعد مهيأة لنقاط النهاية الاصطناعية . يتم التوصل الى توصيف قواعد النقطة الطرفية الجاهزة والمهيأة من خلال اختيار توصيف الخدمات الذي يوجد أعلى كشف الخدمات.
قواعد المعدلة لنقاط النهاية الاصطناعية
ملاحظة : Custom rules apply globally, across all services.
للمساعدة في التوصيف ، يتم عرض نقاط النهاية والخدمات المتأثرة.
استدعاءات اصطناعية
وبالإضافة إلى كونه قادرا على تعليم نقاط النهاية بأكملها بأنها اصطناعية ، فإنه من الممكن أيضا بوضع علامات على المكالمات الفردية باعتبارها الاصطناعية. يكون ذلك مفيدا عندما تقوم عمليات التحقق الاصطناعية الخاصة بك باستخدام "الانتاج" APIs ، والذي يعد بصفة عامة فكرة ممتاز .
قواعد الاتصال الصناعي
وتتميز هذه الدعوة بأنها اصطناعية إذا استوفيت حالة واحدة أو أكثر من الشروط التالية :
- وهو ينتمي الى نقطة نهاية صناعية
- هو طلب HTTP الذي يحمل
X-INSTANA-SYNTHETIC: 1نص رأس HTTP وهو طلب HTTP الذي يحمل أي مما يلي البرامج الوسيطة للمستخدم:
kube-probe، والتي هي قيمةUser-Agentنص رأس التحقيقات التي صدرت عن كوبرنيتdiego-healthcheck، والتي هي قيمةUser-Agentنص رأس عمليات الفحص الصحي التي أصدرها دييغو بالنسبة الى صهر السحاب في اصدارات Cloud Fundry الحديثةELB-HealthChecker، والتي هي جزء من قيمةUser-Agentنص رأس عمليات التحقق من صحة اصدار AWS Elstic Load Balancer
ملاحظة : خلافا للحالة
X-INSTANA-SYNTHETIC، لا يقوم Incasure بتحديد الاختيار المفترضUser-Agentنص الرأس. لذلك ، لتطبيق هذه القواعد ، يجب أن تقوم باستخدام وظائف نصوص رأس HTTP المهيأة لكي يقوم وكلاء النظام الرئيسي بمراقبة برامج APIs التي تقوم بتجميعهاUser-Agentنص الرأس.وهو عبارة عن عمل Spring Cloud Confالقنصلية Config Watch
- المساحات التي تم توضيحها مع
syntheticمع القيمةtrue، التي يمكن تحقيقها مع أي من تتبع SDKs للتتبع
استدعاءات اصطناعية في تحليلات غير محددة
الاستدعاءات المتزامنة هي ، افتراضيا ، يتم اخفائها في تحليلات غير محددة ، حيث أنها تميل الى أن تكون مثيرة للاهتمام لتحليل الأداء فقط عندما تكون خاطئ جدا. لكي يتوافر لديك استدعاءات تحليلات غير محددة أيضا ، يجب أن تقوم باختيار التطبيق من خلال مفتاح مكالمات مخفية-> استدعاءات اصطناعية .
نقاط نهاية غير محددة
عندما يكون هناك معلومات غير كافية لمناظرتها آليا الى نقطة نهاية (eg. يتم مناظرة نقاط النهاية يدويا بدون اتاحة بيانات كافية) ، ويتم مناظرة هذه الاستدعاءات لنقطة النهاية الخاصة "غير المحددة".
نقاط نهاية أخرى
عند اكتشاف العديد من نقاط النهاية على خدمة معينة ، يتم تجميع الاتصالات تحت نقطة نهاية "أخرى" خاصة. والهدف من هذه الحماية هو الحفاظ على مجموعة نقاط النهاية إلى حجم معقول.
وعادة ما يحدث ذلك عندما يقوم أحد Ingasing قواعد معرفة مسبقا أو قاعدة مهيأة بتجميع الاستدعاءات في عدد كبير من نقاط النهاية التي تقوم باستلام اتصال واحد لكل منهم.
على سبيل المثال ، أحد Intagints قواعد معرفة مسبقا يقوم بمناظرة استدعاءات HTTP الى نقاط النهاية التي تأتي أسمائها من مقطع المسار الأول الذي تم ايجاده في عنوان URL. اذا تم بناء هذه الأجزاء من القيم الديناميكية (على سبيل المثال ، "GET /blu-item" ، "GET / البند الأحمر" ...) ، ومن شأن تطبيق هذه القاعدة أن يؤدي إلى عدد كبير من نقاط النهاية ، وهو أمر غير مفيد.
عند التعامل مع endpoints HTTP ، قد يتم تحسين الحالة عن طريق تغيير توصيف قواعد استخراج نقاط النهاية.
نقاط نهاية Trigger الداخلية
عادة ما تبدأ عمليات التتبع التي يتم التقاطها بواسطة Ingnitaman مع استدعاء وارد لأحد الخدمات. بالرغم من ذلك ، عند استخدام SDK الغير takass يكون من الممكن بدء تتبع مع استدعاء صادر من الخدمة. في هذه الحالة سيقوم Ingast بتكوين استدعاء أصلي اصطناعي (يتم مناظرته الى نقطة نهاية "trigger الداخلي") لهذه الخدمة لتحسين امكانية القراءة.
