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

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

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

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

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

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

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

      Get-Service -Name StackdriverMonitoring

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

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

      sudo service stackdriver-agent status

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

      sudo service stackdriver-agent restart

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

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

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

    • ב-Windows, סוכן המעקב כותב הודעות ביומן האירועים של Windows.

    • ב-Linux, סוכן Monitoring הוא collectd חבילה ומתעד הודעות ב-/var/log/syslog או ב-/var/log/messages. ההודעות ביומן מתחילות בקידומת collectd או stackdriver-agent:

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

      • אם אתם רואים בעיות ב-Proxy, בדקו שהגדרתם את ה-Proxy של HTTP בצורה נכונה. ההוראות הן חלק מהמאמר התקנה ב-Linux וב-Windows.

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

      • אם מופיעות ביומנים השגיאות 'שילוב לא נתמך של סוג אוסף/תוסף collectd' או 'מזהה collectd לא נתמך', יכול להיות שאתם שולחים מדדים של סוכן שלא נתמכים. זה יכול לקרות בתרחישים הבאים:

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

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

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

אימות הפרויקט ופרטי הכניסה

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

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

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

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

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

משתמשים בדף VM instances של Compute Engine במסוף Google Cloud כדי לוודא שלמכונת ה-VM של Compute Engine יש פרטי כניסה מתאימים לסוכן Monitoring. בדרך כלל, פרטי הכניסה מתווספים לחשבון השירות שמוגדר כברירת מחדל בכל המכונות הווירטואליות החדשות של Compute Engine, אבל אפשר לשנות את ברירות המחדל האלה כשיוצרים מכונה.

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

כניסה לדף VM instances

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

  1. במקרה הצורך, משנים את הפרויקט הנוכחי Google Cloud לפרויקט שמשויך למכונה הווירטואלית ב-Compute Engine. לדוגמה, אם מוצגת לכם ההודעה Enable billing, זה אומר שבפרויקט הנוכחי אין מכונות וירטואליות של Compute Engine.
  2. בדף VM Instances, לוחצים על השם של מכונת ה-VM. יוצג דף הפרטים של מכונת ה-VM.
  3. בדף VM instance details, מחפשים את הכותרת Cloud API access scopes:
    • אם מופיעה האפשרות 'מתן גישה מלאה לכל ממשקי ה-API של Cloud', יש לכם את האישורים המתאימים.
    • אם ליד Stackdriver Monitoring API מופיע שם ישן יותר של Cloud Monitoring API, וקיבלתם הרשאת כתיבה בלבד או מלאה, סימן שיש לכם את פרטי הכניסה המתאימים.
    • אחרת, לחשבון השירות שמוגדר כברירת מחדל במופע לא יהיו פרטי הכניסה שהסוכן צריך. כדי להשתמש בסוכן במופע, צריך להוסיף פרטי כניסה של חשבון שירות עם מפתח פרטי. הוראות מפורטות מופיעות במאמר הוספת פרטי כניסה.

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

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

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

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

כדי לבדוק אם יש במופע שלכם פרטי כניסה של חשבון שירות עם מפתח פרטי, מריצים את פקודות 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}"
}

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

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

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

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

  • אתם בודקים מכונה וירטואלית (VM) של Compute Engine, אבל הפרויקטGoogle Cloud בקובץ ההרשאות הוא לא הפרויקט שמכיל את המכונה.
  • חשבון השירות שמופיע ברשימה לא קיים. יכול להיות שהיא נמחקה.
  • לא מופעלים בחשבון השירות שמופיע ברשימה התפקידים הנכונים. צריכות להיות לו לפחות ההרשאות roles/monitoring.metricWriter (כתיבת מדדים של מעקב) לאיסוף מדדים ו-roles/logging.logWriter (כתיבת רישומים) לכתיבת רישומים.
  • המפתח הפרטי לא קיים. יכול להיות שהגישה בוטלה.

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

יצירת פרטי כניסה חדשים

