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

פתרון בעיות בהטמעת נתונים ב-Ops Agent

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

לפני שמתחילים

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

Google Cloud המסוף מציג שההתקנה של סוכן תפעול נתקעת במצב 'בהמתנה'

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

סיבות נפוצות לכשל בהתקנה

ההתקנה של סוכן תפעול עלולה להיכשל מהסיבות הבאות:

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

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

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

לחשבון השירות שמחובר למכונה הווירטואלית אין את התפקיד roles/logging.logWriter או roles/monitoring.metricWriter.
היקף הגישה לרישום ביומן או למעקב לא מופעל. מידע על בדיקה ועדכון של היקפי גישה זמין במאמר אימות היקפי הגישה.
‫Logging API או Monitoring API לא מופעלים.

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

הסוכן פועל, אבל הנתונים לא מוזנים

משתמשים ב-Metrics Explorer כדי לשלוח שאילתה למדד של הסוכן uptime, ומוודאים שרכיב הסוכן, google-cloud-ops-agent-metrics או google-cloud-ops-agent-logging, כותב למדד.

נכנסים לדף Metrics explorer במסוף Google Cloud :
עוברים אל Metrics Explorer

אם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
במתג עם התווית Builder Code, בוחרים באפשרות Code, ואז מגדירים את השפה ל-PromQL.

מזינים את השאילתה הבאה ולוחצים על Run:

