איסוף מדדים של Prometheus

במאמר הזה מתוארת ההגדרה והשימוש במקלט מדדים של סוכן תפעול, שבו אפשר להשתמש כדי לאסוף מדדים מ-Prometheus ב-Compute Engine. במסמך הזה מובאת גם דוגמה שאפשר להשתמש בה כדי לנסות את המקלט.

משתמשים ב-Google Kubernetes Engine יכולים לאסוף מדדים של Prometheus באמצעות השירות המנוהל של Google Cloud ל-Prometheus. מקלט Prometheus של סוכן התפעול מעניק למשתמשי Compute Engine את אותה היכולת.

אתם יכולים להשתמש בכל הכלים ש-Cloud Monitoring מספק, כולל PromQL, כדי להציג ולנתח את הנתונים שנאספים על ידי מקלט Prometheus. לדוגמה, אפשר להשתמש ב-Metrics Explorer, כפי שמתואר במאמר מסוףGoogle Cloud ל-Monitoring, כדי להריץ שאילתות על הנתונים. אפשר גם ליצור לוחות בקרה ומדיניות התראות ב-Cloud Monitoring כדי לעקוב אחרי מדדי Prometheus. מומלץ להשתמש ב-PromQL כשפת השאילתות למדדי Prometheus.

אפשר גם לראות את מדדי Prometheus בממשקים מחוץ ל-Cloud Monitoring, כמו ממשק המשתמש של Prometheus ו-Grafana.

בחירת המקלט המתאים

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

מומלץ להשתמש ב-Ops Agent Prometheus receiver אם התנאים הבאים מתקיימים:

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

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

שילובים קיימים

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

  • קבוצה של workload.googleapis.com מדדים שנבחרו לאפליקציה
  • לוח בקרה להצגת המדדים באופן חזותי.

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

לדוגמה, אם אתם משתמשים בשילוב של Apache Web Server‏ (httpd),‏ סוכן תפעול אוסף חמישה מדדים סקלריים, וכל נקודה על הגרף נחשבת כ-8 בייט. אם משאירים את תדירות הדגימה שמוגדרת כברירת מחדל ב-Ops Agent, שהיא 60 שניות, מספר הבייטים שנקלטים ביום הוא 57,600 כפול מספר המארחים:

  • ‫8 (בייטים) * 1,440 (דקות ביום) * 5 (מדדים) * n (מארחים), או
  • ‫57,600 * n (מארחים)

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

מקלט Prometheus

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

  • מספר המדדים והעוצמה (cardinality) שלהם שמופקים מהאפליקציה שלכם הם בשליטתכם. אין קבוצה של מדדים שנאספו במיוחד. כמות הנתונים שאתם מעבירים נקבעת לפי ההגדרה של אפליקציית Prometheus ומקלט Prometheus של סוכן תפעול.

  • המדדים מוזנים ל-Cloud Monitoring בתור prometheus.googleapis.comמדדים. כשמייבאים את המדדים האלה ל-Cloud Monitoring, הם מסווגים כסוג של מדדים מותאמים אישית, והם כפופים למכסות ולמגבלות של מדדים מותאמים אישית.

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

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

    • מספר המדדים הסקלריים; כל ערך הוא דוגמה אחת
    • מספר מדדי ההתפלגות; כל היסטוגרמה נספרת כ-(2 + מספר הדליים בהיסטוגרמה) דגימות
    • תדירות הדגימה של כל מדד
    • מספר המארחים שמהם נדגמים המדדים

    למידע נוסף על תמחור, אפשר לעיין במאמר תמחור של Google Cloud Observability. דוגמאות מופיעות במאמר דוגמאות לתמחור על סמך דגימות שהועלו.

דרישות מוקדמות

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

ה-receiver של סוכן תפעול דורש נקודת קצה שפולטת מדדי Prometheus. לכן, האפליקציה שלכם צריכה לספק נקודת קצה כזו ישירות או להשתמש בספרייה או בכלי לייצוא של Prometheus כדי לחשוף נקודת קצה. הרבה ספריות ומסגרות שפות כמו Spring ו-DropWizard, או אפליקציות כמו StatsD, ‏ DogStatsD ו-Graphite, שפולטות מדדים שאינם מדדי Prometheus, יכולות להשתמש בספריות לקוח או בייצואנים של Prometheus כדי לפלוט מדדים בסגנון Prometheus. לדוגמה, כדי לשלוח מדדים של Prometheus:

  • משתמשי Spring יכולים להשתמש בספרייה Spring Metrics.
  • משתמשי StatsD יכולים להשתמש בחבילה statsd_exporter.
  • משתמשי Graphite יכולים להשתמש בחבילה graphite_exporter.

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

