פתרון בעיות בסוכן Logging

בדף הזה מפורטות הוראות לפתרון בעיות נפוצות שקשורות להתקנה של סוכן Logging או לאינטראקציה איתו.

רשימת המשימות

אם נתקלתם בבעיות בהתקנה או בשימוש בסוכן Logging, כדאי לבדוק את הדברים הבאים:

  • אם פקודות ההתקנה של Linux גורמות לשגיאות, צריך לוודא שמוסיפים את הקידומת sudo לפקודות ההתקנה.

  • מוודאים ששירות הסוכן פועל במכונה הווירטואלית:

    • במכונת VM עם Windows, משתמשים בפקודת PowerShell הבאה:

      Get-Service -Name StackdriverLogging

      מחפשים את השירות Stackdriver Logging. אם הסוכן לא פועל, יכול להיות שתצטרכו להפעיל אותו מחדש.

    • במכונת VM של Linux, משתמשים בפקודה הבאה:

      sudo service google-fluentd status

      אם הסוכן לא פועל, יכול להיות שתצטרכו להפעיל אותו מחדש באמצעות הפקודה הבאה:

      sudo service google-fluentd restart

      אם ההפעלה מחדש נכשלת, ופלט היומן מראה 'Disabled via metadata' (הושבת באמצעות מטא-נתונים), סביר להניח שאתם מריצים תמונה מ-Google Cloud Marketplace, שבה סוכן Logging מושבת כברירת מחדל. המפתח google-logging-enable של מטא-נתונים של מופע שולט במצב ההפעלה של סוכן Logging, כאשר ערך של 0 משבית את הסוכן. כדי להפעיל מחדש את הסוכן, צריך להסיר את המפתח google-logging-enable או להגדיר את הערך שלו ל-1. מידע נוסף זמין במאמר בנושא יצירת מופע עם סוכן הרישום ביומן מושבת).

      אם הסוכן לא מושבת באמצעות מטא-נתונים, צריך להתקין אותו מחדש. מידע נוסף מופיע בקטע התקנה מחדש של סוכן Logging.

  • בודקים אם הסוכן כתב הודעות שגיאה ביומנים.

    • ב-Windows, החל מגרסה v1-9, סוכן Logging שומר את היומנים שלו ב-C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      אין אפשרות לקבל את הרישומים של גרסאות קודמות של הסוכן.

    • ב-Linux, סוכן Logging הוא חבילת fluentd והוא רושם הודעות ביומן ב-/var/log/google-fluentd/google-fluentd.log:

      • אם מופיעות שגיאות HTTP 429, יכול להיות שחרגתם מהמכסות של Logging API. אפשר לראות את המכסה הזמינה על ידי בחירה באפשרות ממשקי API ושירותים > מרכז הבקרה במסוף Google Cloud . בוחרים את Logging API.

      • אם נתקלתם בבעיות בגישה ל-API או בהרשאה, כדאי לעבור אל אימות פרטי הכניסה של Compute Engine.

  • אם נראה שהסוכן פועל כרגיל, אבל אתם לא מקבלים נתונים, צריך לבדוק שהסוכן שולח נתונים לפרויקט הנכון. בקטע הבא מוסבר איך מאמתים את פרטי הכניסה של Compute Engine.

  • אם הסוכן לא מצליח לקבל הרשאה, צריך לבדוק אם פרטי הכניסה של המפתח הפרטי חסרים או לא תקינים.

אימות ההתקנה של הסוכן

כדי לוודא שההתקנה בוצעה בהצלחה, מחפשים ב-Logs Explorer את הרשומה של יומן הבדיקה של הסוכן.

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.

  2. בחלק העליון של הדף, בוחרים את הפרויקט שמכיל את מכונת ה-VM:

    • בקטע Compute Engine VM instances, בוחרים את הפרויקט Google Cloud שמכיל את המכונה הווירטואלית.

  3. בכרטיסיות של Windows, בוחרים את המשאב של מכונת ה-VM:

    • בקטע Compute Engine, בוחרים באפשרות GCE VM Instance.
    • בוחרים באפשרות syslog (Linux),‏ fluent.info (Windows) או All logs (כל היומנים).

