অ্যান্টিপ্যাটার্ন: এপিআই প্রক্সিতে একাধিকবার মেসেজলগিং নীতি চালু করুন, অ্যান্টিপ্যাটার্ন: এপিআই প্রক্সিতে একাধিকবার মেসেজলগিং নীতি চালু করুন

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

Apigee Edge-এর MessageLogging পলিসি API Proxy ডেভেলপারদের syslog-এ অথবা ডিস্কে (শুধুমাত্র Edge for Private Cloud-এর জন্য) কাস্টম মেসেজ লগ করার সুযোগ দেয়। API অনুরোধ সম্পর্কিত যেকোনো গুরুত্বপূর্ণ তথ্য, যেমন ইনপুট প্যারামিটার, অনুরোধ পেলোড, প্রতিক্রিয়া কোড, ত্রুটির বার্তা (যদি থাকে), ইত্যাদি পরবর্তী রেফারেন্স বা ডিবাগিংয়ের জন্য লগ করা যেতে পারে। যদিও এই পলিসিটি লগিং করার জন্য একটি ব্যাকগ্রাউন্ড প্রসেস ব্যবহার করে, তবে এটি ব্যবহারের কিছু সীমাবদ্ধতা রয়েছে।

অ্যান্টিপ্যাটার্ন

MessageLogging পলিসি একটি API অনুরোধ সম্পর্কে আরও তথ্য পেতে এবং সেই অনুরোধে উদ্ভূত যেকোনো সমস্যা ডিবাগ করার একটি কার্যকর উপায় প্রদান করে। তবে, একই MessageLogging পলিসি একাধিকবার ব্যবহার করা অথবা PostClientFlow ব্যতীত অন্য ফ্লো-তে একই API প্রক্সিতে একাধিক MessageLogging পলিসিকে খণ্ডে খণ্ডে ডেটা লগ করতে দেওয়া বিরূপ প্রভাব ফেলতে পারে। এর কারণ হলো, Apigee Edge একটি MessageLogging পলিসির জন্য একটি বাহ্যিক syslog সার্ভারের সাথে সংযোগ স্থাপন করে। যদি পলিসিটি TCP-এর উপর TLS ব্যবহার করে, তবে একটি TLS সংযোগ স্থাপনের জন্য অতিরিক্ত ওভারহেড তৈরি হয়।

চলুন একটি উদাহরণ এপিআই প্রক্সির সাহায্যে বিষয়টি ব্যাখ্যা করা যাক।

এপিআই প্রক্সি

নিম্নলিখিত উদাহরণে, "LogRequestInfo" নামের একটি MessageLogging পলিসি Request ফ্লো-তে রাখা হয়েছে, এবং "LogResponseInfo" নামের আরেকটি MessageLogging পলিসি Response ফ্লো-তে যোগ করা হয়েছে। উভয়ই ProxyEndpoint PreFlow-তে রয়েছে। API প্রক্সি অনুরোধটি গ্রহণ করার সাথে সাথেই LogRequestInfo পলিসিটি ব্যাকগ্রাউন্ডে কার্যকর হয়, এবং LogResponseInfo পলিসিটি প্রক্সি টার্গেট সার্ভার থেকে প্রতিক্রিয়া পাওয়ার পরে কিন্তু API ক্লায়েন্টকে প্রতিক্রিয়া ফেরত পাঠানোর আগে কার্যকর হয়। এতে অতিরিক্ত সিস্টেম রিসোর্স ব্যবহৃত হবে, কারণ এক্ষেত্রে দুটি 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>

বার্তা লগিং নীতি

নিম্নলিখিত উদাহরণ পলিসি কনফিগারেশনগুলিতে, TCP-এর উপর TLS ব্যবহার করে ডেটা তৃতীয় পক্ষের লগ সার্ভারগুলিতে লগ করা হচ্ছে। যদি একই API প্রক্সিতে এই পলিসিগুলির একাধিক ব্যবহার করা হয়, তাহলে TLS সংযোগ স্থাপন এবং পরিচালনার অতিরিক্ত কাজ সিস্টেম মেমরি এবং CPU সাইকেল দখল করবে, যা বৃহৎ পরিসরে পারফরম্যান্স সমস্যা তৈরি করবে।

লগ অনুরোধ তথ্য নীতি

<?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>

লগরেসপন্সইনফো নীতি

<?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>

লগএররইনফো নীতি

<?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>

