המדיניות בנושא רישום הודעות ביומן

מדיניות ניתנת להרחבה

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

המדיניות MessageLogging מאפשרת לכם לרשום ביומן הודעות מותאמות אישית ב-Cloud Logging או ב-syslog. אתם יכולים להשתמש במידע שביומנים למשימות שונות, כמו איתור בעיות בסביבת זמן הריצה של ה-API.

המדיניות הזו היא מדיניות שניתנת להרחבה, והשימוש בה עשוי להשפיע על העלויות או על הניצול, בהתאם לרישיון שלכם ל-Apigee. למידע על סוגי מדיניות והשלכות השימוש, אפשר לעיין במאמר בנושא סוגי מדיניות.

יש שתי דרכים להשתמש במדיניות MessageLogging:

• רכיב <CloudLogging> מתעד הודעות ב-Logging. כדי להשתמש בשיטה הזו, צריך להפעיל את Cloud Logging API בפרויקט Google Cloud . למידע נוסף על הפעלת ממשקי API בפרויקט Google Cloud , אפשר לעיין במאמר הפעלה והשבתה של שירותים.
• רכיב <Syslog> מתעד הודעות ב-syslog, פרוטוקול סטנדרטי לשליחת יומן מערכת או הודעות אירוע לשרת ספציפי. כדי להשתמש בשיטה הזו, צריך שיהיה שרת syslog זמין. אם אין לכם שרת כזה, אתם יכולים להשתמש בשירותים ציבוריים לניהול יומנים, כמו Splunk,‏ Sumo Logic ו-Loggly. מידע נוסף זמין במאמר בנושא הגדרת שירותים לניהול יומנים של צד שלישי.

הערה: אי אפשר להשתמש גם ברכיב <CloudLogging> וגם ברכיב <Syslog> באותה מדיניות.

רכיב <MessageLogging>

הגדרה של מדיניות <MessageLogging>.

ערך ברירת המחדל	מידע נוסף מופיע בכרטיסייה מדיניות ברירת המחדל שבהמשך
חובה?	חובה
סוג	סוג
רכיב אב	לא רלוונטי
רכיבי צאצא	<CloudLogging> <Syslog> <logLevel>

רכיב <MessageLogging> משתמש בתחביר הבא:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging continueOnError="false" enabled="true" name="Message-Logging-1">
    <DisplayName>Message Logging-1</DisplayName>
    <Syslog>
<!-- Note: You cannot use both the <Syslog> element and the <CloudLogging> element in the same policy. -->
        <Message>Some message for syslog</Message>
        <Host>localhost</Host>
        <Port>514</Port>
    </Syslog>
    <CloudLogging>
<!-- Note: You cannot use both the <CloudLogging> and the <Syslog> element in the same policy. -->
        <LogName>projects/{organization.name}/logs/{log.id}</LogName>
        <Message contentType="application/json">{"{message.queryparam.key}": "{message.queryparam.value}"}</Message>
        <Labels>
            <Label>
                <Key>key1</Key>
                <Value>value1</Value>
            </Label>
            <Label>
                <Key>key2</Key>
                <Value>value2</Value>
            </Label>
        </Labels>
        <ResourceType>api</ResourceType>
        <Endpoint>regional-endpoint</Endpoint>
    </CloudLogging>
    <logLevel>ALERT</logLevel>
</MessageLogging>

לרכיב הזה יש את המאפיינים הבאים שמשותפים לכל המדיניות:

מאפיין	ברירת מחדל	חובה?	תיאור
name	לא רלוונטי	חובה	השם הפנימי של המדיניות. הערך של מאפיין name יכול להכיל אותיות, מספרים, רווחים, מקפים, קווים תחתונים ונקודות. הערך הזה לא יכול להיות ארוך מ-255 תווים. אפשר להשתמש ברכיב <DisplayName> כדי לתת למדיניות תווית בשם אחר בשפה טבעית בכלי לעריכת פרוקסי בממשק המשתמש לניהול.
continueOnError	FALSE	אופציונלי	מגדירים את הערך false כדי להחזיר שגיאה אם המדיניות נכשלת. זו התנהגות צפויה ברוב המקרים. הגדרה ל-true מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים: הפעלת כללי תקלות מתבצעת רק במצב שגיאה (מידע על continueOnError) טיפול בתקלות בתהליך הנוכחי
enabled	TRUE	אופציונלי	מגדירים את הערך true כדי לאכוף את המדיניות, או את הערך false כדי להשבית את המדיניות. המדיניות לא נאכפת גם אם היא עדיין משויכת לזרימה.
async	FALSE	הוצא משימוש	המאפיין הזה הוצא משימוש.