אם מופיעה רשומת יומן עם הכיתוב 'Successfully sent gRPC to Logging API', סימן שההתקנה של הסוכן הושלמה. ההודעה הזו נוצרת פעם אחת כשהסוכן מותקן, וגם בכל פעם שהסוכן מופעל מחדש.

מידע נוסף על Logs Explorer זמין במאמר שימוש ב-Logs Explorer.

בדיקת הנציג

אם אתם חושדים שהסוכן לא פועל, בדקו שהוא פועל ונסו לשלוח הודעת בדיקה ל-Logging:

מופע Linux

  1. מריצים את הפקודות הבאות במכונת ה-VM כדי לוודא שסוכן ה-Logging פועל:

    ps ax | grep fluentd

    הפלט אמור להיראות כך:

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
 2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]

  2. כדי לשלוח הודעת יומן לבדיקה, מריצים את הפקודה הבאה במופע של מכונת ה-VM:

    logger "Some test message"

מכונה וירטואלית ב-Windows

לסוכן Logging יש שני שמות של שירותים ב-Windows:

  • ‫StackdriverLogging לגרסאות v1-5 ואילך
  • fluentdwinsvc לגרסאות קודמות

צריך להפעיל שירות של סוכן אחד. מריצים את הפקודות הבאות במכונת ה-VM באמצעות PowerShell:

  1. שואלים לגבי הסטטוס של שני השירותים. אם אתם יודעים איזה שירות צריך להפעיל, אתם יכולים להשתמש רק בשם השירות הזה:

    Get-Service StackdriverLogging,fluentdwinsvc

  2. אם שירות מסוים לא פועל, תופיע הודעת שגיאה. אם הוא פועל, הפלט אמור להיראות כך:

    Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging

  3. אם שולחים שאילתה לשני השירותים, אמורה להופיע הודעת שגיאה אחת וסטטוס Running אחד:

    • אם לא מופיע סטטוס של Running, סימן שסוכן Logging לא פועל.
    • אם אתם רואים ש-StackdriverLogging פועל, סימן שאתם משתמשים בגרסה עדכנית של הסוכן. כדי לדעת איזו גרסה ספציפית מותקנת, אפשר לעיין במאמר איך בודקים את הגרסה.
    • אם אתם רואים ש-fluentdwinsvc פועל, אתם צריכים לשדרג את הסוכן לגרסה העדכנית.

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

    New-EventLog   -LogName Application -Source "Test Source"
Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."

איפה מוצגת הודעת הבדיקה?

אחרי ששולחים הודעת בדיקה, מחפשים אותה ב-Logs Explorer:

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.

  2. בחלק העליון של הדף, בוחרים את הפרויקט שמכיל את מכונת ה-VM:

    • בקטע Compute Engine VM instances, בוחרים את הפרויקט Google Cloud שמכיל את המכונה הווירטואלית.

  3. בכרטיסיות של Windows, בוחרים את המשאב של מכונת ה-VM:

    • בקטע Compute Engine, בוחרים באפשרות GCE VM Instance.
    • בוחרים באפשרות syslog (Linux),‏ fluent.info (Windows) או All logs (כל היומנים).

  4. אמור להופיע רשומה ביומן עם הודעת הבדיקה. אם כן, סוכן הרישום פועל בצורה תקינה.

אימות פרטי הכניסה ל-Compute Engine

כדי שמכונת VM ב-Compute Engine תוכל להריץ את הסוכן בלי פרטי כניסה של מפתח פרטי, למכונה צריכים להיות היקפי גישה מתאימים וזהות חשבון השירות שבה המכונה משתמשת צריכה להיות בעלת הרשאות IAM מתאימות.

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

