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

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़. जानकारी

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

एंटीपैटर्न

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

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

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

यहां दिए गए उदाहरण में, MessageLogging की नीति "LogRequestInfo" है को इसमें रखा जाता है अनुरोध फ़्लो और "LogResponseInfo" नाम की अन्य MessageLogging नीति को रिस्पॉन्स फ़्लो. दोनों, 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 का इस्तेमाल करके लॉग इन करें. अगर एक ही एपीआई प्रॉक्सी में, इनमें से एक से ज़्यादा नीतियों का इस्तेमाल किया जाता है, तो 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 नीति के अनुसार अगर इस नीति के लागू होने से पहले कोई गड़बड़ी होती है, तो ट्रिगर किया जा सकता है.

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

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

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

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

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

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

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