בטבלה הבאה מפורטים רכיבי המשנה של <MessageLogging>:

שם השדה	תיאור השדה
CloudLogging	הגדרת רישום הודעות ב-Cloud Logging.
Syslog	הגדרת ההודעות כך שיירשמו ביומן ב-syslog.

דוגמאות

CloudLogging

<MessageLogging name="LogToCloudLogging">
    <CloudLogging>
        <LogName>projects/{organization.name}/logs/{log.id}</LogName>
        <Message contentType="application/json">{"{message.queryparam.key}": "{message.queryparam.value}"}</Message>
        <Labels>
            <Label>
                <Key>key1</Key>
                <Value>value1</Value>
            </Label>
            <Label>
                <Key>key2</Key>
                <Value>value2</Value>
            </Label>
        </Labels>
        <ResourceType>api</ResourceType>
        <Endpoint>logging.us.rep.googleapis.com:443</Endpoint>
    </CloudLogging>
</MessageLogging>

בדוגמה הזו מוצג שימוש ב תבניות של הודעות. ‫Since the Message element contains the flow variables

{"{message.queryparam.key}": "{message.queryparam.value}"}

כשמישהו מתקשר לשרת ה-proxy עם הערכים message.queryparam.key = "fruit" ו- message.queryparam.value = "apple", רשומת היומן שתתקבל תהיה {"fruit": "apple"}.

Syslog

<MessageLogging name="LogToSyslog">
  <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>514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <DateFormat>yyMMdd-HH:mm:ss.SSS</DateFormat>
  </Syslog>
  <logLevel>ALERT</logLevel>
</MessageLogging>

בדוגמה הזו, נניח שאתם צריכים לרשום ביומן מידע על כל הודעת בקשה שממשק ה-API מקבל מאפליקציות צרכניות. הערך 3f509b58 מייצג ערך מפתח ספציפי לשירות loggly. אם יש לכם חשבון Loggly, מחליפים את מפתח Loggly. הודעת היומן שנוצרת תאוכלס בארבעה ערכים: הארגון, ה-API proxy ושם הסביבה שמשויכים לעסקה, יחד עם הערך של פרמטר שאילתה בהודעת הבקשה. הפורמט של חותמות הזמן יהיה דומה ל-230704-13:42:17.376, בהתאם לפורמט שצוין ברכיב DateFormat.

הערה: אי אפשר להפנות למשתנים ברכיבי Host ו-Port. הם חייבים להכיל ערכים סטטיים.

Syslog באמצעות TLS/SSL

<MessageLogging name="LogToSyslog">
  <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>WARN</logLevel>
</MessageLogging>

אתם יכולים לשלוח הודעות לספקי רישום הודעות של צד שלישי באמצעות TLS/SSL על ידי הוספת הבלוק <SSLInfo>.

הפניה לרכיב צאצא

בקטעים הבאים מתוארים רכיבי הצאצא של <MessageLogging>.

<CloudLogging>

משתמשים ברכיב <CloudLogging> כדי לרשום הודעות ביומן ב-Cloud Logging.

הערה: כדי להשתמש ב-<CloudLogging>, צריך להפעיל את Cloud Logging API בפרויקט Google Cloud . במאמר הפעלה והשבתה של שירותים מוסבר איך להפעיל ממשקי API בפרויקט ב- Google Cloud . רכיב <CloudLogging> של מדיניות MessageLogging זמין בגרסה 1.7.0 ואילך של Apigee ו-Apigee Hybrid.