טעינת פרטי הכניסה שמוגדרים כברירת מחדל נכשלה

אם יש Could not load the default credentials שגיאות בקובץ היומן Logging, יכול להיות שהסוכן לא מצליח להתחבר לשרת המטא-נתונים של Compute Engine.

יומן השגיאות נראה כך:

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

סיבה אפשרית לכך היא שהמכונה הווירטואלית כוללת הגדרת proxy בהתאמה אישית. כדי לפתור את הבעיה, צריך לעיין בהוראות להגדרת שרת proxy כדי להחריג את שרת המטא-נתונים של Compute Engine ‏ (metadata.google.internal או 169.254.169.254) ממעבר דרך ה-proxy. אם השגיאה נמשכת, צריך להסיר את חשבון השירות שמוגדר כברירת המחדל של Compute Engine מהמכונה הווירטואלית ולהוסיף אותו מחדש.

אימות היקפי הגישה

כדי לאמת את היקפי הגישה:

  1. נכנסים לדף VM instances במסוף Google Cloud :

    כניסה לדף VM instances

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים את התוצאה עם כותרת המשנה Compute Engine.

  2. לוחצים על השם של מכונת ה-VM. מוצג דף הפרטים של המופע.

  3. בקטע Cloud API access scopes, לוחצים על Details כדי לראות את רשימת ממשקי ה-API. חפשו את הערכים הבאים:

    1. אם מופיעה ההודעה 'למופע הזה יש גישה מלאה ל-API לכל שירותי Google Cloud', היקפי הגישה שלכם מספיקים.
    2. אם ליד Stackdriver Logging API, שם ישן של Cloud Logging API, מופיעה ההרשאה כתיבה בלבד או מלאה, אז היקפי הגישה של המופע מתאימים לסוכן Cloud Logging.
    3. אם ליד Stackdriver Monitoring API, שם ישן של Cloud Monitoring API, מופיעה ההרשאה כתיבה בלבד או מלאה, סימן שהיקפי הגישה של המופע מתאימים לסוכן Cloud Monitoring.

פתרון הבעיה

אם אין לכם היקפי גישה מתאימים במכונה של Compute Engine, צריך להוסיף את היקפי הגישה הנדרשים למכונה.

בטבלה הבאה מפורטים ההיקפים שרלוונטיים לסוכני הרישום והמעקב:

היקף גישה הרשאות סוכן
https://www.googleapis.com/auth/logging.write מתאים לסוכן Logging
https://www.googleapis.com/auth/monitoring.write מתאים לסוכן Monitoring

אימות ההרשאה של חשבון השירות שמוגדר כברירת מחדל

גם אם היקפי הגישה של המכונה הווירטואלית ב-Compute Engine מספיקים, יכול להיות שחשבון השירות שמשמש כברירת המחדל של המכונה לא מספק את הרשאות ה-IAM הנכונות לסוכן.