אם פרטי הכניסה לא תקינים, צריך לבצע את הפעולות הבאות:

  1. לכל פרויקט מקושר שמכיל מכונות שצריך לאשר את הגישה אליהן באמצעות מפתח פרטי – כל פרויקט שמכיל מכונות Compute Engine שנוצרו בלי לכלול את היקף הגישה https://www.googleapis.com/auth/monitoring.write – יוצרים חשבון שירות ומפיקים מפתח פרטי, אם הם עדיין לא קיימים. פועלים לפי השלבים הבאים:

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

      עוברים אל הגדרות.

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

    2. בוחרים בכרטיסייה היקף Netric.
    3. מזהים את הפרויקט שמכיל את משאבי Compute Engine המדוברים ועוברים אל Google Cloud המסוף.
    4. עוברים לדף IAM Service Accounts במסוף Google Cloud , בוחרים את פרויקט Google Cloud , יוצרים חשבון שירות חדש ואז יוצרים מפתח פרטי חדש לחשבון השירות הזה.

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

      • עוברים לדף IAM Service Accounts, בוחרים את הפרויקט Google Cloud ופועלים לפי השלבים במאמר יצירת חשבון שירות:

        כניסה לדף 'חשבונות שירות' ב-IAM

      • לוחצים על הלחצן הבא ובוחרים את הפרויקט: Google Cloud

        יצירת חשבון שירות והורדת מפתח

        הלחצן הקודם מבצע אוטומציה של התהליך ליצירה ולהורדה של מפתח למערכת המקומית עבור חשבון השירות הספציפי לסוכן. במקרה הצורך, התהליך גם יוצר את חשבון השירות הנדרש ומוודא שלחשבון השירות יש את ההרשאות הנכונות. לחשבונות שירות ספציפיים לסוכנים יש שם שדומה ל-stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. תקבלו הודעה על השלמת הפעולות האלה בתיבת דו-שיח שדומה לזו:

        באנר שמודיע למשתמש שנוצרו חשבון שירות ומפתח.

  2. מחליפים את המפתח הפרטי במכונות שמתאימות לחשבון השירות הרלוונטי.

    • ב-Linux, מחליפים את המפתח הפרטי שנמצא בתיקייה /etc/google/auth/application_default_credentials.json.
    • ב-Windows, מחליפים את המפתח הפרטי שנמצא בתיקייה C:\ProgramData\Google\Auth\application_default_credentials.json. מידע נוסף מופיע במאמר בנושא העתקת המפתח הפרטי למופע.

  3. הפעלה מחדש של הסוכן

    • ב-Linux, מריצים את הפקודה sudo service stackdriver-agent restart
    • ב-Windows, נכנסים למסוף לניהול שירותים ומפעילים מחדש את השירות Cloud Monitoring.

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

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

  • קוראים את קובץ ה-JSON של המפתח הפרטי במופע, לדוגמה (ב-Linux): sudo cat /etc/google/auth/application_default_credentials.json
  • מוודאים שהערך בשדה project_id זהה לערך של הפרויקט שבמעקב שעבורו יצרתם הרשאות.

אימות נתוני הנציג

כדי לוודא שהסוכן שולח את המדדים בצורה נכונה, משתמשים בשיטה timeSeries.list של Monitoring API כדי לחפש נתונים עדכניים של סדרות זמן ממופע מכונה וירטואלית. אפשר להפעיל את ה-method באמצעות APIs Explorer בדף התיעוד של ה-method. אם לא מופיעים נתונים, יכול להיות שהסוכן שולח נתונים לפרויקט הלא נכון. כדי לבדוק את זה, אפשר לעיין במאמר אימות הפרויקט ופרטי הכניסה.

