كيف يمكنك بناء إستراتيجية مراقبة واجهة برمجة التطبيقات (API) لنقاط النهاية العامة والخاصة؟

يتطلب إنشاء إستراتيجية مراقبة واجهة برمجة التطبيقات (API) لكل من نقاط النهاية العامة والخاصة إدراك أن هاتين الفئتين من واجهات برمجة التطبيقات (API) لهما مستهلكون مختلفون، وأنماط فشل مختلفة، وقيود أمنية مختلفة، ومتطلبات وصول مختلفة للمراقبة. تخدم نقطة النهاية العامة المستخدمين الخارجيين أو الشركاء أو تطبيقات العملاء عبر الإنترنت المفتوح. تخدم نقطة النهاية الخاصة الخدمات الصغيرة الداخلية أو العاملين في الخلفية أو أدوات الإدارة أو مكونات البنية التحتية خلف حدود الشبكة. يمكن أن يتسبب كلاهما في حوادث خطيرة عند فشلهما، ولكن الطريقة التي تراقب بها كل منهما يجب أن تأخذ في الاعتبار الاختلافات.

تبدأ معظم الفرق بمراقبة واجهات برمجة التطبيقات (APIs) التي تواجه الجمهور لأنها تكون مرئية للعملاء بشكل مباشر. وهذه نقطة بداية معقولة، ولكنها تخلق نقطة عمياء خطيرة. غالبًا ما تحمل نقاط النهاية الخاصة الحمولة التي تعتمد عليها نقاط النهاية العامة. يمكن لخدمة المصادقة الداخلية الفاشلة، أو بوابة قاعدة بيانات بطيئة، أو مسار اتصال معطل بين الخدمات، أو واجهة برمجة تطبيقات قائمة انتظار الرسائل المتدهورة، أن تزيل السطح العام بالكامل على الرغم من أن نقاط النهاية العامة نفسها يمكن الوصول إليها تقنيًا. وتغطي استراتيجية المراقبة الكاملة كلتا الطبقتين لأن الموثوقية تعتمد على السلسلة الكاملة، وليس فقط الحافة المرئية.

لماذا تحتاج نقاط النهاية العامة والخاصة إلى أساليب مراقبة مختلفة

الفرق الأساسي هو من يستخدم واجهة برمجة التطبيقات (API) وكيف يصلون إليها.

يمكن للعملاء الخارجيين الوصول إلى نقاط النهاية العامة عبر الإنترنت من خلال تحليل DNS وتوجيه CDN وموازنات التحميل وإنهاء TLS. إنهم يواجهون أنماط حركة مرور غير متوقعة، ومحاولات إساءة استخدام، وتنوعًا جغرافيًا، ومجموعة كاملة من ظروف الشبكة بين العميل والخادم. يجب أن تأخذ المراقبة في الاعتبار جميع هذه العوامل لأن أيًا منها يمكن أن يؤثر على التجربة.

يتم الوصول إلى نقاط النهاية الخاصة عن طريق الخدمات الداخلية ضمن بيئة شبكة يتم التحكم فيها. يستخدمون عادةً اكتشاف الخدمة، وDNS الداخلي، والشبكات الخاصة، وغالبًا ما يتخطون TLS أو يستخدمون TLS المتبادل للمصادقة. تعد أنماط حركة المرور أكثر قابلية للتنبؤ بها، ولكن أوضاع الفشل مختلفة: التكوينات الخاطئة لشبكة الخدمة، ومشكلات تنسيق الحاوية، وفشل DNS الداخلي، وسلاسل المهلة المتتالية التي تنتشر عبر الرسم البياني للتبعية.

إن استراتيجية المراقبة التي تتعامل مع كلا النوعين بشكل متطابق ستؤدي إما إلى الإفراط في مراقبة نقاط النهاية الخاصة من خلال عمليات فحص خارجية غير ضرورية أو تقليل مراقبتها من خلال الاعتماد على نفس المجسات الخارجية التي لا يمكنها الوصول إلى الشبكات الداخلية. يصمم النهج الصحيح المراقبة لكل نوع بناءً على نموذج الوصول الخاص به وملف تعريف المخاطر والأهمية التشغيلية.

الخطوة 1: رسم خريطة لواجهة برمجة التطبيقات (API) وتصنيفها