כדי לאמת את ההרשאה של חשבון השירות שמוגדר כברירת מחדל, מתחילים באיתור חשבון השירות שמוגדר כברירת מחדל:

  1. נכנסים לדף VM instances במסוף Google Cloud :

    כניסה לדף VM instances

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים את התוצאה עם כותרת המשנה Compute Engine.

  2. לוחצים על השם של מכונת ה-VM. מוצג דף הפרטים של המופע.

  3. חפשו את הכותרת חשבון שירות בדף. חשבון השירות שמוגדר כברירת מחדל עבור המכונה מופיע ברשימה. היא עשויה להיראות כך:

    [ID]-compute@developer.gserviceaccount.com

  4. נכנסים לדף IAM במסוף Google Cloud :

    כניסה לדף IAM

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא IAM & Admin.

  5. בוחרים באפשרות View By: Principals (תצוגה לפי: ישויות). תוצג רשימה של אנשים, קבוצות וחשבונות שירות. בעמודה תפקיד מופיעים התפקידים של כל ישות בפרויקט.

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

    • אם מופיעה ההרשאה עריכה, התפקיד הזה מתאים לכל הסוכנים. יכול להיות שהתפקיד עריכה יוקצה אוטומטית לחשבון השירות שמוגדר כברירת מחדל, בהתאם להגדרות מדיניות הארגון.
    • אם מופיעה ההרשאה Logs Writer (כתיבת יומנים), ההרשאה הזו מספיקה לסוכן של Logging. מידע על תפקידים אחרים ב-Logging שכוללים את הרשאת הכתיבה מופיע במאמר בקרת גישה ל-Cloud Logging.
    • אם אתם רואים את התפקיד Monitoring Metric Writer, הוא מספיק ל-Monitoring Agent. מידע על תפקידים אחרים ב-Monitoring שכוללים את הרשאת הכתיבה מופיע במאמר בקרת גישה ל-Cloud Monitoring.

פתרון הבעיה

אם לחשבון השירות שמוגדר כברירת מחדל אין תפקידים מתאימים, נסו לערוך את התפקידים של חשבון השירות בדף IAM ואדמין > IAM. מוסיפים את התפקידים המתאימים של Logging או Monitoring כדי להעניק הרשאה לסוכנים: Logging > Logs Writer או Monitoring > Monitoring Metric Writer.

אימות פרטי הכניסה של המפתח הפרטי

במכונות וירטואליות ב-Compute Engine, אפשר להגדיר את הסוכן כך שישתמש בחשבון שירות שאינו ברירת המחדל ושכולל את ההרשאה המתאימה.

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

  1. הסוכן מחפש משתנה סביבה, GOOGLE_APPLICATION_CREDENTIALS, שמכיל את השם של קובץ שמכיל את פרטי הכניסה של המפתח הפרטי.

  2. אם משתנה הסביבה לא קיים, הנציג יחפש את פרטי הכניסה במיקום ברירת המחדל:

    Linux

    /etc/google/auth/application_default_credentials.json

    Windows

    C:\ProgramData\Google\Auth\application_default_credentials.json

  3. אם פרטי הכניסה לא נמצאים במיקום ברירת המחדל, הסוכן משתמש בפרטי הכניסה שמוגדרים כברירת מחדל באפליקציה משרת המטא-נתונים.

המידע הבא יעזור לכם לאבחן בעיות שקשורות לפרטי כניסה של מפתח פרטי:

  1. המפתח הפרטי נמצא במקום?
  2. האם המפתח הפרטי עדיין תקף לחשבון השירות?
  3. האם לחשבון השירות יש את התפקידים שנדרשים לסוכן?

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

האם פרטי הכניסה קיימים?

כדי לבדוק אם יש במופע שלכם פרטי כניסה של חשבון שירות עם מפתח פרטי, מריצים את פקודות Linux הבאות במופע:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

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

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY]@developer.gserviceaccount.com",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

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

כדי לבדוק או לשנות את משתנה הסביבה של פרטי הכניסה, צריך לגשת אל GOOGLE_APPLICATION_CREDENTIALS או להגדיר אותו ב-/etc/default/google-fluentd.

אם אין קובצי פרטי כניסה, אפשר לעיין במאמר בנושא הוספת פרטי כניסה.

האם פרטי הכניסה תקפים?

בקובץ פרטי הכניסה, project_id הוא Google Cloud הפרויקט שלכם, client_email מזהה את חשבון השירות בפרויקט, ו-private_key_id מזהה את המפתח הפרטי בחשבון השירות. משווים את המידע הזה למידע שמופיע בקטע IAM & Admin > Service accounts במסוףGoogle Cloud .

