एंटीपैटर्न: एपीआई प्रॉक्सी में MessageLogging नीति को कई बार शुरू करें

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

Apigee Edge की MessageLogging नीति, एपीआई प्रॉक्सी डेवलपर को कस्टम मैसेज को syslog या डिस्क (सिर्फ़ निजी क्लाउड के लिए) पर लॉग करने की अनुमति देती है. एपीआई अनुरोध से जुड़ी किसी भी अहम जानकारी, जैसे कि इनपुट पैरामीटर, अनुरोध पेलोड, रिस्पॉन्स कोड, गड़बड़ी के मैसेज (अगर कोई है) वगैरह की जानकारी, बाद में इस्तेमाल करने के लिए या डीबग करने के लिए लॉग की जा सकती है. नीति में डेटा को लॉग करने के लिए, बैकग्राउंड में चलने वाली प्रोसेस का इस्तेमाल किया जाता है. इस दौरान, इस नीति का इस्तेमाल करते समय कुछ चेतावनियों का ध्यान रखना चाहिए.

एंटीपैटर्न

MessageLogging नीति, किसी एपीआई अनुरोध के बारे में ज़्यादा जानकारी पाने का एक बेहतर तरीका है. इससे, एपीआई अनुरोध में आने वाली किसी भी समस्या को डीबग किया जा सकता है. हालांकि, एक से ज़्यादा बार एक ही MessageLogging नीति का इस्तेमाल करने या एक से ज़्यादा MessageLogging नीतियों का इस्तेमाल करने से, PostClientFlow के अलावा, एक ही एपीआई प्रॉक्सी में अलग-अलग फ़्लो में डेटा को अलग-अलग हिस्सों में लॉग करने का बुरा असर हो सकता है. इसकी वजह यह है कि Apigee Edge, MessageLogging नीति के लिए बाहरी syslog सर्वर से कनेक्शन खोलता है. अगर नीति में टीसीपी के बजाय TLS का इस्तेमाल किया जाता है, तो TLS कनेक्शन बनाने के लिए अतिरिक्त खर्च की ज़रूरत होती है.

आइए, उदाहरण के तौर पर एपीआई प्रॉक्सी की मदद से इसे समझाएं.

एपीआई प्रॉक्सी

नीचे दिए गए उदाहरण में, अनुरोध के फ़्लो में "LogRequestInfo" नाम की एक MessageLogging नीति शामिल की गई है. साथ ही, रिस्पॉन्स फ़्लो में, "LogResponseInfo" नाम की एक दूसरी MessageLogging नीति जोड़ी गई है. दोनों प्रॉक्सीEndpoint PreFlow में हैं. आम तौर पर, API प्रॉक्सी को अनुरोध मिलते ही LogRequestInfo नीति बैकग्राउंड में काम करती है. प्रॉक्सी सर्वर को टारगेट सर्वर से जवाब मिलने के बाद, LogResponseInfo नीति लागू होती है. हालांकि, प्रॉक्सी का जवाब एपीआई क्लाइंट को देने से पहले लागू होता है. इससे, सिस्टम के ज़्यादा संसाधनों की खपत होगी, क्योंकि शायद दो TLS कनेक्शन बनाए जा रहे हैं.

इसके अलावा, "LogErrorInfo" नाम की एक MessageLogging नीति. यह सिर्फ़ तब लागू होती है, जब एपीआई प्रॉक्सी को एक्ज़ीक्यूट करने के दौरान कोई गड़बड़ी होती है.

<?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 का इस्तेमाल करके, तीसरे पक्ष के लॉग सर्वर पर लॉग किया जा रहा है. अगर एक ही एपीआई प्रॉक्सी में इनमें से एक से ज़्यादा नीतियों का इस्तेमाल किया जाता है, तो TLS कनेक्शन को सेट अप और मैनेज करने की ज़िम्मेदारी, सिस्टम की ज़्यादा मेमोरी और सीपीयू साइकल का इस्तेमाल करेगी. इस वजह से, परफ़ॉर्मेंस की समस्याएं बड़े पैमाने पर आ सकती हैं.

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 गेटवे टाइम आउट की गड़बड़ियां हो सकती हैं.
  • प्राइवेट क्लाउड सेटअप पर मैसेज प्रोसेसर ने एक साथ कई फ़ाइल डिस्क्रिप्टर खोले, जहां फ़ाइल लॉगिंग का इस्तेमाल किया जाता है.

  • अगर MessageLogging नीति को PostClient फ़्लो के अलावा किसी दूसरे फ़्लो में रखा जाता है, तो हो सकता है कि जानकारी लॉग न की जा सके. इसकी वजह यह है कि अगर इस नीति के लागू होने से पहले कोई गड़बड़ी होती है, तो MessageLogging नीति को लागू नहीं किया जाएगा.

    पिछले प्रॉक्सीEndpoint उदाहरण में, जानकारी को इन स्थितियों में लॉग नहीं किया जाएगा:

    • अगर अनुरोध करने की प्रक्रिया में, LogRequestInfo नीति के पहले बनाई गई कोई भी नीति काम नहीं करती.
      या
    • अगर टारगेट सर्वर किसी गड़बड़ी (एचटीटीपी 4XX, 5XX) के साथ काम नहीं करता. इस स्थिति में, जब कोई नतीजा नहीं मिलता, तो LogResponseInfo नीति लागू नहीं होगी.

    दोनों मामलों में, LogErrorInfo नीति लागू होगी और यह सिर्फ़ गड़बड़ी से जुड़ी जानकारी लॉग करेगी.

सबसे सही तरीका

  • लॉग किए जाने वाले सभी फ़्लो वैरिएबल को सेट करने के लिए, ExtractVariables नीति या JavaScript नीति का इस्तेमाल करें. इससे, उन्हें MessageLogging नीति के लिए उपलब्ध कराने के लिए उपलब्ध कराया जा सकता है.
  • सभी ज़रूरी डेटा को PostClientFlow में लॉग करने के लिए, एक MessageLogging नीति का इस्तेमाल करें, जिसे बिना किसी शर्त के लागू किया जाता है.
  • यूडीपी प्रोटोकॉल का इस्तेमाल करें, जहां syslog सर्वर पर मैसेज की डिलीवरी की गारंटी न हो. साथ ही, TLS/एसएसएल ज़रूरी नहीं है.

MessageLogging नीति को इस तरह डिज़ाइन किया गया है कि इसे एपीआई के असल फ़ंक्शन से अलग किया जा सके. इसमें गड़बड़ी को ठीक करना भी शामिल है. इसलिए, इसे PostClientFlow में शुरू करने के लिए, इसे अनुरोध/रिस्पॉन्स की प्रोसेस से बाहर रखा जाता है. इसका मतलब है कि यह हमेशा डेटा को लॉग करेगा, फिर चाहे एपीआई काम न कर रहा हो या नहीं.

यहां PostClientFlow में MessageLogging नीति को लागू करने का उदाहरण दिया गया है:

<?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 में रिस्पॉन्स वैरिएबल उपलब्ध नहीं होते, इसलिए एक्सट्रैक्ट वैरिएबल या JavaScript नीतियों का इस्तेमाल करके, woeid और weather.response* वैरिएबल को साफ़ तौर पर सेट करना ज़रूरी है.

इसके बारे में और पढ़ें