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

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

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

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

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

‫Google Cloud במסוף מופיע שההתקנה של Ops Agent תקועה בסטטוס Pending (בהמתנה)

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

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

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

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

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

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

לחשבון השירות שמחובר למכונה הווירטואלית אין את התפקיד 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?

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

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

החל מגרסה Ops Agent 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 לא מלא.
מוודאים שהגדרת הרישום ביומן נכונה.

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

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

Linux

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

Windows

מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.
פותחים טרמינל ב-PowerShell עם הרשאות אדמין: לוחצים לחיצה ימנית על הסמל של PowerShell ובוחרים באפשרות Run as Administrator.
כדי להפעיל מחדש את הסוכן, מריצים את פקודת 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, צריך לבדוק את ההגדרה של מעבדי רישום אחרים.

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

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

Linux

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

Windows

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

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

כדי לבצע את השלבים האלה, צריך להיכנס ל-VM באמצעות 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
```
השגיאות האלה עשויות להצביע על כך שפרסתם את הסוכן ללא חשבון שירות או ללא פרטי כניסה שצוינו. למידע על פתרון הבעיה, קראו את המאמר מתן הרשאה ל-Ops Agent.

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

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

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

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

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

הסבר על הודעות השגיאה "failed to flush chunk" (הניקוי של המקטע נכשל)

החל מגרסה 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.

מפרט הפורמט של פרוקסי HTTP מופיע במדריך הרשמי של Fluent Bit.

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

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

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

המדדים נאספים, אבל נראה שיש בעיה

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

הסוכן מתעד 'הייצוא נכשל. הודעות עם הכיתוב 'יתבצע ניסיון נוסף'

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

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

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"

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

כדי לוודא שהדרייבר מותקן ופועל כמו שצריך, פועלים לפי השלבים לאימות ההתקנה של דרייבר ה-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 ו-processes/utilization, סימן שאין לכם תהליכים שפועלים ביחידות ה-GPU.processes/max_bytes_used מדדי ה-GPU processes לא נאספים אם לא פועלים תהליכים ב-GPU.

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

יש מספר קטן של מדדים שגרסה 2.0.0 של סוכן תפעול וגרסאות חדשות יותר מטפלות בהם באופן שונה מגרסאות ה-"preview" של סוכן תפעול (גרסאות קודמות ל-2.0.0) או מ-Monitoring agent.

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

סוג המדד, לא כולל `agent.googleapis.com`	סוכן תפעול (GA)^†	סוכן תפעול (תצוגה מקדימה)^†	סוכן מעקב מדור קודם
`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 ומעלה של סוכן תפעול. העמודה תצוגה מקדימה מתייחסת לגרסאות של סוכן תפעול שקטנות מ-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. הבעיה תוקנה ב-Ops Agent בגרסה 2.27.0, אבל בגלל הבעיה הידועה של שימוש גבוה בזיכרון ב-Windows, אם נתקלתם בבעיה הזו אנחנו ממליצים לשדרג ל-Ops Agent בגרסה 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 במסוף מופיע שההתקנה של Ops Agent תקועה בסטטוס Pending (בהמתנה)

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

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

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

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

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

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

Linux

Windows

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

Linux

Windows

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

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

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

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

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

הסבר על הודעות השגיאה "failed to flush chunk" (הניקוי של המקטע נכשל)

בעיות ב-Proxy ל-HTTP

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

המדדים נאספים, אבל נראה שיש בעיה

הסוכן מתעד 'הייצוא נכשל. הודעות עם הכיתוב 'יתבצע ניסיון נוסף'

הסוכן רושם ביומן את ההודעות "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