קובץ פרטי הכניסה לא תקף אם מתקיים אחד מהתנאים הבאים:

  • אתם בודקים מכונת Compute Engine, אבל הפרויקט Google Cloud בקובץ ההרשאות הוא לא הפרויקט שמכיל את המכונה.
  • חשבון השירות שמופיע ברשימה לא קיים. יכול להיות שהיא נמחקה.
  • לחשבון השירות שמופיע ברשימה לא מוקצים התפקידים הנכונים: Logs Writer לסוכן Cloud Logging ו-Monitoring Metric Writer לסוכן Cloud Monitoring.
  • המפתח הפרטי לא קיים. יכול להיות שההרשאה בוטלה.

אפשר לבטל את פרטי הכניסה באמצעות הקטע IAM & Admin > Service accounts במסוף Google Cloud . אם לא מופיעים פרטי כניסה תקינים, אפשר לעיין במאמר בנושא הוספת פרטי כניסה כדי להחליף את פרטי הכניסה הקיימים או להוסיף פרטי כניסה חדשים.

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

אחרת, תצטרכו ליצור חשבון שירות חדש כמו שמתואר בקטע הוספת פרטי כניסה.

אימות של שאילתות להחרגת יומנים

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

אימות חומת האש

כדי לבדוק אם למופע שלכם יש גישה ל-logging.googleapis.com, מריצים את פקודת Linux הבאה במופע:

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

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

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

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

התקנה מחדש של הסוכן

התקנת הגרסה העדכנית ביותר של הסוכן יכולה לפתור הרבה בעיות:

בעיות נפוצות אחרות

בטבלה הבאה מפורטות כמה בעיות נפוצות שבהן אתם עשויים להיתקל בסוכן Cloud Logging, ומוסבר איך לפתור אותן.

ב-Linux, סוכן Logging מתעד שגיאות ב-/var/log/google-fluentd/google-fluentd.log. ב-Windows, סוכן Logging מתעד שגיאות ב-C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log (החל מגרסה v1-9). השגיאה Google::APIClient::ClientError מציינת שיש בעיה בהרשאות או בגישה ל-API.

יכול להיות שתתחילו לראות שגיאות אחרי שהנציג יפעל בהצלחה. לדוגמה, יכול להיות שמישהו ביטל את ההרשאות הנדרשות בפרויקט או במופע של המכונה הווירטואלית.

