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

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

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

ضد الگو

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

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

پروکسی API

در مثال زیر، یک خط مشی MessageLogging با نام "LogRequestInfo" در جریان درخواست قرار داده شده است و سیاست MessageLogging دیگری با نام "LogResponseInfo" به جریان پاسخ اضافه شده است. هر دو در 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 اضافی را اشغال می‌کند و منجر به مشکلات عملکرد در مقیاس می‌شود.

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

تاثیر

  • افزایش سربار شبکه به دلیل ایجاد چندین بار اتصال به سرورهای گزارش در طول جریان پروکسی 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 یا سیاست های جاوا اسکریپت تنظیم کنید.

در ادامه مطلب