אלה הוראות מפורטות לשימוש בשיטה timeSeries.list:

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

    • מכונות Compute Engine: עוברים לדף הפרטים של המכונה ב-Compute Engine. בתחתית הדף, לוחצים על Equivalent REST (מקבילה ל-REST). המזהה הוא מספר בן 19 ספרות.

  2. עוברים לדף התיעוד של ה-method timeSeries.list.

  3. ממלאים את הטופס של APIs Explorer:

    1. מגדירים את name לפרויקט שמכיל את המכונה הווירטואלית, עם הקידומת projects/. לדוגמה, projects/[YOUR_PROJECT_ID].

    2. מגדירים את filter לשורה הבאה כדי לבחור מדד של סוכן מתוך מופע ה-VM. מעתיקים ומדביקים אותו בכלי APIs Explorer, ואז משנים את מזהה מכונת ה-VM:

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"

    3. הגדרת מרווח הזמן של החיפוש. רוצים מרווח של כחמש דקות:

      • מגדירים את interval.endTime לזמן הנוכחי לפי שעון גריניץ', שאפשר לראות בכתובת time.is/GMT. הזמן צריך להיות בפורמט כמו בדוגמה הבאה. אין לתחום את השעה במירכאות כפולות:

        2016-10-31T14:10:00Z

      • מגדירים את interval.startTime לחמש דקות לפני שעת הסיום, בערך, באותו פורמט.

    4. משאירים את כל שאר השדות ריקים.

  4. לוחצים על Execute.

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

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

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

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

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

    • שגיאות מסוג Invalid argument (ארגומנט לא תקין) מצביעות כנראה על בעיה באיות ובפורמט של מזהה הפרויקט, המסנן או שתי חותמות הזמן.

      הדרישות לגבי ארגומנטים של חותמת זמן תלויות בסוג המדד שאתם מציינים. סוג מדד מתעד נתונים של GAUGE, DELTA או CUMULATIVE. מידע נוסף זמין במאמר MetricKind.

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

    • שגיאות מסוג 'אין הרשאה' יכולות להצביע על כך שכתבתם את מזהה הפרויקט בצורה שגויה.

    • שגיאות מסוג 'לא נמצא' יכולות להצביע על כך שהשמטתם את הקידומת projects/ הנדרשת בשדה 'שם'.

    צריך לפתור את הבעיות ולנסות שוב לבצע את הקריאה ל-API.

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

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

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

קביעה באילו מכונות וירטואליות של Linux מותקן הסוכן

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

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

הפעלה מחדש אוטומטית של הסוכן

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

לדוגמה, ב-Linux, אפשר ליצור את הרשומה הבאה ב-crontab כדי לבדוק את סטטוס הסוכן כל 5 דקות:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

בעיות מוכרות

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

בעיה בגישה לנתונים (Windows)

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

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

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

בעיות במטמון המטא-נתונים (Linux)

יכול להיות שתראו הודעת שגיאה בקובץ יומן המערכת של Linux‏ (/var/log/syslog ב-Debian / Ubuntu או /var/log/messages ב-Red Hat / CentOS / SLES) שדומה להודעה הבאה:

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

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

בעיה שקשורה להשמטת נקודת נתונים עם ערך אינסופי (Linux)

יכול להיות שתראו הודעת שגיאה בקובץ יומן המערכת של Linux‏ (/var/log/syslog ב-Debian / Ubuntu או /var/log/messages ב-Red Hat / CentOS / SLES) שדומה להודעה הבאה:

write_gcm: can not take infinite value

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

בעיה במגבלת הקצב של מפתח מטא-נתונים (Linux)

יכול להיות שתראו הודעת שגיאה בקובץ יומן המערכת של Linux‏ (/var/log/syslog ב-Debian / Ubuntu או /var/log/messages ב-Red Hat / CentOS / SLES) שדומה להודעה הבאה:

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

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

בעיה שקשורה למכסה של Cloud Monitoring API (ב-Linux)

יכול להיות שתראו הודעת שגיאה בקובץ יומן המערכת של Linux‏ (/var/log/syslog ב-Debian / Ubuntu או /var/log/messages ב-Red Hat / CentOS / SLES) שדומה להודעה הבאה:

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

ההודעה הזו מציינת שהגעתם למגבלת המכסה של Cloud Monitoring API. במדריך בנושא Quota מוסבר איך לנהל את מגבלת המכסה.

שימוש בזיכרון בנפח גדול בגלל ערך נמוך של COLLECTD_INTERVAL (Linux)

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

בעיה של הצפת מאגר (Linux)

יכול להיות שתופיע הודעת שגיאה בקובץ יומן המערכת של Linux (/var/log/syslog ב-Debian / Ubuntu או /var/log/messages ב-Red Hat / CentOS / SLES) שדומה להודעה הבאה:

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

ההודעות האלה מציינות שצריך לשדרג את סוכן המעקב לגרסה 6.1.2 ואילך.

הערך 'מקור' במאגר השתנה (Linux)

יכול להיות שתופיע הודעת שגיאה דומה להודעה הבאה כשמשדרגים את הסוכן, מתקינים את הסוכן או מריצים את apt-get update ב-Debian/Ubuntu Linux:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

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

apt-get --allow-releaseinfo-change update

ואז מריצים שוב את השדרוג או ההתקנה.

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

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

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

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