قبل مراقبة البناء، تحتاج إلى جرد واضح لما هو موجود. تتمتع معظم المؤسسات المتنامية بنقاط نهاية لواجهة برمجة التطبيقات (API) أكثر بكثير مما تدرك، وتنتشر عبر خدمات وبيئات وحدود شبكات متعددة.

التصنيف حسب التعرض

ابدأ بتصنيف كل نقطة نهاية لواجهة برمجة التطبيقات (API) في إحدى هذه الفئات:

• عام خارجي: يمكن لأي شخص الوصول إليه عبر الإنترنت دون مصادقة. صفحات التسويق وواجهات برمجة التطبيقات للتوثيق العام ونقاط نهاية الحالة.
• مصادقة عامة: يمكن الوصول إليها عبر الإنترنت ولكنها تتطلب المصادقة. واجهات برمجة تطبيقات المنتجات التي تواجه العملاء، وعمليات تكامل الشركاء، والواجهات الخلفية لتطبيقات الهاتف المحمول.
• داخلي خاص: يمكن الوصول إليه فقط داخل الشبكة الداخلية أو VPC. الاتصال من خدمة صغيرة إلى خدمة صغيرة، وواجهات برمجة التطبيقات الإدارية الداخلية، ومعالجات المهام في الخلفية.
• البنية التحتية الخاصة: واجهات برمجة تطبيقات البنية التحتية ذات المستوى المنخفض التي تدعم النظام الأساسي. وكلاء قاعدة البيانات، وطبقات ذاكرة التخزين المؤقت، وواجهات قائمة انتظار الرسائل، ومستويات التحكم في شبكة الخدمة.

تحتوي كل فئة على متطلبات مراقبة مختلفة، وحدود زمن انتقال مقبولة مختلفة، ومعالجة مختلفة للمصادقة، وهياكل ملكية مختلفة.

التصنيف حسب تأثير الأعمال

ضمن كل فئة تعرض، قم بتصنيف نقاط النهاية حسب تأثير الأعمال. تعد واجهة برمجة التطبيقات العامة الموثقة التي تعالج المدفوعات أكثر أهمية من نقطة النهاية العامة التي تخدم المحتوى التسويقي. تعد واجهة برمجة التطبيقات الداخلية التي تتعامل مع التحقق من صحة رمز المصادقة أكثر أهمية من واجهة برمجة التطبيقات الداخلية التي تنشئ تقارير أسبوعية. يحدد تأثير الأعمال تكرار المراقبة وخطورة التنبيه وأهداف SLO.

يؤدي الجمع بين تصنيف التعرض وتأثير الأعمال إلى إنشاء مصفوفة أولويات المراقبة التي توجه الإستراتيجية بأكملها.

الخطوة 2: مراقبة التصميم لنقاط النهاية العامة

يجب مراقبة نقاط النهاية العامة خارجيًا، من وجهة نظر المستخدمين الذين يستهلكونها. وهذا يعني إجراء عمليات فحص اصطناعية من المواقع الجغرافية التي تطابق قاعدة المستخدمين الخاصة بك، عبر الإنترنت العام، من خلال نفس DNS وCDN ومسار موازنة التحميل الذي تتبعه حركة المرور الحقيقية.

الشيكات الاصطناعية الخارجية

لكل نقطة نهاية عامة مهمة، قم بتكوين عمليات فحص HTTP الاصطناعية التي:

• حل DNS وإنشاء اتصالات من خلال المسار العام
• استخدم مصادقة واقعية (مفاتيح API، ورموز OAuth، وJWTs) التي تتوافق مع ما يرسله العملاء
• التحقق من صحة رموز الحالة ووقت الاستجابة ومحتوى نص الاستجابة
• التشغيل من مناطق جغرافية متعددة بفواصل زمنية تتراوح من 30 ثانية إلى دقيقتين
• اختبر باستخدام نفس أساليب HTTP ونصوص الطلب التي يستخدمها العملاء الحقيقيون

يعد هذا المنظور الخارجي ضروريًا لأن فحوصات السلامة الداخلية لا يمكنها اكتشاف المشكلات في مسار التسليم العام. سيكون التكوين الخاطئ لنظام DNS، أو خطأ ذاكرة التخزين المؤقت لـ CDN، أو عدم تطابق التحقق من سلامة موازن التحميل، أو مشكلة شهادة TLS غير مرئي من داخل الشبكة ولكنه مرئي تمامًا للمراقبة الخارجية.

مراقبة تجربة المستهلك