שגיאה מטרה פתרון
הפעלת מנהל ההתקנה של הסוכן ב-Windows נכשלת יכול להיות שהורדתם את קובץ ההתקנה לספריית מערכת. מעבירים את קובץ ההתקנה לספרייה שאינה ספריית מערכת, כמו C:\Users\[USERID]\.
ה-API לא הופעל בפרויקט לא הפעלתם את Cloud Logging API בפרויקט. נכנסים אל APIs console ומשנים את הסטטוס של Cloud Logging API ל-ON.
בבקשה היו פרטי כניסה לא תקינים
או
שלא הייתה אפשרות לאחזר את טוקן הגישה (לא הוגדרו היקפי הרשאות?)		 למופע ה-VM אין פרטי כניסה מתאימים. מידע נוסף זמין במאמר בנושא מתן הרשאה לסוכן Logging להתקין פרטי כניסה.
ההרשאה נכשלה פרטי הכניסה להרשאה של המפתח הפרטי של סוכן Logging לא מוגדרים בצורה נכונה. אימות פרטי הכניסה של המפתח הפרטי
למתקשר אין הרשאה לחשבון השירות שמשמש להרשאה בפרויקט אין הרשאות מספיקות. יכול להיות שזה חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או ב-App Engine, או חשבון שירות שהוגדר על ידי המשתמש ומשמש להרשאה באמצעות מפתח פרטי. בחשבון צריכה להיות הרשאת עריכה. משנים את ההרשאה של חשבון השירות בדף IAM של הפרויקט. אם צריך, אפשר לשנות את היקף הגישה של מכונה וירטואלית קיימת באמצעות ההוראות שבמאמר שינוי חשבון השירות והיקפי הגישה של מופע.
אי אפשר לקבל את מזהה הפרויקט הסוכן של Cloud Logging לא הצליח לקבל את מזהה הפרויקט מקובץ פרטי הכניסה של המפתח הפרטי של חשבון שירות. כדי להוסיף מזהה פרויקט לסוכן או לשנות את מזהה הפרויקט שלו, צריך לערוך את קובץ התצורה של הסוכן, /etc/google-fluentd/google-fluentd.conf, במופע של מכונת ה-VM. בקטע <match **> מוסיפים את השורה הבאה:
project_id [YOUR_PROJECT_ID]
אפשרות אחרת היא לעיין במאמר איך מאשרים את סוכן Logging כדי לתקן או להחליף את פרטי הכניסה.
סוכן Logging של Windows מפסיק להעביר יומני אירועים מחלק מהערוצים יכול להיות שסוכן Logging ייכשל בשקט בהטמעה של יומני אירועים מערוצים מסוימים, למרות שהוא עדיין פועל ומטמיע יומני סוכן ויומני אירועים מערוצים אחרים. הסיבה לכך היא שיש בעיות בפלאגין windows_eventlog, כפי שמצוין במצגת הזו. השימוש ב-windows_eventlog2 פותר את הבעיה. הערה: פורמט הנתונים של התוסף windows_eventlog2 לא תואם לאחור לפורמט הנתונים של התוסף windows_eventlog. אם יש צינורות לייצוא ל-BigQuery או ל-Google Cloud Storage שהוגדרו עבור היומנים האלה, צריך לשנות אותם בהתאם. אפשר לעיין בהשוואה הזו של רשומות ביומן שסופקה על ידי windows_eventlog ו-windows_eventlog2. כדי להשתמש ב-windows_eventlog2, קודם צריך לעצור את סוכן Logging ואז להחליף את קובץ התצורה בקובץ דומה לקובץ התצורה לדוגמה הזה. לבסוף, מפעילים את סוכן Logging.
סוכן Logging מפסיק להטמיע יומנים בנוכחות logrotate יכול להיות שסוכן Logging יאבד את המיקום שלו בקובצי הקלט אם logrotate מוגדר עם ההגדרה copytruncate. מומלץ להשתמש בהגדרה nocopytruncate כדי לוודא שהכלי logrotate יעביר את הקבצים במקום לחתוך אותם. אם רוצים לשמור על ההגדרה copytruncate, הפתרון הוא להפעיל מחדש את הסוכן מדי פעם. אפשר גם להשתמש בהגדרה postrotate כדי להפעיל מחדש את הסוכן.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" יש כמה מופעים של סוכן Logging שפועלים במכונת ה-VM. משתמשים ב-ps -aux | grep "/usr/sbin/google-fluentd" כדי להציג תהליכי סוכן שפועלים (צריכים להיות רק שניים: אחד של supervisor ואחד של worker), וב-sudo netstat -nltp | grep :24231 כדי להציג תהליכים שפועלים ותופסים את הפורט. להפסיק מופעים ישנים יותר לפי הצורך.
סוכן Logging לא מופעל בגלל שגיאות מ- lib/fluent/config/types.rb ההגדרה של סוכן Logging כוללת קטע של מנתח ביטויים רגולריים עם ביטוי רגולרי פגום, שגורם לקריאה לא תקינה של ביטוי משנה ולשגיאות כמו Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call. מאתרים ומתקנים את הביטוי הרגולרי הפגום בקובץ ההגדרות של הסוכן. טיפ: אפשר לחפש לפי regex או parse.

מגבלה על נפח התפוקה של היומן

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

בדרך כלל, כשכל רשומה ביומן היא טקסט גולמי בגודל 1,000 בייט ולא כוללת עיבוד נוסף של הפורמט, סוכן Logging מגיע למגבלה של ליבת מעבד (CPU) אחת בכ-5,500 רשומות ביומן לשנייה. אם רשומות היומן דורשות עיבוד מתקדם, למשל ניתוח של JSON או Regex, יכול להיות שמספר רשומות היומן המקסימלי לשנייה יהיה נמוך יותר.

