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

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

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

مضادة للأنماط

توفّر سياسةMessageLogging وسيلة فعّالة للحصول على مزيد من المعلومات حول طلب بيانات من واجهة برمجة التطبيقات وتصحيح أي مشاكل تحدث في طلب البيانات من واجهة برمجة التطبيقات. في المقابل، قد تترتّب آثار سلبية في حال استخدام سياسة MessageLogging (المراسلة) نفسها أكثر من مرة أو استخدام بيانات متعدّدة لتسجيل بيانات سياسات MessageLogging في مجموعات داخل خادم وكيل واجهة برمجة التطبيقات نفسه في تدفقات أخرى غير PostClientFlow. ويرجع ذلك إلى أنّ Apigee Edge تفتح اتصالاً بخادم سجلّ نظام خارجي لسياسة MessageLogging. إذا كانت السياسة تستخدم بروتوكول أمان طبقة النقل (TLS) عبر بروتوكول TCP، سيكون هناك أعباء إضافية لإنشاء اتصال بروتوكول أمان طبقة النقل (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. وفي حال استخدام أكثر من سياسة واحدة من هذه السياسات في الخادم الوكيل نفسه لواجهة برمجة التطبيقات، قد يشغل إنشاء اتصالات بروتوكول أمان طبقة النقل وإدارتها المزيد من ذاكرة النظام ودورات وحدة المعالجة المركزية، ما يؤدي إلى حدوث مشاكل في الأداء على نطاق واسع.

سياسة 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، حيث لا يكون التسليم المضمون للرسائل إلى خادم سجلّ النظام مطلوبًا ولا يكون بروتوكول أمان طبقة النقل أو طبقة المقابس الآمنة إلزاميًا.

تم تصميم سياسة 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* بشكل صريح باستخدام سياسات ExitVariables أو سياسات JavaScript.

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