يجب أن تقيس مراقبة واجهة برمجة التطبيقات العامة ما يختبره المستهلك، وليس ما يعتقد الخادم أنه يقدمه. يتضمن ذلك وقت تحليل DNS ومدة مصافحة TLS والوقت حتى البايت الأول ووقت الاستجابة الإجمالي. إذا كانت أي من هذه الطبقات بطيئة، فإن تجربة المستهلك تتدهور حتى لو كانت معالجة التطبيق سريعة.

بالنسبة لواجهات برمجة التطبيقات (API) التي يستهلكها عملاء الأجهزة المحمولة، يجب أن تأخذ حدود زمن الوصول في الاعتبار التباين الإضافي للشبكة الذي تقدمه اتصالات الأجهزة المحمولة. بالنسبة لواجهات برمجة التطبيقات التي تستهلكها عمليات تكامل الشركاء، يجب أن تتحقق المراقبة من أن رؤوس حدود المعدل والصفحات وتنسيقات الاستجابة للأخطاء تتوافق مع العقد الموثق.

تتبع حدود المعدل وأنماط إساءة الاستخدام

تواجه نقاط النهاية العامة حركة مرور لا تواجهها نقاط النهاية الداخلية: الزحف الآلي، وحشو بيانات الاعتماد، والكشط، وحلقات العميل غير المقصودة. يجب أن تتتبع المراقبة ما إذا كان تحديد المعدل يعمل بشكل صحيح وما إذا كانت أنماط حركة المرور غير العادية تؤثر على المستخدمين الشرعيين. حد المعدل العدواني للغاية يمنع المستخدمين الحقيقيين. إن حد المعدل المسموح به للغاية يسمح بإساءة الاستخدام التي تؤدي إلى انخفاض الأداء للجميع.

SLOs لنقاط النهاية العامة

يجب أن تعكس كائنات مستوى الخدمة (SLO) الخاصة بنقطة النهاية العامة وعد التجربة الذي تم تقديمه للمستهلكين. إذا نصت وثائق واجهة برمجة التطبيقات (API) على هدف توفر بنسبة 99.9% ووقت استجابة أقل من 500 مللي ثانية، فيجب أن تقوم المراقبة بالقياس والإبلاغ مقابل تلك الالتزامات المحددة. بالنسبة لواجهات برمجة التطبيقات التي تواجه الشركاء والتي تتضمن اتفاقيات مستوى الخدمة التعاقدية، تصبح بيانات المراقبة دليلاً على الإبلاغ عن الامتثال.

عادةً ما تحتاج عمليات مستوى الخدمة العامة إلى أهداف أكثر صرامة من عمليات مستوى الخدمة الخاصة لأن المستهلكين الخارجيين لديهم قدر أقل من التسامح مع حالات الفشل وسياق أقل لفهمها. يمكن للخدمة الداخلية إعادة المحاولة تلقائيًا. قد يعرض تطبيق جوال خارجي شاشة خطأ للمستخدم على الفور.

الخطوة 3: مراقبة التصميم لنقاط النهاية الخاصة

تتطلب نقاط النهاية الخاصة نهجًا مختلفًا للمراقبة لأنه لا يمكن الوصول إليها من خلال تحقيقات المراقبة الخارجية. يجب أن تتمتع البنية التحتية للمراقبة بإمكانية الوصول إلى الشبكة الداخلية حيث تتواصل هذه الخدمات.

مجسات المراقبة الداخلية

الأسلوب الأكثر شيوعًا هو تشغيل وكلاء المراقبة أو منفذي الفحص الاصطناعي داخل الشبكة الخاصة. ترسل هذه التحقيقات طلبات إلى نقاط النهاية الداخلية باستخدام نفس اكتشاف الخدمة وDNS الداخلي وآليات المصادقة التي تستخدمها خدمات الإنتاج.

بالنسبة لبيئات Kubernetes، يمكن تشغيل تحقيقات المراقبة كوحدات داخل المجموعة، للوصول إلى الخدمات من خلال أسماء الخدمات الداخلية وDNS للمجموعة. بالنسبة للبنيات المستندة إلى VPC، يتم تشغيل وكلاء المراقبة داخل VPC مع الوصول المناسب لمجموعة الأمان. بالنسبة للبيئات المختلطة، قد تحتاج المسابير إلى التشغيل في مناطق شبكات متعددة.