הגדרת סוכן התפעול

מודל ההגדרות של סוכן תפעול כולל בדרך כלל את ההגדרות הבאות:

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

ההגדרה להטמעת מדדים של Prometheus שונה מעט: אין מעבדים.

הגדרות למדדים של Prometheus

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

  • לא יוצרים מעבד Ops Agent למדדי Prometheus. רכיב Prometheus receiver תומך כמעט בכל אפשרויות ההגדרה שצוינו במפרט scrape_config של Prometheus, כולל אפשרויות של relabeling.

    במקום להשתמש במעבד סוכן תפעול, כל עיבוד המדדים מתבצע באמצעות הקטעים relabel_configs ו-metric_relabel_configs בקובץ ההגדרות של Scape, כפי שמצוין ב-Prometheus receiver. מידע נוסף זמין במאמר שינוי התוויות: שינוי הנתונים שמתבצעת לגביהם פעולת גירוד.

  • אתם מגדירים את צינור עיבוד הנתונים של Prometheus רק במונחים של מקלט Prometheus. לא מציינים מעבדים. בנוסף, אי אפשר להשתמש בצינור ב-Prometheus במקבלי נתונים שאינם Prometheus עבור מדדי Prometheus.

רוב ההגדרות של המקלט הן האפשרויות של scrape-config. כדי שההסבר יהיה תמציתי, לא נכללות כאן האפשרויות האלה. בהמשך מוצגת המבנה של הגדרת Ops Agent שמשתמשת ב-Prometheus receiver. אתם מציינים את הערכים של RECEIVER_ID ושל PIPELINE_ID.

metrics:
  receivers:
    RECEIVER_ID:
      type: prometheus
      config:
        scrape_configs:
          [... omitted for brevity ...]

  service:
    pipelines:
      PIPELINE_ID:
        receivers: [RECEIVER_ID]

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

מקלט Prometheus

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

  • הקטעים של גילוי השירות, *_sd_config.
  • ההגדרה honor_labels.

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

המבנה המלא של Prometheus receiver מוצג בהמשך:

metrics:
  receivers:
    prom_application:
      type: prometheus
      config:
        scrape_configs:
          - job_name: 'STRING' # must be unique across all Prometheus receivers
            scrape_interval: # duration, like 10m or 15s
            scrape_timeout:  # duration, like 10m or 15s
            metrics_path: # resource path for metrics, default = /metrics
            honor_timestamps: # boolean, default = false
            scheme: # http or https, default = http
            params:
              - STRING: STRING
            basic_auth:
              username: STRING
              password: SECRET
              password_file: STRING
            authorization:
              type: STRING # default = Bearer
              credentials: SECRET
              credentials_file: FILENAME

            oauth2: OAUTH2 # See Prometheus oauth2
            follow_redirects: # boolean, default = true
            enable_http2: # boolean, default = true
            tls_config: TLS_CONFIG # See Prometheus tls_config
            proxy_url: STRING

            static_configs:
              STATIC_CONFIG # See Prometheus static_config
            relabel_configs:
              RELABEL_CONFIG # See Prometheus relabel_config
            metric_relabel_configs:
              METRIC_RELABEL_CONFIGS # See Prometheus metric_relabel_configs

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

דוגמה: הגדרת סוכן תפעול ל-Prometheus

בקטע הזה מוצגת דוגמה להגדרה של סוכן תפעול לאיסוף מדדים של Prometheus מאפליקציה. בדוגמה הזו נעשה שימוש ב-JSON Exporter (json_exporter) שסופק על ידי קהילת Prometheus, שחושף מדדים של Prometheus ביציאה 7979.

כדי להגדיר את הדוגמה, צריך את המשאבים הבאים, שאולי תצטרכו להתקין:

  • git
  • curl
  • make
  • python3
  • שפת Go, גרסה 1.19 ואילך

יצירה או הגדרה של האפליקציה