שם השדה	חובה?	תיאור
LogName	כן	שם היומן. שם היומן צריך להיות בפורמט projects/{PROJECT_ID}/logs/{LOG_ID}. אפשר להשתמש במשתנים במקום ב-{PROJECT_ID} וב-{LOG_ID}. הערה: LogName מציין את שם המשאב של יומן Cloud Logging שאליו יישלח רשומה ביומן. באמצעות משתנים, כלל המדיניות MessageLogging מאפשר להוסיף באופן דינמי ערך שם שונה וייחודי לכל רשומה של LogName. עם זאת, אנחנו לא ממליצים על השיטה הזו, ולא מומלץ ליצור באופן דינמי שמות יומנים ייחודיים עם ערכים שיכולים להשתנות מבקשה לבקשה, כי זה עלול לגרום לבעיות של קרדינליות גבוהה. במקום זאת, מומלץ להשתמש בשם קבוע ובעל משמעות מתוך קבוצה קבועה של שמות עבור LogName.
Message	כן	ההודעה שרוצים לרשום ביומן. להודעה יש מאפיין contentType, שהערך שלו יכול להיות text/plain או application/json עבור הודעות טקסט ו-JSON בהתאמה. דוגמאות הערה: משתני התגובה לא יהיו זמינים ב-PostClientFlow אחרי Error Flow. שימוש ב-message. כדי לרשום ביומן מידע על תגובות במצבים של שגיאה ושל הצלחה. מידע נוסף זמין במאמר בנושא הערות שימוש. הערה: רכיב <Message> תומך בתכונה של החלפת מחרוזות דינמיות שנקראת תבניות הודעות.
Label	לא	תווית לצירוף להודעת היומן, אם יש כזו. התוויות יהיו בפורמט של צמד מפתח/ערך כמו בדוגמה הבאה: <Label> <Key>key1</Key> <Value>value1</Value> </Label>
ResourceType	לא (ברירת המחדל היא כללית)	מייצג את המשאב במעקב שמייצר את היומנים.

אימות ב-Cloud Logging

כדי להשתמש ברכיב <CloudLogging>, צריך לפרוס את ה-proxy ל-API כך שישתמש באימות של Google. ‫Apigee ישתמש בפרטי כניסה שמתאימים לזהות של חשבון השירות שציינתם בבקשות היוצאות אל Cloud Logging. לפרטים נוספים, ראו שימוש באימות של Google.

לחשבון השירות שמצורף ל-proxy ל-API בזמן הפריסה צריך להיות תפקיד עם ההרשאה logging.logEntries.create. אלא אם אתם צריכים שליטה מדויקת יותר, מומלץ להשתמש בתפקיד המוגדר מראש roles/logging.logWriter לחשבון השירות. למידע נוסף על תפקידים בניהול זהויות והרשאות גישה (IAM) ב-<CloudLogging>, אפשר לעיין במדריך בקרת הגישה.

אזהרה: אם משביתים את חשבון השירות שמשמש לתעבורת זמן ריצה של API, ‏ Cloud Logging מפסיק לפעול. במקרה כזה, התנועה בזמן הריצה של ה-API ממשיכה לעבור עיבוד כרגיל, אבל לא מדווחים על שגיאות או התראות ברישום ביומן. חשוב לוודא שחשבון השירות נשאר פעיל ושיש לו את ההרשאות הנדרשות לכתיבה ב-Cloud Logging.

פריסת שרת proxy ב-Apigee Hybrid

אם משתמשים ב-Hybrid, חשבון השירות של זמן הריצה שיוצרים עבור Hybrid צריך להתחזות לחשבון השירות של ה-proxy כדי לבצע קריאות מאומתות בשמו. לכן, לחשבון השירות של זמן הריצה של Hybrid צריך להיות התפקיד iam.serviceAccountTokenCreator בחשבון השירות של ה-proxy.

<Syslog>