يجب أن يكرر المسبار كيفية استدعاء نقطة النهاية فعليًا في الإنتاج. إذا كانت الخدمات تتواصل من خلال شبكة خدمة مع TLS متبادل، فيجب أن يستخدم مسبار المراقبة نفس مسار المصادقة. إذا تم حل الخدمات من خلال DNS الداخلي باستخدام TTLs قصيرة، فمن المفترض أن يتم حل المسبار بنفس الطريقة. كلما كان مسار المراقبة أقرب إلى مسار الإنتاج، كلما كان يمثل السلوك الحقيقي بشكل أكثر دقة.

مراقبة التبعيات بين الخدمات

يجب أن تركز مراقبة نقطة النهاية الخاصة بشكل كبير على علاقات التبعية بين الخدمات. في بنية الخدمات الصغيرة، قد يجتاز طلب مستخدم واحد من 5 إلى 15 استدعاءًا داخليًا لواجهة برمجة التطبيقات (API). يؤثر الفشل أو التدهور في أي نقطة في تلك السلسلة على الاستجابة النهائية.

تقوم المراقبة المدركة للتبعية بتعيين هذه العلاقات وتتبع أداء كل واجهة برمجة تطبيقات داخلية ومدى توفرها بشكل مستقل. عند حدوث حادثة عامة، تساعد هذه الرؤية الداخلية الفرق على تحديد الخدمة الداخلية التي هي السبب الجذري بسرعة بدلاً من التحقيق في السلسلة بأكملها يدويًا.

تتبع ميزانيات الكمون الداخلي

تتضمن كل استجابة عامة لواجهة برمجة التطبيقات (API) الوقت المستغرق في مكالمات الخدمة الداخلية. إذا كان SLO العام يتطلب استجابة تبلغ 500 مللي ثانية، ويجتاز الطلب ثلاث خدمات داخلية، فإن كل خدمة لها ميزانية زمن الوصول الضمنية. إذا استهلكت إحدى الخدمات الداخلية 400 مللي ثانية من ميزانية 500 مللي ثانية، فإن SLO العام معرض للخطر بالفعل على الرغم من عدم فشل أي فحص داخلي.

تضمن مراقبة نقاط النهاية الداخلية مع حدود زمن الوصول المستمدة من ميزانية SLO العامة اكتشاف التدهور الداخلي قبل كسر التجربة الخارجية. يعد هذا النهج القائم على الميزانية أكثر فعالية من مراقبة كل خدمة داخلية بشكل منفصل لأنه يربط الأداء الداخلي بالنتيجة المهمة بالفعل.

التعامل مع المصادقة لمراقبة نقطة النهاية الخاصة

غالبًا ما تستخدم واجهات برمجة التطبيقات الداخلية آليات مصادقة مختلفة عن واجهات برمجة التطبيقات العامة. قد يستخدم الاتصال من خدمة إلى خدمة TLS المتبادل، أو رموز JWT الداخلية، أو بيانات اعتماد حساب الخدمة، أو مفاتيح API المخصصة للاستخدام الداخلي، أو عدم المصادقة على الإطلاق إذا كانت حدود الشبكة موثوقة.

تحتاج مجسات المراقبة إلى بيانات اعتماد تتوافق مع نموذج المصادقة الداخلي. يجب إدارة بيانات الاعتماد هذه بنفس ممارسات الأمان مثل بيانات اعتماد خدمة الإنتاج: يتم تدويرها بانتظام، وتحديد نطاقها إلى الحد الأدنى من الأذونات المطلوبة، وتخزينها في أنظمة إدارة سرية. يؤدي تحقيق المراقبة باستخدام أذونات واسعة جدًا أو بيانات اعتماد قديمة إلى إنشاء مخاطر أمنية ومخاطر موثوقية المراقبة.

SLOs لنقاط النهاية الخاصة

يجب أن تستمد أهداف مستوى الخدمة الخاصة بنقطة النهاية من مساهمتها في مستويات الخدمة العامة. إذا تم استدعاء خدمة مصادقة داخلية بناءً على كل طلب مستخدم وكانت واجهة برمجة التطبيقات العامة تتمتع بتوفر SLO بنسبة 99.9%، فإن خدمة المصادقة الداخلية تحتاج إلى هدف إتاحة على الأقل بنفس القدر من الدقة، لأن حالات فشلها تنتشر مباشرة إلى السطح العام.