rate({"__name__"="agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])

האם הסוכן שולח יומנים ל-Cloud Logging?

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

צינורות עיבוד נתונים משודרגים של רישום ביומן

החל מגרסה 2.66.0 של סוכן תפעול, פייפליין רישום ברירת המחדל ביומן מטופל על ידי שירות Metrics Agent במקום שירות סוכן Logging. החל מגרסה 2.72.0 של Ops Agent, כל צינורות עיבוד הנתונים הנתמכים של רישום ביומן מטופלים על ידי שירות Metrics Agent. אם פייפליינים של רישום ביומן לא פועלים כמצופה, אתם יכולים לנסות לחזור לגרסה קודמת של שירות סוכן Logging על ידי עדכון ההגדרות:

logging:
  service:
    experimental_otel_logging: false

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

שגיאות בצינור עיבוד הנתונים

אם מוצגת שגיאת זמן הריצה LogPipelineErr ("Ops Agent logging pipeline failed"), סימן שסוכן המשנה של רישום ביומן נתקל בבעיה בכתיבת יומנים. בודקים את התנאים הבאים:

בודקים שיש גישה לקובצי האחסון של סוכן המשנה Logging. הקבצים האלה נמצאים במיקומים הבאים:
- ב-Linux: ‏ /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- ב-Windows:‏ C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\‎
מוודאים שהדיסק של ה-VM לא מלא.
מוודאים שהגדרות הרישום ביומן נכונות.

כדי לבצע את השלבים האלה, צריך להיכנס ל-VM באמצעות SSH.

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

Linux

כדי להפעיל מחדש את הסוכן, מריצים את הפקודה הבאה במופע:
```
sudo systemctl restart google-cloud-ops-agent
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ובודקים שהרכיבים Metrics Agent ו-סוכן Logging הופעלו:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

מתחברים למכונה באמצעות RDP או כלי דומה, ונכנסים ל-Windows.
פותחים טרמינל ב-PowerShell עם הרשאות אדמין על ידי לחיצה ימנית על סמל PowerShell ובחירה באפשרות הפעלה כאדמין.
כדי להפעיל מחדש את הסוכן, מריצים את פקודת PowerShell הבאה:
```
Restart-Service google-cloud-ops-agent -Force
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-סוכן Logging הופעלו:
```
Get-Service google-cloud-ops-agent*
```

שגיאות בניתוח יומנים

אם מופיעה שגיאת זמן הריצה LogParseErr ("סוכן תפעול failed to parse logs"), הבעיה כנראה בהגדרות של מעבד יומנים. כדי לפתור את הבעיה:

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

כדי לבצע את השלבים האלה, צריך להיכנס ל-VM באמצעות SSH.

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

Linux

כדי להפעיל מחדש את הסוכן, מריצים את הפקודה הבאה במופע:
```
sudo systemctl restart google-cloud-ops-agent
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ובודקים שהרכיבים Metrics Agent ו-סוכן Logging הופעלו:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

מתחברים למכונה באמצעות RDP או כלי דומה, ונכנסים ל-Windows.
פותחים טרמינל ב-PowerShell עם הרשאות אדמין על ידי לחיצה ימנית על סמל PowerShell ובחירה באפשרות הפעלה כאדמין.
כדי להפעיל מחדש את הסוכן, מריצים את פקודת PowerShell הבאה:
```
Restart-Service google-cloud-ops-agent -Force
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-סוכן Logging הופעלו:
```
Get-Service google-cloud-ops-agent*
```

בדיקת המדדים המקומיים

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

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

‫Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

פותחים את Windows PowerShell כאדמין ומריצים את הפקודה:

Get-Service google-cloud-ops-agent

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

בדיקת היומן של מודול הרישום ביומן

בשלב הזה צריך להתחבר למכונה הווירטואלית באמצעות SSH.

אפשר למצוא את היומנים של מודול הרישום בכתובת /var/log/google-cloud-ops-agent/subagents/*.log ב-Linux ובכתובת C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log ב-Windows. אם אין יומנים, שירות הסוכן לא פועל כמו שצריך. קודם צריך לעבור לקטע הסוכן מותקן אבל לא פועל כדי לפתור את הבעיה.

יכול להיות שתראו שגיאות הרשאה מסוג 403 כשכותבים ל-Logging API. לדוגמה:

[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
{
"error": {
  "code": 403,
  "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
  "status": "PERMISSION_DENIED",
  "details": [
    {
      "@type": "type.googleapis.com/google.rpc.Help",
      "links": [
        {
          "description": "Google developers console API activation",
          "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
        }
      ]
    }
  ]
}
}

כדי לפתור את השגיאה הזו, צריך להפעיל את Logging API ולהגדיר את התפקיד Logs Writer.

יכול להיות שתופיע בעיה במכסה של Logging API. לדוגמה:
```
error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
```
כדי לפתור את השגיאה הזו, צריך להגדיל את המכסה או להקטין את קצב העברת הנתונים של היומן.
יכול להיות שתראו את השגיאות הבאות ביומן של המודול:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
או
```
can't fetch token from the metadata server
```
השגיאות האלה עשויות להצביע על כך שפרסתם את הסוכן ללא חשבון שירות או ללא פרטי כניסה שצוינו. מידע על פתרון הבעיה הזו זמין במאמר בנושא הרשאת סוכן תפעול.

האם הסוכן שולח מדדים ל-Cloud Monitoring?

בדיקת היומן של מודול המדדים

בשלב הזה צריך להתחבר למכונה הווירטואלית באמצעות SSH.

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

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

Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}

כדי לתקן את השגיאה הזו, מפעילים את Monitoring API ומגדירים את התפקיד כתיבת מדדים של Monitoring.

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

Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}

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

יכול להיות שתראו את השגיאות הבאות ביומן של המודול:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
או
```
can't fetch token from the metadata server
```
השגיאות האלה עשויות להצביע על כך שפרסתם את הסוכן ללא חשבון שירות או ללא פרטי כניסה שצוינו. מידע על פתרון הבעיה הזו זמין במאמר בנושא הרשאת סוכן תפעול.

בעיות בקישוריות לרשת

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

הסיבות הנפוצות לבעיות בקישוריות הן:

כללי חומת אש שמפריעים לתעבורה נכנסת. למידע נוסף על כללי חומת אש, קראו את המאמר שימוש בכללי חומת אש של VPC.
בעיות בהגדרת ה-Proxy ל-HTTP.
הגדרת DNS.

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

הסבר על הודעות השגיאה 'העברה של נתונים זמניים נכשלה'

החל מגרסה 2.28.0 של Ops Agent,‏ Ops Agent מגביל את נפח האחסון במקום בכונן שבו הוא יכול להשתמש כדי לאחסן נתונים זמניים. סוכן תפעול יוצר נתחי מאגר נתונים זמני כשאי אפשר לשלוח נתונים ל-Cloud Logging API. בלי מגבלה, יכול להיות שהחלקים האלה יתפסו את כל המקום שזמין, ויפריעו לשירותים אחרים ב-VM. כששיבוש ברשת גורם לכתיבת נתחי מאגר לדיסק, סוכן תפעול משתמש בכמות ספציפית לפלטפורמה של מקום בכונן כדי לאחסן את הנתחים. הודעה כמו זו שבדוגמה הבאה מופיעה גם ב-/var/log/google-cloud-ops-agent/subagents/logging-module.log במכונות וירטואליות של Linux או ב-C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log במכונות וירטואליות של Windows, כשהמכונה הווירטואלית לא מצליחה לשלוח את נתחי המאגר אל Cloud Logging API:

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

בעיות ב-Proxy ל-HTTP

בעיה בהגדרת Proxy ל-HTTP עלולה לגרום לשגיאות. לדוגמה, שגיאות מ-flb_upstream עם המונח context מצביעות על בעיה בהגדרת שרת ה-proxy:

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

כדי לפתור את הבעיה, צריך לוודא שפרוקסי ה-HTTP הוגדר בצורה נכונה. הוראות להגדרת ה-Proxy ל-HTTP מפורטות במאמר הגדרת Proxy ל-HTTP.

למפרטים של פורמט Proxy ל-HTTP, קראו את המדריך הרשמי של Fluent Bit.

אני רוצה לאסוף רק מדדים או רק יומנים, לא את שניהם

כברירת מחדל, סוכן התפעול אוסף גם מדדים וגם יומנים. כדי להשבית את האיסוף של מדדים או יומנים, משתמשים בקובץ config.yaml של סוכן תפעול כדי לשנות את ברירת המחדל של השירות logging או metrics, כך שלצינור עיבוד הנתונים שמוגדר כברירת מחדל לא יהיו מקלטים. מידע נוסף:

הפסקת ההטמעה של נתונים על ידי השבתת שירותי סוכני המשנה של Ops Agent ‏Logging Agent או Metrics Agent מובילה להגדרה לא תקינה ולא נתמכת.

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

בקטע הזה מתוארים כמה תנאי שגיאה נפוצים.

הסוכן מתעד 'הייצוא נכשל. Will retry" (יתבצע ניסיון נוסף)

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

Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
n invalid value of \"2021-07-13T10:25:18.061-07:00\": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
ent/uptime'.", "interval": "23.491024535s"}
Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
n invalid value of \"2021-07-13T10:26:18.061-07:00\": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
ent/monitoring/point_count'.", "interval": "21.556591578s"}

הסוכן רושם ביומן את ההודעות "TimeSeries could not be written: Points must be written in order."‎

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

Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
gce_instance{instance_id:*,zone:*} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}

הסוכן מתעד את השגיאה One or more points were written more frequently than the maximum sampling period (נקודה אחת או יותר נכתבו בתדירות גבוהה יותר מתקופת הדגימה המקסימלית)

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

Jan 26 11:11:06 * otelopscol[1234]: 2026-01-26T11:11:06.665Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed. Dropping data.
{"error": "failed to export metrics to projects/*: rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written:
timeSeries[...] (... metric.type=\"agent.googleapis.com/cpu/utilization\", ... resource.type=\"gce_instance\", ...):
write for resource failed: One or more points were written more frequently than the maximum sampling period configured for the metric."}

שכפול מדדים מתרחש לעיתים קרובות כשמוסיפים מקלט לצינור עיבוד נתונים חדש שכבר נמצא בשימוש בהגדרת ברירת המחדל המובנית של סוכן תפעול. יכול להיות שלא תדעו שמקלט כבר נמצא בשימוש, כי הגדרת ברירת המחדל לא מוצגת באופן מפורש בקובץ config.yaml. כשיוצרים צינורות עיבוד נתונים חדשים, כדאי לעיין במסמכי התיעוד של הגדרת ברירת המחדל של Ops Agent כדי לראות באילו מקלטים נעשה שימוש בצינורות עיבוד הנתונים שמוגדרים כברירת מחדל. לדוגמה, מקלט hostmetrics מופעל כברירת מחדל ב-default_pipeline. אם תיצרו ותפעילו צינור חדש שמשתמש גם במקלט hostmetrics ב-config.yaml, המדדים מ-hostmetrics יישלחו פעמיים כי המקלט ישמש עכשיו בשני צינורות.

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

הנציג רושם הודעות Token must be a short-lived token (60 minutes) and in a reasonable timeframe (הטוקן חייב להיות טוקן לזמן קצר (60 דקות) ובמסגרת זמן סבירה)

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

Invalid JWT: Token must be a short-lived token (60 minutes) and in a
reasonable timeframe. Check your iat and exp values in the JWT claim.

מידע על סנכרון של שעוני מערכת זמין במאמר הגדרת NTP במכונה וירטואלית.

הסוכן מתעד ביומן את השגיאה 'metrics receiver with type "nvml" is not supported' (מקלט המדדים עם הסוג nvml לא נתמך)

אם אתם אוספים מדדי GPU של NVIDIA Management Library‏ (NVML) (agent.googleapis.com/gpu) באמצעות המקלט nvml, אתם משתמשים בגרסה של סוכן תפעול עם תמיכה בגרסת טרום-השקה (Preview) של מדדי NVML. התמיכה במדדים האלה זמינה לכל המשתמשים ב-סוכן תפעול מגרסה 2.38.0. בגרסת GA, איסוף המדדים שבוצע על ידי מקלט nvml מוזג עם מקלט hostmetrics, ומקלט nvml הוסר.

מופיעה הודעת השגיאה 'metrics receiver with type "nvml" is not supported' (לא נתמך מקלט מדדים עם הסוג nvml) אחרי התקנה של סוכן תפעול בגרסה 2.38.0 או בגרסה חדשה יותר, אם השתמשתם במקלט nvml בתצוגה מקדימה וביטלתם את ברירת המחדל של מרווח האיסוף בקובץ התצורה שצוין על ידי המשתמש. השגיאה מתרחשת כי הנמען nvml כבר לא קיים, אבל קובץ התצורה שצוין על ידי המשתמש עדיין מתייחס אליו.

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

חסרים מדדים של GPU

אם סוכן תפעול אוסף מדדים מסוימים אבל חסרים חלק מהמדדים של NVIDIA Management Library (NVML) GPU (agent.googleapis.com/gpu) או כולם, יכול להיות שיש בעיה בהגדרה או שאין תהליכים שמשתמשים ב-GPU.

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

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

אם הדרייבר לא מותקן, מבצעים את הפעולות הבאות:

מתקינים את מנהל ההתקן של ה-GPU.
מפעילים מחדש את סוכן התפעול.

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

בודקים את היומנים של Ops Agent כדי לוודא שהתקשורת התחילה בהצלחה. הודעות היומן נראות כך:

Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.

אם מנהל ההתקן של ה-GPU מותקן וביומנים של Ops Agent מצוין ש-Ops Agent מתקשר עם מנהל ההתקן, אבל אתם לא רואים מדדים של ה-GPU, יכול להיות שהבעיה היא בתרשים שבו אתם משתמשים. מידע על פתרון בעיות בתרשימים זמין במאמר בתרשים לא מוצגים נתונים.

אם אתם אוספים חלק ממדדי ה-GPU אבל חסרים לכם המדדים processes metrics—processes/max_bytes_used ו-processes/utilization—אז אין לכם תהליכים שפועלים ב-GPU. מדדי ה-GPU processes לא נאספים אם לא פועלים תהליכים ב-GPU.

חלק מהמדדים חסרים או לא עקביים

יש מספר קטן של מדדים שגרסה 2.0.0 ואילך של Ops Agent מטפלת בהם באופן שונה מגרסאות ה'תצוגה המקדימה' של Ops Agent (גרסאות ישנות יותר מ-2.0.0) או מ-Monitoring agent.

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

סוג המדד, לא כולל `agent.googleapis.com`	Ops Agent (זמינות כללית)^†	סוכן תפעול (תצוגה מקדימה)^†	סוכן מעקב מדור קודם
`cpu_state`	הערכים האפשריים ל-Windows הם: `idle`,‏ `interrupt,`,‏ `system` ו-`user`.	הערכים האפשריים ל-Windows הם `idle`,‏ `interrupt,`,‏ `system` ו-`user`.	הערכים האפשריים ב-Windows הם `idle` ו-`used`.
`disk/bytes_used` וגם `disk/percent_used`	הנתונים מוזנים עם הנתיב המלא בתווית `device`, למשל `/dev/sda15`. לא נאסף עבור מכשירים וירטואליים כמו `tmpfs` ו-`udev`.	הנתונים נבלעו בלי `/dev` בנתיב בתווית `device`, לדוגמה, `sda15`. הנתונים נאספים למכשירים וירטואליים כמו `tmpfs` ו-`udev`.	הנתונים נבלעו בלי `/dev` בנתיב בתווית `device`, לדוגמה, `sda15`. הנתונים נאספים למכשירים וירטואליים כמו `tmpfs` ו-`udev`.

^† העמודה GA מתייחסת לגרסאות 2.0.0 ומעלה של סוכן תפעול. העמודה Preview מתייחסת לגרסאות של סוכן תפעול שקודמות ל-2.0.0.

בעיות שספציפיות ל-Windows

הקטעים הבאים רלוונטיים רק ל-Ops Agent שפועל ב-Windows.

עיכוב בקבלת היומנים

אם אתם מבחינים בעיכוב בהגעת היומנים, אבל רואים את ההגעה של רשומות ביומן SuccessAudit של Windows, כמו "An attempt was made to access an object.", יכול להיות שמספר הרשומות ביומן SuccessAudit מונע את הטמעת היומנים בזמן. כדי לפתור את הבעיה, משביתים את רשומות היומן של SuccessAudit אם הן לא נחוצות.

מוני ביצועים פגומים ב-Windows

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

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

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

cd C:\Windows\system32
lodctr /R

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

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

Restart-Service -Name google-cloud-ops-agent -Force

איפוס מלא של מצב הסוכן

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

‫Linux

עוצרים את שירות הסוכן:

sudo service google-cloud-ops-agent stop

מסירים את חבילת הסוכן:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

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

sudo rm -rf /var/log/google-cloud-ops-agent

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

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

הערה: הספרייה /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ מכילה את סוגי הקבצים הבאים:

קובצי מאגר: הקבצים האלה הם רשומות ביומן שנשמרו במאגר, עברו עיבוד על ידי סוכן תפעול אבל עדיין לא הועברו ל-Cloud Logging. אם יש נתונים פגומים, סוכן תפעול צריך לדלג עליהם בגרסאות >= 2.15.0. במקרים מסוימים, צריך לנקות אותם באופן ידני. הקבצים האלה מאוחסנים בתיקיות המשנה, למשל: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
קבצים של מעקב אחרי קובצי יומן: הקבצים האלה מתעדים את המיקום בקובצי היומן שה-סוכן תפעול כבר עקב אחריו. אם הקבצים האלה יוסרו, סוכן התפעול יתחיל מהחלק העליון של הקבצים שהוא מוגדר לעקוב אחריהם. מחיקה של הקבצים האלה עלולה לגרום לשכפול של יומנים אם הם הוטמעו בהצלחה בעבר. הקבצים האלה מאוחסנים ישירות בספרייה כקבצים כמו: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

התחביר .../buffers/*/ בפקודה הקודמת מבטיח שיימחקו רק קובצי המאגר. קובצי המיקום לא נמחקים.

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

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

עוצרים את שירות הסוכן:

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

מסירים את חבילת הסוכן:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

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

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

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

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

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

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

איפוס אבל שמירת קובצי המאגר

אם למכונה הווירטואלית אין נתונים פגומים במאגר הזמני (כלומר, אין הודעות format check failed בקובץ היומן העצמי של סוכן תפעול), אפשר לדלג על הפקודות הקודמות שמסירות את המאגרים הזמניים המקומיים כשמאפסים את מצב הסוכן.

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

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

Linux
```
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
```
Windows
```
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
```
אפשרות 2: מוחקים את תיקיות המשנה של המאגר מהספרייה buffers, אבל משאירים את קובצי המיקום. הגישה הזו מתוארת במאמר בנושא איפוס מלא של מצב הסוכן.

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

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};

אפשרות 4: אם יש הרבה מאגרי נתונים זמניים פגומים ואתם רוצים לעבד מחדש את כל קובצי היומן, אתם יכולים להשתמש בפקודות מאפשרות 3 וגם למחוק את קובצי המיקום (שבהם מאוחסן ההתקדמות של Ops Agent לכל קובץ יומן). מחיקה של קובצי המיקום עלולה לגרום לשכפול של יומנים שכבר הועברו בהצלחה. האפשרות הזו מעבדת מחדש רק את קבצי היומן הנוכחיים. היא לא מעבדת מחדש קבצים שכבר הועברו או יומנים ממקורות אחרים, כמו יציאת TCP. קובצי המיקום מאוחסנים בספרייה buffers, אבל הם מאוחסנים כקבצים. המאגרים המקומיים מאוחסנים כספריות משנה בספרייה buffers,

‫Linux
```
grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete
```
Windows
```
$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
```

בעיות מוכרות בגרסאות האחרונות של סוכן תפעול

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

גרסה 2.56.0 של סוכן תפעול לא מצליחה לשלוח מדדים של Prometheus

אם אתם משתמשים בגרסה 2.56.0 של סוכן תפעול בשילוב עם Prometheus receiver, ויעד הגירוד שלכם פולט מדדים עם מדדי *_created נוספים למונים (כדי לתמוך בתכונה החדשה הניסיונית Created Timestamps), יכול להיות שהסוכן לא יצליח לכתוב מדדים וידווח על שגיאות ששעות ההתחלה חייבות להיות חיוביות. הודעות היומן נראות כך:

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

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

לולאת קריסה בגרסה 2.47.0,‏ 2.48.0 או 2.49.0 של סוכן תפעול

בגרסאות 2.47.0,‏ 2.48.0 ו-2.49.0 שולב רכיב FluentBit פגום לרישום ביומן. הרכיב הזה נכשל בשורות יומן ספציפיות וגורם ל-Ops Agent להיכנס ללולאת קריסה.

הבעיה הזו נפתרה בגרסה 2.50.0 של סוכן תפעול.

מרחב השמות של מדדי Prometheus כולל את שם המכונה בנוסף למזהה המכונה החל מגרסה 2.46.0 של סוכן תפעול

החל מגרסה 2.46.0, סוכן התפעול כולל את שם ה-VM כחלק מהתווית namespace כשמטמיעים מדדים בפורמט ההטמעה של Prometheus. בגרסאות קודמות, המדדים של Prometheus השתמשו רק במזהה המכונה הווירטואלית כחלק מהתווית namespace, אבל החל מגרסה 2.46.0, הערך של namespace מוגדר ל-INSTANCE_ID/INSTANCE_NAME.

אם יש לכם תרשימים, לוחות בקרה או מדיניות התראות שמשתמשים בתווית namespace label, יכול להיות שתצטרכו לעדכן את השאילתות אחרי שדרוג סוכן תפעול לגרסה 2.46.0 ואילך. לדוגמה, אם שאילתת PromQL שלכם נראית כך: http_requests_total{namespace="123456789"}, צריך לשנות אותה ל-http_requests_total{namespace=~"123456789.*"}, כי התווית namespace היא בפורמט INSTANCE_ID/INSTANCE_NAME.

החל מגרסה 2.39.0 של סוכן תפעול, המדדים של Prometheus ללא סוג משתנים לסוג מדד

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

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

שימוש בזיכרון גבוה במכונות וירטואליות של Windows (גרסאות 2.27.0 עד 2.29.0)

ב-Windows בגרסאות Ops Agent‏ 2.27.0 עד 2.29.0, באג שגרם לסוכן להדליף לפעמים שקעים הוביל לשימוש מוגבר בזיכרון ולמספר גבוה של נקודות אחיזה שהוחזקו על ידי התהליך fluent-bit.exe.

כדי לפתור את הבעיה, משדרגים את Ops Agent לגרסה 2.30.0 ומעלה, ומפעילים מחדש את הסוכן.

אזורי הזמן ביומן האירועים שגויים ב-Windows (גרסאות 2.15.0 עד 2.26.0)

יכול להיות שחותמות הזמן שמשויכות ליומני אירועים של Windows ב-Cloud Logging יהיו שגויות אם תשנו את אזור הזמן של מכונת ה-VM מ-UTC. הבעיה תוקנה ב-סוכן תפעול בגרסה 2.27.0, אבל בגלל הבעיה הידועה של שימוש גבוה בזיכרון ב-Windows, אם נתקלתם בבעיה הזו אנחנו ממליצים לשדרג ל-סוכן תפעול בגרסה 2.30.0 לפחות. אם אתם לא מצליחים לשדרג, אתם יכולים לנסות את אחד מהפתרונות הבאים.

שימוש באזור זמן UTC

ב-PowerShell, מריצים את הפקודות הבאות כאדמינים:

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

ביטול הגדרת אזור הזמן רק בשירות של סוכן המשנה לרישום ביומן

ב-PowerShell, מריצים את הפקודות הבאות כאדמינים:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

חותמות זמן שנותחו ב-Windows כוללות אזור זמן שגוי (בכל הגרסאות שלפני 2.27.0)

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

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

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

יומנים לא מזיקים (גרסה 2.9.1 וגרסאות ישנות יותר)

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

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186

יומני הרישום העצמי של הסוכן צורכים יותר מדי מעבד (CPU), זיכרון ומקום בכונן (גרסאות 2.16.0 ומטה)

בגרסאות של סוכן תפעול שקודמות לגרסה 2.17.0, יכול להיות שהסוכן יצרוך הרבה משאבי מעבד, זיכרון ומקום בכונן עם קבצי /var/log/google-cloud-ops-agent/subagents/logging-module.log במכונות וירטואליות של Linux או קבצי C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log במכונות וירטואליות של Windows, בגלל נתחי מאגר פגומים. במקרה כזה, בlogging-module.log מופיע מספר גדול של הודעות כמו זו שבהמשך.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb

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

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

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

לפני שמתחילים

Google Cloud המסוף מציג שההתקנה של סוכן תפעול נתקעת במצב 'בהמתנה'

סיבות נפוצות לכשל בהתקנה

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

הסוכן פועל, אבל הנתונים לא מוזנים

האם הסוכן שולח יומנים ל-Cloud Logging?

צינורות עיבוד נתונים משודרגים של רישום ביומן

שגיאות בצינור עיבוד הנתונים

Linux

Windows

שגיאות בניתוח יומנים

Linux

Windows

בדיקת המדדים המקומיים

בדיקת היומן של מודול הרישום ביומן

האם הסוכן שולח מדדים ל-Cloud Monitoring?

בדיקת היומן של מודול המדדים

בעיות בקישוריות לרשת

הסבר על הודעות השגיאה 'העברה של נתונים זמניים נכשלה'

בעיות ב-Proxy ל-HTTP

אני רוצה לאסוף רק מדדים או רק יומנים, לא את שניהם

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

הסוכן מתעד 'הייצוא נכשל. Will retry" (יתבצע ניסיון נוסף)

הסוכן רושם ביומן את ההודעות "TimeSeries could not be written: Points must be written in order."‎

הסוכן מתעד את השגיאה One or more points were written more frequently than the maximum sampling period (נקודה אחת או יותר נכתבו בתדירות גבוהה יותר מתקופת הדגימה המקסימלית)

הנציג רושם הודעות Token must be a short-lived token (60 minutes) and in a reasonable timeframe (הטוקן חייב להיות טוקן לזמן קצר (60 דקות) ובמסגרת זמן סבירה)

הסוכן מתעד ביומן את השגיאה 'metrics receiver with type "nvml" is not supported' (מקלט המדדים עם הסוג nvml לא נתמך)

חסרים מדדים של GPU

חלק מהמדדים חסרים או לא עקביים

בעיות שספציפיות ל-Windows

עיכוב בקבלת היומנים

מוני ביצועים פגומים ב-Windows

איפוס מלא של מצב הסוכן

איפוס אבל שמירת קובצי המאגר

בעיות מוכרות בגרסאות האחרונות של סוכן תפעול

גרסה 2.56.0 של סוכן תפעול לא מצליחה לשלוח מדדים של Prometheus

לולאת קריסה בגרסה 2.47.0,‏ 2.48.0 או 2.49.0 של סוכן תפעול

מרחב השמות של מדדי Prometheus כולל את שם המכונה בנוסף למזהה המכונה החל מגרסה 2.46.0 של סוכן תפעול

החל מגרסה 2.39.0 של סוכן תפעול, המדדים של Prometheus ללא סוג משתנים לסוג מדד

שימוש בזיכרון גבוה במכונות וירטואליות של Windows (גרסאות 2.27.0 עד 2.29.0)

אזורי הזמן ביומן האירועים שגויים ב-Windows (גרסאות 2.15.0 עד 2.26.0)

חותמות זמן שנותחו ב-Windows כוללות אזור זמן שגוי (בכל הגרסאות שלפני 2.27.0)

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

יומנים לא מזיקים (גרסה 2.9.1 וגרסאות ישנות יותר)

יומני הרישום העצמי של הסוכן צורכים יותר מדי מעבד (CPU), זיכרון ומקום בכונן (גרסאות 2.16.0 ומטה)

פתרון בעיות בהטמעת נתונים ב-Ops Agent