כדי לקבל ולהפעיל את הכלי לייצוא JSON, פועלים לפי השלבים הבאים:

  1. משכפלים את מאגר json_exporter ומחלצים את הכלי לייצוא על ידי הרצת הפקודות הבאות:

    git clone https://github.com/prometheus-community/json_exporter.git

cd json_exporter

git checkout v0.5.0

  2. מריצים את הפקודה הבאה כדי ליצור את כלי הייצוא:

    make build

  3. מפעילים את שרת ה-HTTP של Python באמצעות הפקודה הבאה:

    python3 -m http.server 8000 &

  4. מריצים את הפקודה הבאה כדי להפעיל את הכלי JSON Exporter:

    ./json_exporter --config.file examples/config.yml &

  5. מריצים שאילתה על JSON Exporter כדי לוודא שהוא פועל ומציג מדדים ביציאה 7979:

    curl "http://localhost:7979/probe?module=default&target=http://localhost:8000/examples/data.json"

    אם השאילתה הצליחה, הפלט ייראה כך:

    # HELP example_global_value Example of a top-level global value scrape in the json
# TYPE example_global_value untyped
example_global_value{environment="beta",location="planet-mars"} 1234
# HELP example_value_active Example of sub-level value scrapes from a json
# TYPE example_value_active untyped
example_value_active{environment="beta",id="id-A"} 1
example_value_active{environment="beta",id="id-C"} 1
# HELP example_value_boolean Example of sub-level value scrapes from a json
# TYPE example_value_boolean untyped
example_value_boolean{environment="beta",id="id-A"} 1
example_value_boolean{environment="beta",id="id-C"} 0
# HELP example_value_count Example of sub-level value scrapes from a json
# TYPE example_value_count untyped
example_value_count{environment="beta",id="id-A"} 1
example_value_count{environment="beta",id="id-C"} 3

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

