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

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info

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

ممارسة غير مستحسنة

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

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

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

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

بالإضافة إلى ذلك، هناك سياسة 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>

سياسة MessageLogging

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

سياسة 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>

التأثير

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

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

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

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

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

أفضل ممارسة

  • استخدِم سياسة ExtractVariables أو سياسة JavaScript لضبط جميع متغيّرات المسار التي سيتم تسجيلها، ما يتيح استخدامها في سياسة MessageLogging.
  • استخدِم سياسة MessageLogging واحدة لتسجيل جميع البيانات المطلوبة في PostClientFlow، الذي يتم تنفيذه بدون شروط.
  • استخدِم بروتوكول UDP، حيث لا يكون التسليم المضمون للرسائل إلى خادم syslog مطلوبًا ولا يكون بروتوكول أمان طبقة النقل (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* بشكلٍ صريح باستخدام سياسات ExtractVariables أو JavaScript.

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