Antipattern: استدعِ السياسة MessageLogging عدة مرات في خادم وكيل لواجهة برمجة التطبيقات

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

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

نقوش

توفر سياسة تسجيل الرسائل النصية طريقة فعالة للحصول على مزيد من المعلومات حول طلب البيانات من واجهة برمجة التطبيقات وتصحيح أي مشاكل في طلب البيانات من واجهة برمجة التطبيقات ومع ذلك، يؤدي استخدام سياسة تسجيل الرسائل نفسها أكثر من مرة أو إدخال تعديلات بيانات سجلات سياسات MessageLogging في مجموعات داخل الخادم الوكيل نفسه لواجهة برمجة التطبيقات في مسارات بخلاف قد تنتج عن PostClientFlow آثار سلبية. والسبب في ذلك هو فتح اتصال في Apigee Edge. إلى خادم سجلّ نظام خارجي للاطّلاع على سياسة MessageLogging. وإذا كانت السياسة تستخدم بروتوكول أمان طبقة النقل (TLS) عبر بروتوكول التحكم بالنقل، سيكون هناك تكلفة إضافية لإنشاء اتصال من خلال بروتوكول أمان طبقة النقل (TLS).

لنوضّح ذلك بمساعدة مثال على خادم وكيل لواجهة برمجة التطبيقات.

الخادم الوكيل لواجهة برمجة التطبيقات

في المثال التالي، تظهر سياسة MessageLogging المسماة "LogRequestInfo" في قسم مسار الطلب وسياسة MessageLogging أخرى باسم "LogResponseInfo" تتم إضافته إلى مسار الاستجابة كلاهما في ProxyEndpoint PreFlow تنفيذ سياسة LogRequestInfo في الخلفية ما إن يتلقى الخادم الوكيل لواجهة برمجة التطبيقات الطلب، وLogResponseInfo تنفيذ السياسة بعد تلقي الخادم الوكيل استجابة من الخادم الهدف ولكن قبل يعرض الخادم الوكيل الرد على عميل واجهة برمجة التطبيقات. سيستهلك هذا موارد إضافية للنظام نظرًا لاحتمال إنشاء اتصالين لبروتوكول أمان طبقة النقل (TLS).

وبالإضافة إلى ذلك، هناك سياسة MessageLogging المسماة "LogErrorInfo". يتم تنفيذها فقط إذا كان هناك خطأ أثناء تنفيذ الخادم الوكيل لواجهة برمجة التطبيقات.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
  ...
<FaultRules>
    <FaultRule name="fault-logging">
        <Step>
            <Name>LogErrorInfo</Name>
        </Step>
    </FaultRule>
</FaultRules>
<PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>LogRequestInfo</Name>
      </Step>
    </Request>
  </PreFlow>
  <PreFlow name="PreFlow">
    <Response>
      <Step>
        <Name>LogResponseInfo</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

سياسة تسجيل الرسائل

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

سياسة LogRequestInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogRequestInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

سياسة LogResponseInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogResponseInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {response.status.code}, Response {response.content}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

سياسة LogErrorInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogErrorInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Fault name: {fault.name}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>ERROR</logLevel>
</MessageLogging>

التأثير

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

• إذا تم وضع سياسة MessageLogging في تدفقات بخلاف مسار PostClient، فهناك احتمال عدم تسجيل المعلومات، نظرًا لأن سياسة MessageLogging لن يتم تسجيلها في حال حدوث أي إخفاق قبل تنفيذ هذه السياسة.

  في مثال ProxyEndpoint السابق، ستظهر المعلومات في الحالات التالية:

  • إذا كانت أي من السياسات الموضوعة قبل سياسة LogRequestInfo في فشل تدفق الطلب.
    أو
  • في حال تعذُّر الخادم الهدف مع حدوث أي خطأ (HTTP 4XX و5XX). في هذه الحالة، عندما إذا لم يتم عرض استجابة ناجحة، فلن يتم تنفيذ سياسة LogResponseInfo تنفيذه.

  في كلتا الحالتين، سيتم تنفيذ سياسة LogErrorInfo، وستسجّل فقط العمليات المرتبطة بالخطأ المعلومات.

أفضل ممارسة

• يمكنك استخدام سياسة استخراج المتغيّرات أو سياسة JavaScript لضبط العملية بالكامل. المتغيرات التي يتم تسجيلها، مما يجعلها متاحة لسياسة MessageLogging.
• استخدِم سياسة MessageLogging واحدة لتسجيل جميع البيانات المطلوبة في PostClientFlow، يتم تنفيذه دون شروط.
• استخدام بروتوكول UDP، حيث لا يكون التسليم المضمون للرسائل إلى خادم سجل النظام ولا يعتبر بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) إلزامية.

تم تصميم سياسة MessageLogging بشكل منفصل عن الوظائف الفعلية لواجهة برمجة التطبيقات، بما في ذلك معالجة الأخطاء. ومن ثم، يمكن استدعاؤه في PostClientFlow، وهو خارج معالجة الطلب/الاستجابة، يعني أنها ستقوم دائمًا بتسجيل البيانات بغض النظر عن فشل واجهة برمجة التطبيقات أم لا.

في ما يلي مثال لاستدعاء سياسة MessageLogging في PostClientFlow:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 ...
<PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>LogInfo</Name>
            </Step>
        </Response>
</PostClientFlow>
 ...

في ما يلي مثال على سياسة MessageLogging، وهي LogInfo التي تُسجل جميع البيانات:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Response {weather.response}, Fault: {fault.name:None}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

لأنّ الاستجابة المختلفة في PostClientFlow بعد تدفق خطأ، فمن المهم لضبط متغيّري woeid وweather.response* بشكل صريح باستخدام سياسات استخراج المتغيّرات أو JavaScript

محتوى إضافي للقراءة

• سياسة JavaScript
• سياسة استخراج المتغيّرات
• تنفيذ التعليمات البرمجية بعد معالجة الخادم الوكيل، بما في ذلك عند حدوث أخطاء، مع PostClientFlow