بالنسبة للخدمات الداخلية التي يتم استدعاؤها بواسطة نقاط نهاية عامة متعددة، يجب أن يعتمد SLO على المستهلك الأكثر أهمية. يجب أن تكون خدمة البيانات الداخلية التي تغذي كلاً من واجهة برمجة التطبيقات الخاصة بالخروج ومولد التقارير الأسبوعية متوافقة مع موثوقية الخروج، وليس موثوقية التقرير.

الخطوة 4: بناء رؤية موحدة عبر كلا الطبقتين

إن النتيجة الأكثر قيمة لمراقبة نقاط النهاية العامة والخاصة هي القدرة على ربط الإشارات عبر كلتا الطبقتين. عند حدوث حادثة عامة لواجهة برمجة التطبيقات (API)، يجب أن يكون الفريق قادرًا على معرفة ما إذا كان السبب الجذري موجودًا على الفور في مسار التسليم العام أو في تبعية داخلية.

تصميم لوحة القيادة الموحدة

يجب أن توفر لوحة معلومات المراقبة عرضًا متعدد الطبقات. تعرض الطبقة العليا سلامة نقطة النهاية العامة: التوفر ووقت الاستجابة ومعدلات الخطأ التي يواجهها المستخدمون الخارجيون. تُظهر الطبقة الثانية صحة نقطة النهاية الداخلية: الاتصال بين الخدمات، والوصول إلى قاعدة البيانات، وحالة واجهة برمجة تطبيقات البنية التحتية. يجب أن يكون الارتباط بين الطبقات مرئيًا بحيث أنه عند تدهور نقطة النهاية العامة، يمكن للفريق التحقق مما إذا كانت أي تبعية داخلية قد تدهورت أيضًا.

تساعد مؤشرات الحالة المرمزة بالألوان أو أسهم التبعية أو لوحات المقارنة جنبًا إلى جنب في الارتباط البصري السريع. الهدف هو أن يتمكن المهندس تحت الطلب من النظر إلى شاشة واحدة وفهم ما إذا كانت المشكلة تتعلق بالتسليم الخارجي أو الخدمات الداخلية أو مجموعة من ذلك.

التنبيه المرتبط

يجب أن يعكس تصميم التنبيه العلاقة بين نقاط النهاية العامة والخاصة. إذا تم إطلاق تنبيه واجهة برمجة التطبيقات العامة في نفس الوقت الذي يتم فيه إطلاق تنبيه التبعية الداخلية، فيجب أن يربط نظام التنبيه هذه الأحداث بدلاً من إنتاج سلاسل تنبيه منفصلة. يحتاج المستجيب إلى رؤية حادثة واحدة بكلتا الإشارتين، وليس تنبيهين غير مرتبطين يجب عليهم توصيلهما عقليًا.

يؤدي هذا الارتباط إلى تقليل وقت الاستجابة بشكل كبير لأن المستجيب يفهم الصورة الكاملة على الفور: تفشل واجهة برمجة تطبيقات الدفع العامة لأن خدمة معالجة الدفع الداخلية تعرض أخطاء. بدون الارتباط، قد يقضي المستجيب 10 دقائق في التحقق من واجهة برمجة التطبيقات العامة قبل اكتشاف السبب الجذري الداخلي.

الجدول الزمني للحوادث المشتركة

عندما تشمل الحوادث كلا الطبقتين، يجب أن يتضمن الجدول الزمني للحادث أحداثًا من المراقبة العامة والخاصة. تم اكتشاف تغيير DNS في الساعة 14:02. ارتفاع زمن الاستجابة لواجهة برمجة تطبيقات قاعدة البيانات الداخلية عند الساعة 14:03. تبدأ أخطاء واجهة برمجة التطبيقات الخاصة بالخروج العامة في الساعة 14:04. يساعد هذا الجدول الزمني الفرق على فهم العلاقة السببية والتسلسل، وهو أمر ضروري لكل من الاستجابة في الوقت الفعلي ومراجعة ما بعد الحادث.

الخطوة 5: تناول اعتبارات الأمان والامتثال

تقدم مراقبة نقاط النهاية العامة والخاصة اعتبارات أمنية يجب معالجتها في الإستراتيجية.

حماية بيانات اعتماد المراقبة

