Antipattern: سیاست MessageLogging را چندین بار در یک پراکسی API فراخوانی کنید، Antipattern: سیاست MessageLogging را چندین بار در یک پراکسی API فراخوانی کنید.

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

سیاست MessageLogging در Apigee Edge به توسعه‌دهندگان API Proxy اجازه می‌دهد پیام‌های سفارشی را در syslog یا دیسک (فقط در Edge برای Private Cloud) ثبت کنند. هرگونه اطلاعات مهم مربوط به درخواست API مانند پارامترهای ورودی، حجم درخواست، کد پاسخ، پیام‌های خطا (در صورت وجود) و غیره، می‌توانند برای مراجعه بعدی یا اشکال‌زدایی ثبت شوند. در حالی که این سیاست از یک فرآیند پس‌زمینه برای انجام ثبت وقایع استفاده می‌کند، اما احتیاط‌هایی در استفاده از این سیاست وجود دارد.

ضدالگو

سیاست MessageLogging روشی کارآمد برای کسب اطلاعات بیشتر در مورد یک درخواست API و اشکال‌زدایی هرگونه مشکلی که با درخواست API مواجه می‌شود، ارائه می‌دهد. با این حال، استفاده بیش از یک بار از یک سیاست MessageLogging یا داشتن چندین سیاست MessageLogging که داده‌های لاگ را به صورت تکه‌ای در یک پروکسی API مشابه در جریان‌هایی غیر از PostClientFlow ثبت می‌کنند، ممکن است پیامدهای نامطلوبی داشته باشد. دلیل این امر این است که Apigee Edge برای یک سیاست MessageLogging، اتصالی به یک سرور syslog خارجی باز می‌کند. اگر این سیاست از TLS روی TCP استفاده کند، سربار اضافی برای ایجاد یک اتصال TLS وجود خواهد داشت.

بیایید این را با کمک یک مثال از API Proxy توضیح دهیم.

پروکسی API

در مثال زیر، یک سیاست MessageLogging با نام "LogRequestInfo" در جریان درخواست (Request flow) قرار می‌گیرد و یک سیاست MessageLogging دیگر با نام "LogResponseInfo" به جریان پاسخ (Response flow) اضافه می‌شود. هر دو در ProxyEndpoint PreFlow قرار دارند. سیاست LogRequestInfo به محض دریافت درخواست توسط پروکسی API در پس‌زمینه اجرا می‌شود و سیاست LogResponseInfo پس از دریافت پاسخ از سرور هدف توسط پروکسی، اما قبل از اینکه پروکسی پاسخ را به کلاینت API برگرداند، اجرا می‌شود. این امر منابع سیستم اضافی را مصرف می‌کند زیرا به طور بالقوه دو اتصال TLS برقرار می‌شود.

علاوه بر این، یک سیاست MessageLogging با نام "LogErrorInfo" وجود دارد که فقط در صورت بروز خطا در هنگام اجرای پروکسی API اجرا می‌شود.

<?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 به سرورهای لاگ شخص ثالث ارسال می‌شوند. اگر بیش از یکی از این سیاست‌ها در یک پروکسی 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>

سیاست 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>

تأثیر

• افزایش سربار شبکه به دلیل برقراری چندین بار اتصال به سرورهای لاگ در طول جریان پروکسی API.
• اگر سرور syslog کند باشد یا نتواند حجم بالای ناشی از چندین فراخوانی syslog را مدیریت کند، باعث ایجاد فشار مضاعف بر پردازنده پیام می‌شود که منجر به پردازش کند درخواست و احتمالاً تأخیر زیاد یا خطاهای 504 Gateway Timeout می‌شود.
• افزایش تعداد توصیف‌گرهای فایل همزمان باز شده توسط پردازشگر پیام در تنظیمات ابر خصوصی که در آنها از ثبت فایل استفاده می‌شود.

• اگر سیاست MessageLogging در جریان‌هایی غیر از جریان PostClient قرار گیرد، این احتمال وجود دارد که اطلاعات ثبت نشوند، زیرا در صورت بروز هرگونه خرابی قبل از اجرای این سیاست، سیاست MessageLogging اجرا نخواهد شد.

  در مثال قبلی ProxyEndpoint ، اطلاعات تحت شرایط زیر ثبت نخواهند شد:

  • اگر هر یک از سیاست‌هایی که در جریان درخواست، قبل از سیاست LogRequestInfo قرار گرفته‌اند، با شکست مواجه شوند.
    یا
  • اگر سرور هدف با هر خطایی (HTTP 4XX، 5XX) از کار بیفتد. در این شرایط، وقتی پاسخ موفقیت‌آمیزی بازگردانده نشود، سیاست LogResponseInfo اجرا نخواهد شد.

  در هر دو مورد، سیاست LogErrorInfo اجرا می‌شود و فقط اطلاعات مربوط به خطا را ثبت می‌کند.

بهترین شیوه

• از یک سیاست ExtractVariables یا سیاست جاوا اسکریپت برای تنظیم تمام متغیرهای جریانی که قرار است ثبت شوند استفاده کنید و آنها را برای سیاست MessageLogging در دسترس قرار دهید.
• از یک سیاست MessageLogging واحد برای ثبت تمام داده‌های مورد نیاز در PostClientFlow استفاده کنید که بدون قید و شرط اجرا می‌شود.
• از پروتکل UDP استفاده کنید، که در آن تضمین تحویل پیام‌ها به سرور syslog مورد نیاز نیست و TLS/SSL اجباری نیست.

سیاست MessageLogging به گونه‌ای طراحی شده است که از عملکرد واقعی API، از جمله مدیریت خطا، جدا باشد. بنابراین، فراخوانی آن در PostClientFlow، که خارج از پردازش درخواست/پاسخ است، به این معنی است که صرف نظر از اینکه API با شکست مواجه شود یا خیر، همیشه داده‌ها را ثبت می‌کند.

در اینجا مثالی از فراخوانی سیاست 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* با استفاده از ExtractVariables یا سیاست‌های جاوا اسکریپت بسیار مهم است.

مطالعه بیشتر

• سیاست جاوا اسکریپت
• سیاست استخراج متغیرها
• اجرای کد پس از پردازش پروکسی، از جمله هنگام بروز خطا، با PostClientFlow