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

यह Apigee Edge का दस्तावेज़ है.
Go to the Apigee X documentation. info

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

गलत तरीका

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

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

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

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

इसके अलावा, "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>

मैसेज लॉगिंग नीति

नीति के कॉन्फ़िगरेशन के इस उदाहरण में, टीसीपी पर टीएलएस का इस्तेमाल करके, तीसरे पक्ष के लॉग सर्वर पर डेटा लॉग किया जा रहा है. अगर एक ही एपीआई प्रॉक्सी में इनमें से एक से ज़्यादा नीतियों का इस्तेमाल किया जाता है, तो टीएलएस कनेक्शन बनाने और मैनेज करने में ज़्यादा समय लगेगा. साथ ही, सिस्टम की ज़्यादा मेमोरी और सीपीयू साइकल इस्तेमाल होंगी. इससे, बड़े पैमाने पर परफ़ॉर्मेंस से जुड़ी समस्याएं हो सकती हैं.

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

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

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

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

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

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

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

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

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

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

यहां LogInfo नाम की MessageLogging नीति का एक उदाहरण दिया गया है. यह नीति, सभी डेटा को लॉग करती है:

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

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