تستخدم مجسات المراقبة لكل من نقاط النهاية العامة والخاصة بيانات اعتماد المصادقة. يجب تخزين بيانات الاعتماد هذه بشكل آمن، وتدويرها في الموعد المحدد، ونطاقها إلى الحد الأدنى من الأذونات اللازمة للمراقبة. يجب ألا تمنح بيانات اعتماد المراقبة المخترقة لواجهة برمجة التطبيقات العامة حق الوصول للكتابة. يجب ألا تكشف بيانات الاعتماد المخترقة للمسبار الداخلي عن بيانات الإنتاج.

عزل مراقبة حركة المرور

في البيئات الحساسة، يجب أن تكون مراقبة حركة المرور قابلة للتحديد والفصل عن حركة الإنتاج. يمكن تحقيق ذلك من خلال وكلاء مستخدمين مخصصين للمراقبة، أو مفاتيح API منفصلة، ​​أو وضع علامات على مستوى الشبكة. يضمن هذا الفصل أن نشاط المراقبة لا يتداخل مع الإنتاج وأن فرق الأمان يمكنها التمييز بين طلبات المراقبة وحركة المرور المشبوهة المحتملة.

الوصول إلى مراقبة التدقيق

بالنسبة للمؤسسات الخاضعة لمتطلبات الامتثال، يجب أن تكون مراقبة الوصول إلى نقاط النهاية الخاصة موثقة وقابلة للتدقيق. يجب أن تكون التحقيقات التي يمكنها الوصول إلى الخدمات الداخلية وبيانات الاعتماد التي تستخدمها والبيانات التي يمكنها قراءتها جزءًا من وضع الأمان والامتثال. المراقبة هي شكل من أشكال الوصول الآلي، ويجب أن يتم التحكم فيها وفقًا لذلك.

أمن الشبكة للمسابير الداخلية

تحتاج مجسات المراقبة الداخلية إلى وصول الشبكة إلى نقاط النهاية الخاصة، ولكن يجب أن يكون هذا الوصول مقيدًا. يجب أن تكون المجسات قادرة فقط على الوصول إلى نقاط النهاية التي تم تكوينها لمراقبتها، وليس الشبكة الداخلية بأكملها. يجب أن تحد قواعد مجموعة الأمان أو سياسات الشبكة أو ترخيص شبكة الخدمة من وصول المسبار إلى الحد الأدنى من النطاق المطلوب.

الخطوة 6: إنشاء الملكية ومراجعة الإيقاع

تتضمن إستراتيجية المراقبة التي تغطي نقاط النهاية العامة والخاصة فرقًا متعددة. قد تكون واجهات برمجة التطبيقات العامة مملوكة لهندسة المنتجات أو فرق النظام الأساسي أو فرق تجربة المطورين. قد تكون واجهات برمجة التطبيقات الخاصة مملوكة لمهندسي الواجهة الخلفية أو فرق البنية التحتية أو مالكي الخدمات الصغيرة الفردية. ويجب أن تحدد استراتيجية المراقبة من هو المسؤول عن كل طبقة.

تعيين ملكية نقطة النهاية

يجب أن يكون لكل نقطة نهاية يتم مراقبتها مالك معين يكون مسؤولاً عن الحفاظ على تكوين المراقبة والاستجابة للتنبيهات ومراجعة اتجاهات الأداء. بالنسبة لنقاط النهاية العامة، غالبًا ما تتماشى الملكية مع فريق المنتج الذي يدير تجربة المستهلك. بالنسبة لنقاط النهاية الخاصة، تتماشى الملكية مع فريق الخدمة الذي يحافظ على الكود والبنية التحتية.

تشغيل المراجعات عبر الطبقات

يجب أن تجمع المراجعة ربع السنوية بين مالكي نقاط النهاية العامة والخاصة لفحص تغطية المراقبة وجودة التنبيه والامتثال لمستوى مستوى الخدمة (SLO) والفجوات. تضمن هذه المراجعة عبر الطبقات تطور استراتيجية المراقبة مع تغير البنية. تتطلب الخدمات الجديدة ونقاط النهاية المهملة والتبعيات المتغيرة وأنماط حركة المرور المتغيرة تحديثات المراقبة.

الحفاظ على مخزون المراقبة الحية

يجب أن يكون مخزون نقطة النهاية الذي تم إنشاؤه في الخطوة 1 مستندًا حيًا يتم تحديثه عند إضافة خدمات أو تغييرها أو إيقافها. تؤدي المراقبة القديمة التي تتحقق من نقاط النهاية المهملة إلى حدوث ضوضاء. يؤدي فقدان المراقبة على نقاط النهاية الجديدة إلى إنشاء نقاط عمياء. إن التسوية المنتظمة بين كتالوج الخدمة وتكوين المراقبة تمنع حدوث كلتا المشكلتين.

