‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

הערה: אם ההודעה הבאה מוצגת במכונה וירטואלית (VM) של Linux, אפשר להתעלם ממנה בבטחה:

Need to set
  STACKDRIVER_API_KEY in /etc/sysconfig/stackdriver Not starting. Configuration
  error.

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

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

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

אם פקודות ההתקנה של Linux גורמות לשגיאות, צריך לוודא שמוסיפים את הקידומת sudo לפקודות ההתקנה.
מוודאים ששירות הסוכן פועל במכונה הווירטואלית:
- במכונה וירטואלית של 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, הסוכן של Monitoring כותב הודעות ביומן האירועים של 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', כדאי לעיין בקטע הבא, אימות הפרויקט ופרטי הכניסה.
  - אם מופיעות ביומנים השגיאות Unsupported collectd plugin/type combination או Unsupported collectd id, יכול להיות שאתם שולחים מדדים של סוכן שלא נתמכים. המצב הזה יכול לקרות בתרחישים הבאים:
    - שיניתם את אחת ההגדרות של אפליקציית צד שלישי של הסוכן. כדי לבטל את השינויים, אפשר להתקין מחדש את ההגדרה של הפלאגין הספציפי לפי ההוראות בדף התיעוד הרלוונטי. אם רוצים להשתמש בסוכן כדי לשלוח את המדד הזה ל-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.

אם צריך, משנים את הפרויקט הנוכחי Google Cloud לפרויקט שמשויך למכונה הווירטואלית ב-Compute Engine. לדוגמה, אם מוצגת לכם ההודעה Enable billing, המשמעות היא שבפרויקט הנוכחי אין מכונות וירטואליות של Compute Engine.
בדף VM Instances, לוחצים על השם של מכונת ה-VM. יוצג דף הפרטים של מכונת ה-VM.
בדף 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 (כתיבת מדדים ב-Monitoring) לאיסוף מדדים ו-roles/logging.logWriter (כתיבת יומנים) לכתיבת יומנים.
המפתח הפרטי לא קיים. יכול להיות שהיא בוטלה.

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

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

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

לכל פרויקט מקושר שמכיל מכונות שצריך לאשר להן גישה באמצעות מפתח פרטי – לכל פרויקט שמכיל מכונות Compute Engine שנוצרו בלי לכלול את היקף הגישה https://www.googleapis.com/auth/monitoring.write – יוצרים חשבון שירות ומפיקים מפתח פרטי, אם הם עדיין לא קיימים. פועלים לפי השלבים הבאים:
1. נכנסים לדף Settings במסוף Google Cloud :
  עוברים אל הגדרות.
  
  אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
2. לוחצים על הכרטיסייה היקף הרשת.
3. מזהים את הפרויקט שמכיל את משאבי Compute Engine המדוברים ועוברים אל מסוףGoogle Cloud .
4. עוברים לדף IAM Service Accounts במסוף Google Cloud , בוחרים את פרויקט Google Cloud , יוצרים חשבון שירות חדש ואז יוצרים מפתח פרטי חדש לחשבון השירות הזה.
  כדי לבצע את השלבים האלה, אפשר לבצע אחת מהפעולות הבאות:
  - עוברים לדף IAM Service Accounts, בוחרים את הפרויקט Google Cloud ופועלים לפי השלבים במאמר יצירת חשבון שירות:
    
    כניסה לדף IAM Service Accounts
  - לוחצים על הלחצן הבא ואז בוחרים את הפרויקט Google Cloud :
    
    יצירת חשבון שירות והורדת מפתח
    
    הכפתור הקודם מבצע אוטומציה של התהליך ליצירה ולהורדה של מפתח למערכת המקומית עבור חשבון השירות הספציפי לסוכן. במקרה הצורך, התהליך גם יוצר את חשבון השירות הנדרש ומוודא שלחשבון השירות יש את ההרשאות הנכונות. לחשבונות שירות ספציפיים לסוכן יש שם שדומה ל-stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. תקבלו הודעה על השלמת הפעולות האלה בתיבת דו-שיח שדומה לזו:
  הערה: בחשבונות שירות יכולים להיות עד 10 מפתחות. מידע נוסף זמין במאמר בנושא מגבלות.