אם אתם צריכים קצב העברת נתונים גבוה יותר של יומנים, כדאי לשקול להשתמש ב-Ops Agent. ב-Linux, עבור רשומות ביומן שהן טקסט גולמי בגודל 1,000 בייט ולא נדרש עיבוד נוסף שלהן, סוכן תפעול יכול לעבד כ-160,000 רשומות ביומן בשנייה.

חריגה מהגודל המקסימלי של היומן

אם אחת או יותר מהרשומות ביומן חורגות ממגבלת הגודל המקסימלית, יכול להיות שתמצאו רשומות ביומני fluentd שדומות לרשומות הבאות:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"


או

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

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

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

היומנים משוכפלים

השדה LogEntry.insertID נוסף בצינור העיבוד בתוך הסוכן. אם הערך של insertID שונה בין היומנים הכפולים, זה מצביע על כך שהיומנים נלקחו מקובצי היומן מספר פעמים. זה יכול לקרות אם יש החלפת יומנים, או אם קובץ ה-pos חסר או פגום. כדי להקטין את הסיכוי לבעיה הזו, צריך לוודא שקבצי המיקום של כל קלט in_tail לא מוגדרים להיות בתיקייה /var/log או בתיקיות אחרות שבהן יכול להיות שמופעלת החלפת יומנים.

צינור עיבוד הנתונים של הרישום ביומן מסתמך גם על השדה LogEntry.timestamp כדי לבטל כפילויות ביומנים. מוודאים שחותמת הזמן בפועל של הרשומה ביומן מנותחת בצורה תקינה. אם לא הגדרתם את Fluentd כך שינתח את חותמת הזמן המקורית מתוך רשומת היומן, הוא ישתמש בזמן שבו הוא מעבד את רשומת היומן. לכן, אם הקלט נקרא כמה פעמים, יכול להיות ש-Fluentd יתייחס אליהם כאל רשומות שונות ביומן עם חותמות זמן שונות, גם אם חותמת הזמן בשורת היומן זהה.

שגיאות חוזרות ביומן הביקורת: Data points cannot be written more than 24h in the past

יש בעיה מוכרת שמשפיעה על גרסאות 1.8.5 עד 1.9.3 (כולל), שגורמת להופעה חוזרת של יומנים כמו אלה ביומני ביקורת של גישה לנתונים, כשהסוכן פועל יותר מ-24 שעות:

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

הפתרון הוא לשדרג את הסוכן לגרסה 1.9.4 ואילך.

תווי Unicode ביומנים מוחלפים ברווחים או ב-'�'

כברירת מחדל, הקלט in_tail מצפה שקובצי הקלט יהיו בקידוד ASCII, ולכן הוא מחליף כל תו שאינו ASCII ברווח. כדי להטמיע קבצים בקידוד UTF-8, צריך לספק שתי אפשרויות בהגדרות של in_tail:

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

שתי האפשרויות נדרשות. אם מספקים רק את האפשרות encoding, תווים שאינם ASCII ביומני הרישום שהועלו יוחלפו בתו '�'.

הסרנו סוכן שדווח על ידי Google Cloud המסוף כסוכן שהותקן

אחרי שמסירים את הסוכן, יכול להיות שיעבור עד שעה עד שהשינוי יופיע במסוף Google Cloud .

סוכן Logging לא מופיע ברשימה 'הסרת התקנה של תוכנית' ב-Windows

כדי להסיר את ההתקנה של סוכן Logging אם הוא לא מופיע ברשימה הסרת התקנה של תוכנית בלוח הבקרה של Windows, מריצים את הפקודה uninstall.exe מהספרייה שבה התקנתם אותו.