בדף הזה מוסבר איך לפתור בעיות נפוצות שקשורות להתקנה של סוכן Logging או לאינטראקציה איתו.
רשימת המשימות
אם נתקלתם בבעיות בהתקנה או בשימוש בסוכן Logging, כדאי לבדוק את הדברים הבאים:
אם פקודות ההתקנה של Linux גורמות לשגיאות, צריך לוודא שמוסיפים את הקידומת
sudoלפקודות ההתקנה.מוודאים ששירות הסוכן פועל במכונה הווירטואלית:
במכונה וירטואלית של 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. כדי לראות את המכסה הזמינה, בוחרים באפשרות APIs & services (ממשקי API ושירותים) > Dashboard (מרכז בקרה) במסוף Google Cloud . בוחרים את Logging API.
אם נתקלתם בבעיות בגישה ל-API או בהרשאות, כדאי לעבור אל אימות פרטי הכניסה של Compute Engine.
אם נראה שהסוכן פועל כרגיל, אבל אתם לא מקבלים נתונים, כדאי לבדוק שהסוכן שולח נתונים לפרויקט הנכון. בקטע הבא מוסבר איך מאמתים את פרטי הכניסה של Compute Engine.
אם הסוכן לא מצליח לקבל הרשאה, צריך לבדוק אם פרטי הכניסה של המפתח הפרטי חסרים או לא תקינים.
אימות ההתקנה של הנציג
כדי לוודא שההתקנה בוצעה בהצלחה, מחפשים את רשומת יומן הבדיקה של הסוכן ב-Logs Explorer.
-
במסוף Google Cloud , נכנסים לדף Logs Explorer:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
בחלק העליון של הדף, בוחרים את הפרויקט שמכיל את מכונת ה-VM:
- בקטע Compute Engine VM instances, בוחרים את הפרויקט Google Cloud שמכיל את המכונה הווירטואלית.
בכרטיסיות של Windows, בוחרים את המשאב של מכונת ה-VM:
- בקטע Compute Engine, בוחרים באפשרות
GCE VM Instance. - בוחרים באפשרות syslog (Linux), fluent.info (Windows) או All logs (כל היומנים).
- בקטע Compute Engine, בוחרים באפשרות
אם מופיעה רשומה ביומן, Successfully sent gRPC to Logging API (ה-gRPC נשלח בהצלחה אל Logging API), סימן שההתקנה של הסוכן הושלמה. ההודעה הזו נוצרת פעם אחת כשהסוכן מותקן, וגם בכל פעם שהסוכן מופעל מחדש.
מידע נוסף על Logs Explorer זמין במאמר שימוש ב-Logs Explorer.
בדיקת הסוכן
אם אתם חושדים שהסוכן לא פועל, בדקו שהוא פועל ונסו לשלוח הודעת בדיקה ל-Logging:
מופע של Linux
מריצים את הפקודות הבאות במכונת ה-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 [...]כדי לשלוח הודעת יומן לבדיקה, מריצים את הפקודה הבאה במופע של המכונה הווירטואלית:
logger "Some test message"
מכונת Windows
לסוכן Logging יש שני שמות של שירותים ב-Windows:
-
StackdriverLoggingלגרסאות v1-5 ואילך -
fluentdwinsvcלגרסאות קודמות
צריך להפעיל שירות סוכן אחד. מריצים את הפקודות הבאות במכונת ה-VM באמצעות PowerShell:
בקשו לדעת את הסטטוס של שני השירותים. אם אתם יודעים איזה שירות צריך לפעול, אתם יכולים להשתמש רק בשם השירות הזה:
Get-Service StackdriverLogging,fluentdwinsvcאם שירות מסוים לא פועל, תוצג הודעת שגיאה. אם הוא פועל, הפלט אמור להיראות כך:
Status Name DisplayName ------ ---- ----------- Running StackdriverLogging Cloud Loggingאם שולחים שאילתה לשני השירותים, אמורה להופיע הודעת שגיאה אחת וסטטוס
Runningאחד:- אם לא מופיע סטטוס של
Running, סימן שהסוכן Logging לא פועל. - אם אתם רואים ש-
StackdriverLoggingפועל, סימן שאתם מריצים גרסה עדכנית של הסוכן. כדי לזהות את הגרסה הספציפית, אפשר לעיין במאמר בנושא איתור הגרסה. - אם אתם רואים ש-
fluentdwinsvcפועל, אתם צריכים לשדרג את הסוכן לגרסה העדכנית.
- אם לא מופיע סטטוס של
נדרשות הרשאות אדמין: אם פועלת גרסה כלשהי של הסוכן, שולחים הודעת יומן לצורך בדיקה על ידי הרצת פקודות 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:
-
במסוף Google Cloud , נכנסים לדף Logs Explorer:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
בחלק העליון של הדף, בוחרים את הפרויקט שמכיל את מכונת ה-VM:
- בקטע Compute Engine VM instances, בוחרים את הפרויקט Google Cloud שמכיל את המכונה הווירטואלית.
בכרטיסיות של Windows, בוחרים את המשאב של מכונת ה-VM:
- בקטע Compute Engine, בוחרים באפשרות
GCE VM Instance. - בוחרים באפשרות syslog (Linux), fluent.info (Windows) או All logs (כל היומנים).
- בקטע Compute Engine, בוחרים באפשרות
אמורה להופיע רשומה ביומן עם הודעת הבדיקה. אם כן, סוכן הרישום פועל בצורה תקינה.
אימות פרטי הכניסה ל-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 מהמכונה הווירטואלית ולהוסיף אותו מחדש.
אימות היקפי ההרשאות
כדי לוודא את היקפי הגישה:
-
נכנסים לדף VM instances במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים את התוצאה שבה כותרת המשנה היא Compute Engine.
לוחצים על השם של מכונת ה-VM. מוצג דף הפרטים של המופע.
בקטע Cloud API access scopes, לוחצים על Details כדי לראות את רשימת ממשקי ה-API. מחפשים את הרשומות הבאות:
- אם מופיעה ההודעה 'למופע הזה יש גישה מלאה ל-API לכל שירותי Google Cloud', היקפי הגישה שלכם מספיקים.
- אם ליד Stackdriver Logging API, שם ישן יותר של Cloud Logging API, מופיעה ההרשאה כתיבה בלבד או מלאה, אז היקפי הגישה של המופע מתאימים לסוכן Cloud Logging.
- אם ליד 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 הנכונות לסוכן.
כדי לאמת את ההרשאה של חשבון השירות שמוגדר כברירת מחדל, קודם צריך לאתר את חשבון השירות שמוגדר כברירת מחדל:
-
נכנסים לדף VM instances במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים את התוצאה שבה כותרת המשנה היא Compute Engine.
לוחצים על השם של מכונת ה-VM. מוצג דף הפרטים של המופע.
מחפשים את הכותרת חשבון שירות בדף. חשבון השירות שמוגדר כברירת מחדל עבור המכונה מופיע ברשימה. היא עשויה להיראות כך:
[ID]-compute@developer.gserviceaccount.com-
נכנסים לדף IAM במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
בוחרים באפשרות View By: Principals (תצוגה לפי: ישויות). תוצג רשימה של אנשים, קבוצות וחשבונות שירות. בעמודה תפקיד מופיעים התפקידים של כל גורם בפרויקט.
בשורה של חשבון השירות שמוגדר כברירת מחדל למופע, אמור להופיע תפקיד אחד או יותר:
- אם מופיעה ההרשאה עריכה, התפקיד הזה מתאים לכל הנציגים. יכול להיות שהתפקיד עריכה יוקצה אוטומטית לחשבון השירות שמוגדר כברירת מחדל, בהתאם להגדרות של מדיניות הארגון.
- אם מופיעה האפשרות 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.
אימות פרטי הכניסה של המפתח הפרטי
במכונות וירטואליות (VM) של Compute Engine, אפשר להגדיר את הסוכן כך שישתמש בחשבון שירות שאינו ברירת המחדל ושכולל את ההרשאה המתאימה.
כדי להגדיר את הסוכן בדרך הזו, צריך ליצור פרטי כניסה של מפתח פרטי לחשבון השירות המיועד ולתת את פרטי הכניסה האלה לסוכן.
- הסוכן מחפש משתנה סביבה,
GOOGLE_APPLICATION_CREDENTIALS, שמכיל את השם של קובץ שמכיל את פרטי הכניסה של המפתח הפרטי. אם משתנה הסביבה לא קיים, הנציג יחפש את פרטי הכניסה במיקום ברירת המחדל:
Linux
/etc/google/auth/application_default_credentials.jsonWindows
C:\ProgramData\Google\Auth\application_default_credentials.jsonאם פרטי הכניסה לא נמצאים במיקום ברירת המחדל, הסוכן משתמש בפרטי הכניסה שמוגדרים כברירת מחדל באפליקציה משרת המטא-נתונים.
המידע הבא יעזור לכם לאבחן בעיות שקשורות לפרטי הכניסה של המפתח הפרטי:
- האם המפתח הפרטי נמצא במקום?
- האם המפתח הפרטי עדיין תקף לחשבון השירות?
- האם לחשבון השירות יש את התפקידים שנדרשים לסוכן?
כדי לוודא שפרטי כניסה תקינים של מפתח פרטי מותקנים במופע של מכונת ה-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
במאמר כללים של חומת אש מוסבר איך להגדיר כללים לתעבורה יוצאת.
התקנה מחדש של הסוכן
התקנה של הגרסה העדכנית ביותר של הסוכן יכולה לפתור הרבה בעיות:
אם אתם בטוחים שהבעיה לא קשורה לפרטי הכניסה, אתם יכולים לדלג אל התקנה ב-Linux וב-Windows.
הוראות להתקנה מלאה של הסוכן ושל כל האישורים הנדרשים מופיעות במאמר התקנת סוכן Logging.
בעיות נפוצות אחרות
בטבלה הבאה מפורטות כמה בעיות נפוצות שבהן אתם עשויים להיתקל בסוכן 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, במופע של המכונה הווירטואלית.
בקטע <match **> מוסיפים את השורה הבאה:project_id [YOUR_PROJECT_ID]אפשרות אחרת היא לעיין במאמר בנושא איך מאשרים את סוכן Logging כדי לתקן או להחליף את פרטי הכניסה. |
| הסוכן Window Logging מפסיק להזין יומני אירועים מחלק מהערוצים | יכול להיות שסוכן Logging ייכשל בשקט בהטמעה של יומני אירועים מערוצים מסוימים, גם אם הוא עדיין פועל ומטמיע יומני סוכן ויומני אירועים מערוצים אחרים.
הסיבה לכך היא שיש בעיות בתוסף windows_eventlog, כפי שמצוין במצגת הזו.
השימוש ב-windows_eventlog2
פותר את הבעיה. |
הערה: פורמט הנתונים של התוסף windows_eventlog2 לא תואם לאחור לפורמט הנתונים של התוסף windows_eventlog. אם יש צינורות לייצוא של BigQuery או Google Cloud Storage שמוגדרים ליומנים האלה, צריך לשנות אותם בהתאם. כאן אפשר לראות השוואה בין רשומות ביומן שסופקו על ידי windows_eventlog ו-windows_eventlog2.
כדי להשתמש ב-windows_eventlog2, צריך קודם לעצור את סוכן 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 במכונה הווירטואלית. | משתמשים בפקודה ps -aux | grep "/usr/sbin/google-fluentd" כדי להציג את תהליכי הסוכן שפועלים (צריכים להיות רק שניים: אחד של מפקח ואחד של עובד), ובפקודה sudo netstat -nltp | grep :24231 כדי להציג את התהליכים שפועלים ותופסים את הפורט. אפשר להפסיק מופעים ישנים יותר לפי הצורך. |
סוכן Logging לא מופעל בגלל שגיאות מ-lib/fluent/config/types.rb |
ההגדרה של סוכן Logging כוללת קטע של מנתח regex עם regex שגוי, שגורם לקריאה לא תקינה של subexp ולשגיאות כמו 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) נוטה לגדול ככל שקצב העברת הנתונים של היומן גדל. אבל הסוכן, עם הגדרות ברירת המחדל, יכול להשתמש רק בליבת CPU אחת. לכן, כשהתפוקה של היומן עולה בחדות, יכול להיות שהסוכן יגיע למגבלת השימוש ב-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 (כולל), שגורמת להופעה חוזרת של יומנים כמו אלה ביומני הביקורת של Data Access, כשהסוכן פועל יותר מ-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 מהספרייה שבה התקנתם אותו.