প্রভাব

  • এপিআই প্রক্সি ফ্লো চলাকালীন লগ সার্ভারগুলোর সাথে একাধিকবার সংযোগ স্থাপন করার কারণে নেটওয়ার্কিং ওভারহেড বৃদ্ধি পায়।
  • যদি সিসলগ সার্ভারটি ধীরগতির হয় অথবা একাধিক সিসলগ কলের কারণে সৃষ্ট বিপুল পরিমাণ ডেটা সামলাতে না পারে, তাহলে এটি মেসেজ প্রসেসরের উপর বিপরীত চাপ সৃষ্টি করবে, যার ফলে অনুরোধ প্রক্রিয়াকরণ ধীর হয়ে যাবে এবং সম্ভাব্য উচ্চ ল্যাটেন্সি বা ৫০৪ গেটওয়ে টাইমআউট ত্রুটি দেখা দেবে।
  • যেসব প্রাইভেট ক্লাউড সেটআপে ফাইল লগিং ব্যবহার করা হয়, সেখানে মেসেজ প্রসেসর দ্বারা একই সাথে খোলা ফাইল ডেসক্রিপ্টরের সংখ্যা বৃদ্ধি পেয়েছে।

  • যদি MessageLogging পলিসিটি PostClient ফ্লো ছাড়া অন্য কোনো ফ্লোতে স্থাপন করা হয়, তাহলে তথ্য লগ না হওয়ার সম্ভাবনা থাকে, কারণ এই পলিসিটি কার্যকর হওয়ার আগে কোনো ব্যর্থতা ঘটলে MessageLogging পলিসিটি কার্যকর হবে না।

    পূর্ববর্তী ProxyEndpoint উদাহরণে , নিম্নলিখিত পরিস্থিতিতে তথ্য লগ করা হবে না:

    • অনুরোধ প্রবাহে LogRequestInfo পলিসির আগে থাকা কোনো পলিসি ব্যর্থ হলে।
      অথবা
    • যদি টার্গেট সার্ভার কোনো ত্রুটির (HTTP 4XX, 5XX) কারণে ব্যর্থ হয়, এবং এই পরিস্থিতিতে কোনো সফল প্রতিক্রিয়া ফেরত না আসে, তাহলে LogResponseInfo পলিসিটি কার্যকর হবে না।

    উভয় ক্ষেত্রেই, LogErrorInfo পলিসিটি কার্যকর হবে এবং শুধুমাত্র ত্রুটি-সম্পর্কিত তথ্য লগ করবে।

সর্বোত্তম অনুশীলন

  • লগ করার জন্য সমস্ত ফ্লো ভেরিয়েবল সেট করতে একটি ExtractVariables পলিসি অথবা JavaScript পলিসি ব্যবহার করুন, যাতে সেগুলি MessageLogging পলিসির জন্য উপলব্ধ হয়।
  • PostClientFlow-তে সমস্ত প্রয়োজনীয় ডেটা লগ করার জন্য একটিমাত্র MessageLogging পলিসি ব্যবহার করুন, যা শর্তহীনভাবে কার্যকর হয়।
  • UDP প্রোটোকল ব্যবহার করুন, যেখানে syslog সার্ভারে বার্তার নিশ্চিত ডেলিভারির প্রয়োজন হয় না এবং TLS/SSL বাধ্যতামূলক নয়।

MessageLogging পলিসিটি ত্রুটি পরিচালনা সহ প্রকৃত API কার্যকারিতা থেকে বিচ্ছিন্ন রাখার জন্য ডিজাইন করা হয়েছিল। তাই, অনুরোধ/প্রতিক্রিয়া প্রক্রিয়াকরণের বাইরে থাকা PostClientFlow-তে এটিকে কল করার অর্থ হলো, API ব্যর্থ হয়েছে কি না তা নির্বিশেষে এটি সর্বদা ডেটা লগ করবে।

PostClientFlow-তে MessageLogging Policy প্রয়োগ করার একটি উদাহরণ নিচে দেওয়া হলো:

<?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>

যেহেতু একটি Error Flow-এর পরে PostClientFlow-তে response variables উপলব্ধ থাকে না, তাই ExtractVariables অথবা JavaScript policies ব্যবহার করে woeid এবং weather.response* ভেরিয়েবলগুলো সুস্পষ্টভাবে সেট করা গুরুত্বপূর্ণ।

আরও পড়ুন