Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Linux

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

Windows

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

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

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

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

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

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

Linux

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

Windows

מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.
פותחים טרמינל ב-PowerShell עם הרשאות אדמין על ידי לחיצה ימנית על סמל PowerShell ובחירה באפשרות הפעלה כמנהל מערכת.
כדי להפעיל מחדש את הסוכן, מריצים את פקודת PowerShell הבאה:
```
Restart-Service google-cloud-ops-agent -Force
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:
```
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 Metric Writer.

יכול להיות שיוצגו שגיאות 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.
בעיות בהגדרת ה-HTTP proxy.
הגדרת ה-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

בעיות ב-HTTP proxy

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

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

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

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

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."}

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

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

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'

אם אתם אוספים מדדי 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

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

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

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

אם מנהל ההתקן לא מותקן, פועלים לפי השלבים הבאים:

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

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

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

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

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

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

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

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

הקטעים הבאים רלוונטיים רק ל-סוכן תפעול שפועל ב-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/ יש קבצים מהסוגים הבאים:

קבצים של מאגר זמני: אלה רשומות ביומן שנוספו למאגר הזמני ועברו עיבוד על ידי Ops Agent, אבל עדיין לא הועברו ל-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 בקובץ היומן העצמי של Ops Agent), אפשר לדלג על הפקודות הקודמות שמסירות את המאגרים המקומיים כשמאפסים את מצב הסוכן.

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

אפשרות 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 וגם למחוק את קובצי המיקום (שמאחסנים את ההתקדמות של סוכן תפעול לכל קובץ יומן). מחיקה של קבצי המיקום עלולה לגרום לשכפול של יומנים שכבר נבלעו בהצלחה. האפשרות הזו מעבדת מחדש רק קבצים של יומנים נוכחיים. היא לא מעבדת מחדש קבצים שכבר הועברו או יומנים ממקורות אחרים, כמו יציאת 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 , יכול להיות שתצטרכו לעדכן את השאילתות אחרי שדרוג סוכן תפעול לגרסה 2.46.0 ואילך. לדוגמה, אם שאילתת PromQL שלכם נראית כך: http_requests_total{namespace="123456789"}, אתם צריכים לשנות אותה כך: http_requests_total{namespace=~"123456789.*"}, כי התווית namespace היא בפורמט INSTANCE_ID/INSTANCE_NAME.

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

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

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

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

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

בעיות ב-HTTP proxy

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

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

הנציג/ה מתעד/ת 'הייצוא נכשל. הודעות עם הכיתוב Will retry

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

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

הסוכן מתעד ביומן את השגיאה 'metrics receiver with type "nvml" is not supported'

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

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

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

עיכוב בהגעת היומנים

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

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

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

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

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

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

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

החל מגרסה 2.39.0 של סוכן תפעול, סוג המדד של מדדים לא מסוג untyped ב-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