דפוס אנטי: הפעלה של מדיניות MessageLogging כמה פעמים ב-proxy ל-API

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

מדיניותMessageLogging של Apigee Edge מאפשרת למפתחים של שרת proxy ל-API לרשום הודעות מותאמות אישית syslog או לדיסק (Edge לענן פרטי בלבד). כל מידע חשוב שקשור ל-API בקשות כמו פרמטרים של קלט, מטען ייעודי (payload) של בקשה, קוד תגובה, הודעות שגיאה (אם יש), וכן הלאה, ניתן לתעד אותן לשימוש במועד מאוחר יותר או לצורך ניפוי באגים. למרות שהמדיניות משתמשת ברקע לביצוע הרישום ביומן, יש אזהרות לגבי השימוש במדיניות.

נגד דוגמת עיצוב

מדיניות MessageLogging מספקת דרך יעילה לקבל מידע נוסף על בקשת API וניפוי באגים בכל הבעיות שזוהו בבקשת ה-API. עם זאת, שימוש באותה מדיניות MessageLogging יותר מפעם אחת או שימוש כללי מדיניות MessageLogging רושמים נתונים במקטעים באותו שרת proxy ל-API בתהליכים שאינם ל-PostClientFlow עשויות להיות השלכות שליליות. הסיבה לכך היא ש-Apigee Edge פותח חיבור לשרת Syslog חיצוני עבור מדיניות MessageLogging. אם המדיניות משתמשת ב-TLS באמצעות TCP, יש תקורה נוספת ליצירת חיבור TLS.

נסביר זאת בעזרת דוגמה לשרת Proxy ל-API.

API מסוג proxy

בדוגמה הבאה, מדיניות MessageLogging בשם "LogRequestInfo" נמצא ב תהליך הבקשה, ומדיניות נוספת של MessageLogging בשם "LogResponseInfo" נוסף זרימת תגובה. שניהם נמצאים ב-ProxyEndpoint PreFlow. המדיניות LogRequestInfo מתבצעת ברקע, ברגע ששרת ה-proxy של ה-API מקבל את הבקשה, המדיניות מופעלת אחרי ששרת ה-proxy מקבל תגובה משרת היעד אבל לפני ששרת ה-Proxy מחזיר את התגובה ללקוח ה-API. הפעולה הזו תנצל משאבי מערכת נוספים, מכיוון שהמערכת עלולה ליצור שני חיבורי TLS.

בנוסף, קיימת מדיניות MessageLogging בשם "LogErrorInfo" שמבוצע רק אם מתרחשת שגיאה במהלך ביצוע של שרת ה-proxy ל-API.

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes">?
Proxy<Endpoint n>ame=&<quot;default"
  ...
Fault>Rules
   < Fau>ltRule name=&<quot>;fault-loggi<ng&qu>ot;
     <   St>ep
  <          >N<ameLogError>I<nfo/Name
        /Step>
    </FaultR>ule
/Fa<ultR>ules
PreF<low >name="Pre<Flow&>quot;
 <   Re>quest<
      S>tep<
       > Na<meLogRequestInfo/Name
>     < /Step
 >   /Req<uest>
  /PreFl<ow
 > PreFlow name=&<quot;>PreFlow<">;
   < Response>
  <    Step>
      <  NameLogRespo>nseInfo/Name
      /Step
    /Response
  /PreFlow
  ...
/ProxyEndpoint

מדיניות רישום הודעות

בדוגמאות להגדרות הבאות של המדיניות, הנתונים נרשמים ביומן של צד שלישי שרתי יומנים באמצעות TLS ב-TCP. אם משתמשים בכמה מכללי המדיניות האלה באותו שרת proxy ל-API, התקורה של יצירה וניהול של חיבורי TLS היו בעייתיים את זיכרון המערכת ואת מחזורי המעבד (CPU), מה שמוביל לבעיות בביצועים בקנה מידה נרחב.

המדיניות בנושא LogRequestInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Messag>eLo<gging >name=<"L>ogRequestInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"]< Weather> requ<est >for WOEID {request<.quer>ypara<m.w}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

