דף זה תורגם על ידי Cloud Translation API.

Antipattern: יש להפעיל את מדיניות 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" 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. אם משתמשים בכמה מכללי המדיניות האלה באותו שרת proxy ל-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 ל-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" 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.

קריאה נוספת

מדיניות JavaScript
המדיניות בנושא exportVariables
הפעלת קוד לאחר עיבוד שרת proxy, כולל כאשר מתרחשות תקלות, עם PostClientFlow