משתמשים ברכיב <Syslog> כדי להגדיר את ההודעות שיירשמו ביומן ב-syslog. כשמשתמשים ב-<Syslog>, שרת proxy ל-API מעביר הודעות יומן מ-Apigee לשרת syslog מרוחק. כדי להשתמש בשיטה הזו, צריך שיהיה שרת syslog זמין. אם אין לכם, תוכלו להשתמש בשירותים ציבוריים לניהול יומנים כמו Splunk,‏ Sumo Logic ו-Loggly. מידע נוסף זמין במאמר בנושא הגדרת שירותים לניהול יומנים של צד שלישי.

שם השדה	חובה?	תיאור השדה
Message	כן	ההודעה שרוצים לרשום ביומן. להודעה יש מאפיין contentType, שהערך שלו יכול להיות text/plain או application/json עבור הודעות טקסט ו-JSON בהתאמה. דוגמאות הערה: ה<Message>רכיב תומך בתכונה של החלפת מחרוזות דינמיות שנקראת תבנוּת הודעות. הערה: משתני התגובה לא יהיו זמינים ב-PostClientFlow אחרי Error Flow. שימוש ב-message. כדי לרשום ביומן מידע על תגובות במצבים של שגיאה ושל הצלחה. מידע נוסף זמין במאמר בנושא הערות שימוש.
Host	לא	שם המארח או כתובת ה-IP של השרת שאליו צריך לשלוח את ה-syslog. אם לא כוללים את הרכיב הזה, ברירת המחדל היא localhost.
Port	לא	היציאה שבה פועל syslog. אם לא כוללים את הרכיב הזה, ברירת המחדל היא 514.
Protocol	לא	‫TCP או UDP (ברירת מחדל). פרוטוקול UDP מספק ביצועים טובים יותר, אבל פרוטוקול TCP מבטיח שהודעות יועברו ליומן הרישום בשרת syslog. לשליחת הודעות syslog ב-TLS/SSL, נתמך רק TCP.
FormatMessage	לא, אבל נדרש <FormatMessage>true</FormatMessage> כדי להשתמש ב-Loggly.	‫true או false (ברירת מחדל) האלמנט הזה מאפשר לכם לשלוט בפורמט של תוכן שנוצר על ידי Apigee ומוסף לפני ההודעה. אם המדיניות מוגדרת כ-True, לפני הודעת ה-syslog מופיע מספר קבוע של תווים, שמאפשר לכם לסנן את המידע הזה מההודעות. דוגמה לפורמט הקבוע: <14>1 2023-03-20T09:24:39.039+0000 e49cd3a9-4cf6-48a7-abb9-7ftfe4d97d00 Apigee - - - Message starts here המידע שנוצר על ידי Apigee כולל: ‫<14> – ציון עדיפות (ראו Syslog Protocol) שמבוסס על רמת היומן ורמת המתקן של ההודעה. ‫1 – גרסת ה-syslog הנוכחית. תאריך עם קיזוז ל-UTC‏ (UTC = +0000). מזהה ייחודי אוניברסלי (UUID) של מעבד ההודעות. ‫"Apigee - - - " אם המדיניות מוגדרת כ-false (ברירת מחדל), התווים הקבועים האלה לא יתווספו בתחילת ההודעה. הערה: אם מגדירים את הערך <FormatMessage>false</FormatMessage>, הודעת היומן עדיין כוללת את ציון העדיפות ואת התאריך. כדי לעצב את הודעת היומן כך שתכלול רק את גוף ההודעה, מגדירים את <PayloadOnly>true</PayloadOnly>. ראו PayloadOnly.
PayloadOnly	לא	‫true או false (ברירת מחדל) הרכיב הזה מגדיר את הפורמט של הודעות שנוצרות על ידי Apigee כך שיכילו רק את גוף ההודעה של syslog, בלי התווים שנוספו בתחילת ההודעה שצוינו על ידי FormatMessage. אם לא כוללים את הרכיב הזה או משאירים אותו ריק, ערך ברירת המחדל הוא false. FormatMessage הערה: הגדרה של <PayloadOnly>true</PayloadOnly> מבטלת את ההגדרה של FormatMessage.
DateFormat	לא	מחרוזת תבנית עיצוב שמשמשת לעיצוב חותמת הזמן של כל הודעת יומן. כברירת מחדל, Apigee משתמש ב-yyyy-MM-dd'T'HH:mm:ss.SSSZ. אופן הפעולה של התבנית הזו מתואר במסמכי התיעוד של המחלקת SimpleDateFormat של Java. לפי ההגדרה הזו, yyyy במחרוזת הפורמט יוחלף בשנה בת 4 ספרות, MM יוחלף במספר החודש בן 2 הספרות וכן הלאה.
SSLInfo	לא	מאפשר לכם לרשום הודעות ביומן באמצעות SSL/TLS. שימוש עם רכיב המשנה <Enabled>true</Enabled>. אם לא כוללים את הרכיב הזה או משאירים אותו ריק, ערך ברירת המחדל הוא false (ללא TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> אפשר להגדיר את התג <SSLInfo> באותו אופן שבו מגדירים אותו ב-TargetEndpoint, כולל הפעלת TLS/SSL דו-כיווני, כפי שמתואר בהפניה להגדרת proxy ל-API. יש תמיכה רק בפרוטוקול TCP.

<logLevel>

הערכים התקפים לרכיב <logLevel> הם: INFO (ברירת מחדל), ALERT, WARN, ERROR.

מגדירה רמה ספציפית של מידע שייכלל ביומן ההודעות.

אם משתמשים ברכיב FormatMessage (ומגדירים אותו כ-true), ההגדרה <logLevel> משפיעה על ניקוד העדיפות המחושב (המספר בתוך הסוגריים הזוויתיים) במידע שנוצר על ידי Apigee ומצורף בתחילת ההודעה.

הערות לגבי השימוש

כשמצרפים מדיניות MessageLogging לזרימת proxy ל-API, מומלץ למקם אותה בתגובת ProxyEndpoint, בזרימה מיוחדת שנקראת PostClientFlow. הזרימה PostClientFlow מופעלת אחרי שהתגובה נשלחת ללקוח ששלח את הבקשה, וכך מוודאים שכל המדדים זמינים לרישום ביומן. פרטים על השימוש ב-PostClientFlow מופיעים במאמר הפניה להגדרת proxy ל-API.

הערה: חשוב לציין שהמשתנה של זרימת התגובה לא זמין ב-PostClientFlow אחרי שהעיבוד עובר למצב שגיאה. במקום זאת, אפשר להשתמש במשתנה message כדי להגדיר ערכים במדיניות MessageLogging ב-PostClientFlow, וכך לוודא שהערכים יוגדרו בין אם מצב השגיאה היה ההקשר הקודם ובין אם לא. מידע נוסף ודוגמאות זמינים במאמר חומר עזר בנושא משתני זרימה.

ה-PostClientFlow הוא מיוחד בשתי דרכים:

1. היא מופעלת רק כחלק מתהליך התגובה.
2. זהו התהליך היחיד שמופעל אחרי שה-proxy עובר למצב שגיאה.

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

בתמונה הבאה של כלי הניפוי באגים מוצגת מדיניות MessageLogging שמופעלת כחלק מה-PostClientFlow, אחרי הפעלת DefaultFaultRule:

בדוגמה הזו, המדיניות Verify API Key (אימות מפתח API) גרמה לשגיאה בגלל מפתח לא תקין.

בהמשך מוצגת ההגדרה של ProxyEndpoint שכוללת את PostClientFlow:

<ProxyEndpoint name="default">
  ...
  <PostClientFlow>
    <Response>
      <Step>
        <Name>Message-Logging-1</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

הודעות ביומנים של Apigee נרשמות כטקסט פשוט, ואפשר להגדיר את הרישום ביומן כך שיכלול משתנים, כמו: התאריך והשעה שבהם הבקשה או התגובה התקבלו, זהות המשתמש בבקשה, כתובת ה-IP של המקור שממנו נשלחה הבקשה וכן הלאה.

הודעות ביומנים של Apigee נרשמות באופן אסינכרוני: התשובה מוחזרת בזמן שהיומנים עדיין נכתבים. כתוצאה מכך, חסימת קריאות לא מוסיפה זמן אחזור ל-API. יכול להיות שיהיו מקרים שבהם יומן לא ייכתב בלי שתחזור שגיאה, אבל האירועים האלה נדירים.

המדיניות MessageLogging כותבת הודעות שנרשמו ביומן בזיכרון למאגר זמני. כלי הרישום של ההודעות קורא הודעות מהמאגר ואז כותב ליעד שהגדרתם. לכל יעד יש מאגר משלו.

הערה: שיחות דרך שרת proxy מצליחות גם אם הרישום נכשל

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

אם קצב הכתיבה למאגר גדל מעבר לקצב הקריאה, מתרחשת גלישה במאגר והרישום ייכשל. אם זה קורה, יכול להיות שאחת מההודעות הבאות תופיע בקובץ היומן:

• שימוש ב-<CloudLogging>:

  steps.messagelogging.TooManyPendingLoggingRequest

• שימוש ב-<Syslog>:

  Log message size exceeded. Increase the max message size setting

מגדילים את המאפיין max.log.message.size.in.kb (ערך ברירת המחדל = 128KB) בקובץ message-logging.properties.

הערה: המשתנים של הודעת התגובהב-Apigee לא זמינים מתוך Error Flow. המשתנים האלה לא זמינים גם ב-PostClientFlow אם התהליך הקודם היה Error Flow. אם רוצים לרשום ביומן את פרטי התשובה מ-PostClientFlow, משתמשים ב-message. אפשר להשתמש באובייקט הזה כדי לקבל כותרות ומידע אחר מהתשובה, בין אם הייתה שגיאה ובין אם לא. מידע נוסף ודוגמה זמינים במאמר הפניה למשתני זרימה.

ערכי ברירת מחדל למשתנים בתבנית הודעה

אפשר לציין ערכי ברירת מחדל לכל משתנה בתבנית ההודעה בנפרד. לדוגמה, אם אי אפשר לפתור את המשתנה request.header.id, הערך שלו מוחלף בערך unknown.

<Message>This is a test message. id = {request.header.id:unknown}</Message>

אפשר לציין ערך ברירת מחדל משותף לכל המשתנים שלא נפתרו על ידי הגדרת המאפיין defaultVariableValue ברכיב Message:

<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>

הערה: ערך ברירת המחדל של המשתנה לא יכול לכלול רווחים.

הגדרה של שירותי ניהול יומנים של צד שלישי

מדיניות MessageLogging מאפשרת לשלוח הודעות syslog לשירותי ניהול יומנים של צד שלישי, כמו Splunk,‏ Sumo Logic ו-Loggly. אם רוצים לשלוח syslog לאחד מהשירותים האלה, צריך לעיין בתיעוד של השירות כדי להגדיר את המארח, היציאה והפרוטוקול של השירות, ואז להגדיר את רכיב ה-Syslog במדיניות בהתאם.

מידע על הגדרת ניהול יומנים של צד שלישי זמין במאמרי העזרה הבאים:

• ‫Splunk (צריך לבחור את גרסת המוצר)
  אפשר גם לעיין בפוסט הזה בקהילת Apigee: Log messages into Splunk
• Sumo Logic
  • כדאי גם לעיין בפוסט הזה בקהילת Apigee: הגדרת רישום ביומן באמצעות Sumo Logic
  • דוגמה מלאה לשימוש ב-Sumo Logic כשירות רישום ביומן מופיעה בפוסט הבא בקהילת Apigee. הפתרון משתמש במדיניות JavaScript אחת כדי לבצע בקשות HTTP POST אל Sumo Logic HTTP Source Collector: Logging to Sumo Logic using JavaScript and HTTP
• ‫Loggly
  כשמשתמשים ב-Loggly, צריך להשתמש ב-<FormatMessage>true</FormatMessage> במדיניות כרכיב צאצא של רכיב <Syslog>.
  מידע נוסף על רישום הודעות ב-Loggly זמין גם בפוסט הזה בקהילת Apigee:‏ רישום הודעות ב-Loggly

הפניה לשגיאה

בקטע הזה מתוארים קודי התקלה והודעות השגיאה שמוחזרים, ומשתני התקלה שמוגדרים על ידי Apigee כשמדיניות כזו מפעילה שגיאה. חשוב לדעת את המידע הזה אם אתם מפתחים כללי תקלות לטיפול בתקלות. מידע נוסף על שגיאות שקשורות למדיניות ועל טיפול בשגיאות

שגיאות זמן ריצה

השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.

קוד תקלה	סטטוס HTTP	מטרה
steps.messagelogging.StepDefinitionExecutionFailed	500	לצפייה במחרוזת השגיאה.
steps.messagelogging.InvalidGoogleCloudLogName	500	השגיאה הזו מוצגת אם הביטוי LogName לא מניב את הפורמט התקין של projects/{project}/logs/{logid}.
steps.messagelogging.InvalidJsonMessage	500	השגיאה הזו מופיעה כשערך המאפיינים contentType נבחר כ-application/json, אבל ערך ההודעה בפועל הוא לא מחרוזת JSON תקינה.
steps.messagelogging.TooManyPendingLoggingRequest	500	השגיאה הזו מופיעה כשיש יותר מ-2,500 בקשות בהמתנה שעדיין לא נכתבו ב-Cloud Logging. המגבלה של 2,500 היא לכל פוד של זמן ריצה ב-Apigee. לדוגמה, אם התנועה מתחלקת בין שני מופעים של פודים של Apigee runtime, המגבלה האפקטיבית היא 5,000 בקשות.

-

שגיאות בהטמעה

השגיאות האלה יכולות להתרחש כשפורסים שרת proxy שמכיל את המדיניות הזו.

טיפ: רוצה עזרה בפתרון שגיאה? כדי לקבל מידע מפורט לפתרון בעיות, לוחצים על בעמודה 'תיקון'.

שם השגיאה	מטרה	תיקון
InvalidProtocol	פריסת המדיניות MessageLogging עלולה להיכשל עם השגיאה הזו אם הפרוטוקול שצוין ברכיב <Protocol> לא תקין. הפרוטוקולים התקינים הם TCP ו-UDP. לשליחת הודעות syslog ב-TLS/SSL, נתמך רק TCP.
InvalidPort	פריסת המדיניות MessageLogging עלולה להיכשל עם השגיאה הזו אם מספר היציאה לא מצוין ברכיב <Port> או אם הוא לא תקין. מספר היציאה חייב להיות מספר שלם גדול מאפס.

משתני תקלות

המשתנים האלה מוגדרים כשמתרחשת שגיאת זמן ריצה. מידע נוסף על שגיאות שקשורות למדיניות

הערה: שיחות דרך שרת proxy מצליחות גם אם הרישום נכשל

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

משתנים	כאשר:	דוגמה
fault.name="fault_name"	‫fault_name הוא שם התקלה, כפי שמופיע בטבלה Runtime errors שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה.	fault.name Matches "StepDefinitionExecutionFailed"
messagelogging.policy_name.failed	‫policy_name הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה.	messagelogging.ML-LogMessages.failed = true

דוגמה לתגובת שגיאה

הערה: כדי לטפל בשגיאות, מומלץ ללכוד את החלק errorcode של תגובת השגיאה. אל תסתמכו על הטקסט ב-faultstring, כי הוא עשוי להשתנות.

{  
   "fault":{
      "detail":{
         "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed"
      },
      "faultstring":"Execution failed"
   }
}

דוגמה לכלל שגיאה

<FaultRule name="MessageLogging">
    <Step>
        <Name>ML-LogMessages</Name>
        <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition>
    </Step>
    <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition>
</FaultRule>

משתנים בתהליך

המשתנים הבאים מאוכלסים אם יש כשל במדיניות.

• messagelogging.failed
• messagelogging.{stepdefinition-name}.failed

הערה: שיחות דרך שרת proxy מצליחות גם אם הרישום נכשל

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

נושאים קשורים

• משתנים שנחשפים על ידי Apigee: הפניה למשתני זרימה