המדיניות של LogResponseInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Message>Log<ging n>ame=&<quot;Lo>gResponseInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {r<esponse.>statu<s.co>de}, Response {res<ponse>.cont<ent}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

המדיניות בנושא LogErrorInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Mess>age<Loggin>g nam<e=">;LogErrorInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{<environm>ent.n<ame}>"] Fault name<: {fa>ult.n<ame}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bledt<rue/Enabl>e<d
    /SSLInfo
>  /Syslog
  logLevelERROR/logLevel
/MessageLogging

השפעה

  • תקורה מוגברת של הרשתות כתוצאה מיצירת חיבורים לשרתי היומן מרובים במהלך זרימת ה-API ל-Proxy.
  • אם שרת ה-Syslog איטי או לא יכול לטפל בנפח האחסון הגבוה שנגרם על ידי מספר רשתות Syslog שיחות, אז הוא יגרום ללחץ חוזר על מעבד ההודעות, וכתוצאה מכך הבקשה תהיה איטית ובזמן אחזור שעשויים להיות גבוהים, או שגיאות 504 הזמן הקצוב לתפוגה של השער.
  • מספר גדול יותר של תיאורי קבצים בו-זמנית שנפתחו על ידי מעבד ההודעות ב- הגדרות של ענן פרטי שבהן נעשה שימוש ברישום קבצים ביומן.

  • אם מדיניות MessageLogging נמצאת בתהליכים שאינם זרימה של PostClient, יש שייתכן שהמידע לא יירשם ביומן, כי מדיניות MessageLogging לא יבוצע אם יתגלה כשל לפני הרצת המדיניות הזו.

    בדוגמה הקודמת של ProxyEndpoint, המידע לא יהיה רשום בנסיבות הבאות:

    • אם חלים כללי מדיניות כלשהם לפני המדיניות LogRequestInfo תהליך הבקשה נכשל.
      או
    • אם שרת היעד נכשל ומוצגת שגיאה כלשהי (HTTP 4XX, 5XX). במצב כזה, לא תוחזר תגובה מוצלחת, המדיניות LogResponseInfo לא בביצוע.

    בשני המקרים, המדיניות LogErrorInfo תתבצע ותתעד רק את הנתונים שקשורים לשגיאה מידע.

שיטה מומלצת

  • משתמשים במדיניות מופעלת (extractVariables) או במדיניות JavaScript כדי להגדיר את כל הזרימה של המשתנים שנרשמו ביומן, והופכים אותם לזמינים עבור מדיניות MessageLogging.
  • להשתמש במדיניות MessageLogging יחידה כדי לרשום את כל הנתונים הנדרשים ב-PostClientFlow, שמבוצע ללא תנאי.
  • להשתמש בפרוטוקול UDP, שבו לא מובטחת מסירה של הודעות לשרת ה-Syslog נדרש ו-TLS/SSL אינו חובה.

מדיניות MessageLogging נועדה להיות מופרדת מהפונקציונליות של ה-API בפועל, כולל טיפול בשגיאות. לכן, להפעיל אותו ב-PostClientFlow, של עיבוד בקשה/תגובה, פירושו שהוא תמיד יתעד נתונים ללא קשר שה-API נכשל או לא.

הנה דוגמה להפעלת מדיניות MessageLogging ב-PostClientFlow:

<?xml version="1.0" encoding="UTF-8&quo>t; sta<ndalone=">yes"<?
 ...
P>ostClient<Flow
   >     Request/<
   >     Response
   <    >     St<ep
  >             < Name>LogInfo/N<ame
     > <      /Step
   >     /Response
/PostClientFlow
 ...

דוגמה למדיניות MessageLogging, LogInfo, שמתעדת את כל הנתונים:

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?>
Me<ssageL>oggin<g name=>"LogInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Resp<onse {we>ather<.res>ponse}, Fault: {fa<ult.n>ame:N<one}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

כי התגובה משתנים אינם זמינים ב-PostClientFlow בעקבות שגיאה, חשוב כדי להגדיר במפורש משתנים woeid ו-weather.response* באמצעות מדיניות extractVariables או JavaScript.

קריאה נוספת