الأخطاء الشائعة في مراقبة واجهة برمجة التطبيقات ثنائية الطبقة

تتكرر العديد من الأخطاء عندما تقوم الفرق ببناء إستراتيجيات مراقبة تشمل نقاط النهاية العامة والخاصة.

الأول هو مراقبة نقاط النهاية العامة فقط وافتراض أن الصحة الداخلية ضمنية. يمكن أن تتدهور الخدمات الداخلية بطرق غير مرئية على الفور في المقاييس العامة حتى يتجاوز التدهور الحد الأدنى ويتسبب في فشل مفاجئ في مواجهة الجمهور.

والثاني هو استخدام مجسات المراقبة الخارجية لنقاط النهاية الداخلية. لا يمكن للمسبارات الخارجية الوصول إلى الشبكات الخاصة، كما أن محاولة تعريض نقاط النهاية الداخلية للمراقبة الخارجية تؤدي إلى مخاطر أمنية دون فائدة تشغيلية.

والثالث هو تطبيق نفس العتبات على كلا الطبقتين. تتمتع نقاط النهاية العامة والخاصة بخصائص أداء مختلفة ونطاقات زمن وصول مقبولة مختلفة. يجب أن يكون لمكالمة الخدمة الداخلية التي تبلغ 50 مللي ثانية واستجابة واجهة برمجة التطبيقات العامة 300 مللي ثانية حدود مراقبة مختلفة حتى لو كانت جزءًا من نفس سلسلة الطلب.

والرابع هو إهمال إدارة الاعتماد في تحقيقات المراقبة. تتسبب بيانات اعتماد المراقبة منتهية الصلاحية في تنبيهات انقطاع كاذبة تؤدي إلى تآكل الثقة في نظام المراقبة. ينبغي أتمتة إدارة دورة حياة الاعتماد لأغراض المراقبة ومراجعتها بانتظام.

والخامس هو بناء أنظمة مراقبة منفصلة ومنفصلة لكل طبقة. إذا كانت المراقبة العامة والخاصة موجودة في أدوات مختلفة دون أي ارتباط، فإن الفريق يفقد الفائدة الأكثر قيمة: القدرة على تتبع الحوادث عبر الطبقات وتحديد الأسباب الجذرية بسرعة.

الأفكار النهائية

يتطلب بناء استراتيجية مراقبة واجهة برمجة التطبيقات (API) لنقاط النهاية العامة والخاصة فهم أن هاتين الفئتين تخدمان مستهلكين مختلفين، وتواجهان مخاطر مختلفة، وتتطلبان أساليب وصول مختلفة للمراقبة، ولكن موثوقيتهما مترابطة بعمق.

يجب مراقبة نقاط النهاية العامة خارجيًا من منظور المستهلك من خلال التنوع الجغرافي والمصادقة الواقعية والتحقق من صحة الاستجابة وSLOs التي تتوافق مع التوقعات الخارجية. يجب مراقبة نقاط النهاية الخاصة داخليًا باستخدام مجسات تكرر أنماط اتصالات الإنتاج، وميزانيات زمن الوصول المستمدة من عمليات مستوى الخدمة العامة، والرؤية الواعية بالتبعية التي تربط الصحة الداخلية بالنتائج الخارجية.

تصبح الإستراتيجية أقوى عندما يتم توحيد كلا الطبقتين من خلال لوحات المعلومات المترابطة، والتنبيهات المتصلة، والجداول الزمنية للحوادث المشتركة. هذه الرؤية الموحدة هي ما يسمح للفرق باكتشاف الحوادث بشكل أسرع، وتحديد الأسباب الجذرية عبر الطبقات، والاستجابة بالسياق الكامل بدلاً من المعلومات الجزئية.

إذا كان منتجك يعتمد على واجهات برمجة التطبيقات، ومعظم المنتجات الحديثة تفعل ذلك، فإن مراقبة السطح العام فقط هي مراقبة نصف النظام فقط. إن الفرق التي تبني إستراتيجيات المراقبة التي تغطي نقاط النهاية العامة والخاصة هي التي تمنع معظم الحوادث، وتحلها بشكل أسرع، وتحافظ على أقوى موثوقية شاملة.