הוספת צינור ורכיב לקליטת נתונים של Ops Agent

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

  1. עורכים את קובץ התצורה של סוכן תפעול, /etc/google-cloud-ops-agent/config.yaml, ומוסיפים את רשומות ה-receiver וה-pipeline הבאות של Prometheus:

    metrics:
  receivers:
    prometheus:
        type: prometheus
        config:
          scrape_configs:
            - job_name: 'json_exporter'
              scrape_interval: 10s
              metrics_path: /probe
              params:
                module: [default]
                target: [http://localhost:8000/examples/data.json]
              static_configs:
                - targets: ['localhost:7979']
  service:
    pipelines:
      prometheus_pipeline:
        receivers:
          - prometheus

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

    דוגמאות להגדרות של שינוי תוויות ב-receiver מופיעות במאמר הגדרות נוספות של receiver.

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

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

LINUX

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

    sudo service google-cloud-ops-agent restart

  2. כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:

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

Windows

  1. מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.

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

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

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

  4. כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:

    Get-Service google-cloud-ops-agent*

מדדי Prometheus ב-Cloud Monitoring

אפשר להשתמש בכלים שמוצעים על ידי Cloud Monitoring עם הנתונים שנאספים על ידי Prometheus receiver. לדוגמה, אפשר ליצור תרשים של נתונים באמצעות Metrics Explorer, כפי שמתואר במאמר בנושא מסוףGoogle Cloud ל-Monitoring. בקטעים הבאים מפורטים כלי השאילתות שזמינים ב-Cloud Monitoring עם Metrics Explorer:

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

אפשר גם לראות את המדדים בממשקים אחרים, כמו ממשק המשתמש של Prometheus ו-Grafana. מידע על הגדרת הממשקים האלה זמין בקטעים הבאים במאמרי העזרה בנושא השירות המנוהל של Google Cloud ל-Prometheus:

שימוש ב-PromQL

‫PromQL היא שפת השאילתות המומלצת למדדים שמועברים באמצעות מקלט Prometheus.

הדרך הפשוטה ביותר לוודא שהנתונים שלכם מ-Prometheus נקלטים היא באמצעות הדף Metrics Explorer ב-Cloud Monitoring במסוף Google Cloud :

  1. במסוף Google Cloud , עוברים לדף  Metrics explorer:

    כניסה אל Metrics Explorer

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

  2. בסרגל הכלים של חלונית הכלי ליצירת שאילתות, לוחצים על הלחצן ששמו הוא  MQL או  PromQL.

  3. מוודאים שהאפשרות PromQL נבחרה במתג שפה. המתג לשפה נמצא באותו סרגל כלים שבו אפשר לעצב את השאילתה.

  4. מזינים את השאילתה הבאה בעורך ולוחצים על Run query:

    up

אם הנתונים שלכם מוזנים, יופיע תרשים כמו זה:

תרשים של Metrics Explorer למדד json-exporter up.

אם אתם מריצים את הדוגמה של JSON Exporter, תוכלו גם להריץ שאילתות כמו הבאות:

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

    example_value_count

    בדוגמה הבאה מוצג תרשים של example_value_count, כולל תוויות שהוגדרו על ידי האפליקציה JSON Exporter ותוויות שנוספו על ידי Ops Agent:

    תרשים ב-Metrics Explorer של המדד example_value_count של json-exporter.

  • שליחת שאילתות לגבי נתונים של מדד שיוצא ממרווח שמות ספציפי. הערך של התווית namespace הוא מזהה המופע של Compute Engine, מספר ארוך כמו 5671897148133813325, שמוקצה למכונה הווירטואלית. דוגמה לשאילתה:

    example_value_count{namespace="INSTANCE_ID"}

  • שאילתת נתונים שתואמים לביטוי רגולרי ספציפי. ה-JSON Exporter פולט מדדים עם תווית id שמקבלת ערכים כמו id-A, id-B, id-C. כדי לסנן את כל המדדים עם תווית id שתואמת לתבנית הזו, משתמשים בשאילתה הבאה:

    example_value_count{id=~"id.*"}

מידע נוסף על השימוש ב-PromQL ב-Metrics Explorer ובטבלאות של Cloud Monitoring זמין במאמר PromQL ב-Cloud Monitoring.

הצגת דפוסי שימוש וביצועים ואבחון במדדים ב-Cloud Monitoring

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

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

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

כדי להציג את הדף ניהול מדדים:

  1. נכנסים לדף  Metrics management במסוף Google Cloud :

    כניסה אל ניהול מדדים

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

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

מידע נוסף על הדף ניהול מדדים זמין במאמר איך רואים ומנהלים את השימוש במדדים.

משאב prometheus_target

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

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

  • ‫project_id: המזהה של Google Cloud הפרויקט, כמו my-project, שבו פועל סוכן התפעול.
  • ‫location: האזור Google Cloud או אזור AWS שבו פועל סוכן התפעול; לדוגמה, us-east1-a (Google Cloud) או aws:us-east-1a (AWS).
  • ‫cluster: תמיד __gce__ למדדי Prometheus שנאספים באמצעות סוכן תפעול.
  • ‫namespace: מזהה המכונה של Compute Engine שבה פועל סוכן תפעול.
  • ‫job: הערך של השדה job_name בתצורת המקלט.
  • ‫instance: התווית של מופע היעד של Prometheus, שנלקחת מההגדרה של מקבל הנתונים. ברירת המחדל היא היעד.

הערכים של התוויות האלה מוגדרים במהלך האיסוף. הערכים של התוויות namespace, location ו-cluster הם קבועים. אם המדדים שחולצו מהאפליקציה כוללים גם את התוויות האלה, סוכן תפעול מוסיף את המחרוזת exported_ כקידומת לתוויות שחולצו.

שינוי התוויות: שינוי הנתונים שמועברים

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

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

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

מידע נוסף על שינוי תוויות זמין במאמרי העזרה של Prometheus בנושא relabel_config ו-metric_relabel_configs.

תוויות מטא של Compute Engine שזמינות במהלך שינוי התוויות

כשסוכן התפעול (Ops Agent) מבצע גירוד של מדדים, הוא כולל קבוצה של תוויות מטא שהערכים שלהן מבוססים על ההגדרה של המכונה הווירטואלית ב-Compute Engine שבה הסוכן פועל. אתם יכולים להשתמש בתוויות האלה ובקטע relabel_configs של Prometheus receiver כדי להוסיף מטא נתונים נוספים למדדים לגבי המכונה הווירטואלית שממנה הם נאספו. דוגמה מופיעה במאמר בנושא הגדרות נוספות של מקלט.

התוויות הבאות של מטא זמינות ביעדים לשימוש בקטע relabel_configs:

  • ‫__meta_gce_instance_id: המזהה המספרי של מכונת Compute Engine (מקומית)
  • ‫__meta_gce_instance_name: השם של מכונת Compute Engine (מקומית). סוכן תפעול ממקם את הערך הזה באופן אוטומטי בתווית instance_name שניתנת לשינוי במדדים.
  • __meta_gce_machine_type: כתובת URL מלאה או חלקית של סוג המכונה של המופע. סוכן תפעול מציב את הערך הזה באופן אוטומטי בתווית machine_type שניתנת לשינוי במדדים.
  • ‫__meta_gce_metadata_NAME: כל פריט מטא-נתונים של המופע
  • ‫__meta_gce_network: כתובת ה-URL של הרשת של המכונה
  • ‫__meta_gce_private_ip: כתובת ה-IP הפרטית של המכונה
  • ‫__meta_gce_interface_ipv4_NAME: כתובת IPv4 של כל ממשק עם שם
  • ‫__meta_gce_project: Google Cloud הפרויקט שבו המופע פועל (מקומי)
  • ‫__meta_gce_public_ip: כתובת ה-IP הציבורית של המכונה, אם קיימת
  • ‫__meta_gce_tags: רשימה מופרדת בפסיקים של תגי מופעים
  • ‫__meta_gce_zone: כתובת ה-URL של אזור Compute Engine שבו המכונה פועלת

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

הגדרות נוספות של הנמען

בקטע הזה מופיעות דוגמאות לשימוש בקטעים relabel_configs ו-metric_relabel_configs של מקלט Prometheus כדי לשנות את המספר והמבנה של המדדים שנקלטים. בקטע הזה יש גם גרסה שונה של המקלט לדוגמה של JSON Exporter שמשתמשת באפשרויות של שינוי התוויות.

הוספת מטא-נתונים של מכונה וירטואלית

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

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

relabel_configs:
  - source_labels: [__meta_gce_zone]
    regex: '(.+)'
    replacement: '${1}'
    target_label: zone

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

הסרת מדדים

אפשר להשתמש בקטע metrics_relabel_configs כדי להשמיט מדדים שלא רוצים להוסיף למאגר. התבנית הזו שימושית לצמצום העלויות. לדוגמה, אפשר להשתמש בתבנית הבאה כדי להשמיט כל מדד עם שמות שתואמים ל-METRIC_NAME_REGEX_1 או ל-METRIC_NAME_REGEX_2:

metric_relabel_configs:
  - source_labels: [ __name__ ]
    regex: 'METRIC_NAME_REGEX_1'
    action: drop
  - source_labels: [ __name__ ]
    regex: 'METRIC_NAME_REGEX_2'
    action: drop

הוספת תוויות סטטיות

אפשר להשתמש בקטע metrics_relabel_configs כדי להוסיף תוויות סטטיות לכל המדדים שנקלטים על ידי מקלט Prometheus. אפשר להשתמש בדפוס הבא כדי להוסיף את התוויות staticLabel1 ו-staticLabel2 לכל המדדים שנוספו:

metric_relabel_configs:
  - source_labels: [ __address__ ]
    action: replace
    replacement: 'STATIC_VALUE_1'
    target_label: staticLabel1
  - source_labels: [ __address__ ]
    action: replace
    replacement: 'STATIC_VALUE_2'
    target_label: staticLabel2

בדוגמה הבאה של JSON Exporter נעשה שימוש בדפוסי ההגדרה האלה כדי לבצע את הפעולות הבאות:

  • מגדירים את התווית zone מהערך של תווית המטא __meta_gce_zone שסופקה על ידי Ops Agent.
  • מבטלים את המדד example_global_value של הכלי לייצוא.
  • מוסיפים את התווית staticLabel עם הערך 'ערך סטטי' לכל המדדים שנאספים.
metrics:
  receivers:
    prometheus:
        type: prometheus
        config:
          scrape_configs:
            - job_name: 'json_exporter'
              scrape_interval: 10s
              metrics_path: /probe
              params:
                module: [default]
                target: [http://localhost:8000/examples/data.json]
              static_configs:
                - targets: ['localhost:7979']
              relabel_configs:
                - source_labels: [__meta_gce_zone]
                  regex: '(.+)'
                  replacement: '${1}'
                  target_label: zone
              metric_relabel_configs:
                - source_labels: [ __name__ ]
                  regex: 'example_global_value'
                  action: drop
                - source_labels: [ __address__ ]
                  action: replace
                  replacement: 'A static value'
                  target_label: staticLabel