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, כותב למדד.

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

logging:
  service:
    experimental_otel_logging: false

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

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

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

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

יכול להיות שיוצגו שגיאות 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 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: צריך לכתוב את הנקודות לפי הסדר'

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

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

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 receiver ב-config.yaml, המדדים מ-hostmetrics יישלחו פעמיים כי הרכיב receiver ישמש עכשיו בשני צינורות.

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

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

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

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

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

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

הקטעים הבאים רלוונטיים רק ל-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 ומעלה. In some cases, they need to be cleaned up manually though. הקבצים האלה מאוחסנים בתיקיות מקוננות, למשל: /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 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. הבעיה הזו תוקנה ב-Ops Agent מגרסה 2.27.0, אבל בגלל בעיה ידועה ב-Windows שגורמת לשימוש גבוה בזיכרון, מומלץ לשדרג לפחות ל-Ops Agent מגרסה 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 וגרסאות ישנות יותר)

בגרסאות של Ops Agent שקודמות לגרסה 2.17.0, יכול להיות שהסוכן יצרוך הרבה מעבד (CPU), זיכרון ומקום בדיסק עם קובצי /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

הסוכן מתעד ביומן את השגיאה 'אין תמיכה במקלט מדדים מסוג 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