מחליפים את המפתח הפרטי במכונות שמתאימות לחשבון השירות הרלוונטי.
- ב-Linux, מחליפים את המפתח הפרטי שנמצא ב-/etc/google/auth/application_default_credentials.json.
- ב-Windows, מחליפים את המפתח הפרטי שנמצא בתיקייה C:\ProgramData\Google\Auth\application_default_credentials.json. מידע נוסף מופיע במאמר בנושא העתקת המפתח הפרטי למופע.
הפעלה מחדש של הסוכן
- ב-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:

קובעים את מזהה המופע של המכונה הווירטואלית שבה התקנתם את הסוכן:
- מכונות Compute Engine: עוברים לדף הפרטים של Compute Engine עבור המכונה. בחלק התחתון של הדף, לוחצים על Equivalent REST (מקבילה ל-REST). המזהה הוא מספר בן 19 ספרות.
עוברים לדף התיעוד של ה-method timeSeries.list.
ממלאים את הטופס ב-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. משאירים את כל שאר השדות ריקים.
לוחצים על 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 מניבה הודעת שגיאה, זה לא מעיד על בעיה בסוכן. בודקים ששדות ה-API Explorer מלאים בצורה תקינה:
- שגיאות מסוג Invalid argument (ארגומנט לא תקין) כנראה מצביעות על בעיה באיות ובפורמט של מזהה הפרויקט, המסנן או שני חותמות הזמן.
  
  הדרישות לגבי ארגומנטים של חותמת זמן תלויות בסוג המדד שאתם מציינים. סוג מדד מתעד נתונים של GAUGE, DELTA או CUMULATIVE. מידע נוסף זמין במאמר MetricKind.
  
  במדדים DELTA ו-CUMULATIVE, צריך להגדיר גם שעת התחלה וגם שעת סיום, ושעת הסיום צריכה להיות מאוחרת יותר משעת ההתחלה. סוגי המדדים האלה מתעדים שינויים שנמדדים לאורך זמן, ולכן שעת ההתחלה ושעת הסיום צריכות להגדיר מרווח זמן שאינו אפס.
- שגיאות מסוג 'אין הרשאה' יכולות להצביע על כך שכתבתם את מזהה הפרויקט בצורה שגויה.
- שגיאות מסוג 'לא נמצא' יכולות להצביע על כך שהשמטתם את הקידומת projects/ הנדרשת בשדה 'שם'.
צריך לפתור את הבעיות ולנסות שוב לבצע את קריאה ל-API.
אם הקריאה ל-API מצליחה אבל אתם רואים רק תגובה ריקה, { }, אתם צריכים לבדוק שהמסנן ומרווח הזמן נכונים. שגיאות בפורמט של חותמות הזמן עלולות לגרום לכך שלא יוחזרו נתונים. אם הכול נראה תקין אבל לא מתקבלים נתונים, יכול להיות שהסוכן לא שולח נתוני מדדים, או שהוא לא שולח אותם לפרויקט שאליו ציפיתם. יכול להיות שזו בעיה בפרטי הכניסה. כדאי לעיין במאמר בנושא אימות פרטי כניסה של מפתח פרטי.

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

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

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

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

מריצים אחת מהשאילתות הבאות כדי לראות אילו מכונות וירטואליות של Linux מריצות את הסוכן:
- APIs Explorer
- Metrics Explorer
שימו לב: לכל שאילתה צריך להזין את שם הפרויקט ולשנות את גבולות הזמן.

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

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

לדוגמה, ב-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.

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

בעיה שקשורה לנקודה על הגרף עם ערך אינסופי (Linux)

write_gcm: can not take infinite value

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

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

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

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

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

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

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

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

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

בעיה של הצפת מאגר (buffer) של טוקנים (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 מהספרייה שבה התקנתם אותו.