איך מתחילים להשתמש באיסוף נתונים בהטמעה עצמית

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

במאמר הזה מוסבר איך:

  • מגדירים את הסביבה ואת כלי שורת הפקודה.
  • מגדירים חשבון שירות לאיחוד זהויות של עומסי עבודה באשכולות עם GKE.
  • הפעלת קובץ הבינארי של Prometheus ב-Kubernetes.
  • קובעים אילו מדדים מוזנים לשירות המנוהל ל-Prometheus.
  • שילוב של השירות המנוהל ל-Prometheus עם הגדרות של prometheus-operator.
  • קומפילציה והרצה ידנית של קובץ ה-Prometheus הבינארי.

כשמפעילים איסוף נתונים עצמאי, ממשיכים לנהל את ההתקנה של Prometheus כמו תמיד. ההבדל היחיד הוא שאתם מריצים את הקובץ הבינארי של תחליף ה-drop-in של השירות המנוהל ל-Prometheus,‏ gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2, במקום הקובץ הבינארי של Prometheus במעלה הזרם.

הקובץ הבינארי שניתן להטמעה מספק אפשרויות הגדרה נוספות באמצעות הדגלים --export.*. מידע נוסף מופיע בפלט של האפשרות --help. במאמר הזה מפורטות האפשרויות החשובות ביותר.

שירות מנוהל ל-Prometheus לא תומך בייצוא מדדים משרת איחוד או משרת שמשמש כמקלט של remote-write. אתם יכולים לשכפל את כל הפונקציות של שרת האיחוד, כולל צמצום נפח ההטמעה על ידי צבירת נתונים לפני השליחה אל Monarch, באמצעות מסננים וצבירות מקומיות.

הזרמת נתונים לשירות המנוהל ל-Prometheus צורכת משאבים נוספים. אם אתם פורסים אוספי נתונים באופן עצמאי, מומלץ להגדיל את מגבלות השימוש במעבד ובזיכרון פי 5, ולשנות אותן בהתאם לשימוש בפועל.

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

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

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

הגדרת פרויקטים וכלים

כדי להשתמש בשירות המנוהל של Google Cloud ל-Prometheus, אתם צריכים את המשאבים הבאים:

  • Google Cloud פרויקט שבו מופעל Cloud Monitoring API.

    • אם אין לכם Google Cloud פרויקט, אתם יכולים ליצור אחד.

      1. במסוף Google Cloud , עוברים אל New Project:

        יצירת פרויקט חדש

      2. בשדה שם הפרויקט, מזינים שם לפרויקט ולוחצים על יצירה.

      3. עוברים אל חיוב:

        לדף החיוב

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

      5. תתבקשו לבחור פרופיל תשלומים קיים או ליצור פרופיל תשלומים חדש.

      ה-API של Monitoring מופעל כברירת מחדל בפרויקטים חדשים.

    • אם כבר יש לכם פרויקט ב- Google Cloud , צריך לוודא ש-Monitoring API מופעל:

      1. עוברים אל APIs & services:

        עוברים אל APIs & services

      2. בוחרים את הפרויקט הרצוי.

      3. לוחצים על Enable APIs and Services.

      4. מחפשים את 'מעקב'.

      5. בתוצאות החיפוש, לוחצים על Cloud Monitoring API.

      6. אם לא מוצגת האפשרות 'API enabled' (ה-API מופעל), לוחצים על הלחצן Enable (הפעלה).

  • אשכול Kubernetes. אם אין לכם אשכול Kubernetes, פועלים לפי ההוראות שבמדריך למתחילים של GKE.

אתם צריכים גם את כלי שורת הפקודה הבאים:

  • gcloud
  • kubectl

הכלים gcloud ו-kubectl הם חלק מ-Google Cloud CLI. מידע על התקנת הרכיבים האלה מופיע במאמר ניהול רכיבי Google Cloud CLI. כדי לראות את הרכיבים של ה-CLI של gcloud שהתקנתם, מריצים את הפקודה הבאה:

gcloud components list

הגדרת הסביבה

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

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

    • מגדירים את ה-CLI של gcloud כך שיפנה למזהה של פרויקטGoogle Cloud :

      gcloud config set project PROJECT_ID

    • אם אתם מריצים את הפקודה ב-GKE, צריך להשתמש ב-CLI של gcloud כדי להגדיר את האשכול:

      gcloud container clusters get-credentials CLUSTER_NAME --location LOCATION --project PROJECT_ID

    • אחרת, משתמשים ב-CLI של kubectl כדי להגדיר את האשכול:

      kubectl config set-cluster CLUSTER_NAME

    מידע נוסף על הכלים האלה:

הגדרת מרחב שמות

יוצרים את מרחב השמות NAMESPACE_NAME Kubernetes בשביל המשאבים שיוצרים כחלק מאפליקציית הדוגמה. מומלץ להשתמש בשם מרחב השמות gmp-test כשמשתמשים במסמכי התיעוד האלה כדי להגדיר דוגמה של הגדרת Prometheus.

יוצרים את מרחב השמות באמצעות הפקודה הבאה:

kubectl create ns NAMESPACE_NAME

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

אם באשכול Kubernetes שלכם מופעל איחוד זהויות של עומסי עבודה ל-GKE, אתם יכולים לדלג על הקטע הזה.

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

הגדרת חשבון שירות לשימוש באיחוד זהויות של עומסי עבודה ב-GKE

אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול Kubernetes, אפשר לדלג על הקטע הזה.

השירות המנוהל ל-Prometheus אוסף נתוני מדדים באמצעות Cloud Monitoring API. אם באשכול שלכם נעשה שימוש באיחוד זהויות של עומסי עבודה ל-GKE, אתם צריכים לתת לחשבון השירות של Kubernetes הרשאה ל-Monitoring API. בקטע הזה מתוארים הנושאים הבאים:

יצירה של חשבון השירות וקישור שלו

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

קודם יוצרים חשבון שירות, אם עדיין לא עשיתם זאת:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa

אחר כך משתמשים ברצף הפקודות הבא כדי לקשר את חשבון השירות gmp-test-saלחשבון השירות שמוגדר כברירת מחדל ב-Kubernetes במרחב השמות NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --condition=None \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

אם אתם משתמשים במרחב שמות או בחשבון שירות אחרים של GKE, צריך לשנות את הפקודות בהתאם.

אישור חשבון השירות

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

הפקודה הבאה מעניקה לחשבון השירות Google Cloud , את התפקידים ב-Monitoring API שדרושים לו כדי לכתוב נתוני מדדים.gmp-test-sa

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

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter \
  --condition=None \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/iam.serviceAccountTokenCreator \
  --condition=None

ניפוי באגים בהגדרת איחוד הזהויות של עומסי עבודה ל-GKE

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

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

איחוד זהויות של עומסי עבודה ל-GKE בסביבות ייצור

בדוגמה שמתוארת במסמך הזה, חשבון השירות Google Cloud משויך לחשבון השירות שמוגדר כברירת מחדל ב-Kubernetes, ומקבל את כל ההרשאות הנדרשות לשימוש ב-Monitoring API. Google Cloud

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

הגדרה של איסוף נתונים בהטמעה עצמית

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

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

אפליקציית הדוגמה פולטת את מדד הדלפק example_requests_total ואת מדד ההיסטוגרמה example_random_numbers (בין היתר) ביציאה metrics שלה. המניפסט של האפליקציה מגדיר שלוש רפליקות.

כדי לפרוס את האפליקציה לדוגמה, מריצים את הפקודה הבאה:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/example-app.yaml

מריצים את הקובץ הבינארי של Prometheus להחלפה

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

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

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/prometheus.yaml

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

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

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

  2. מוודאים שה-pods של שרת Prometheus והאפליקציה לדוגמה נפרסו בהצלחה:

    kubectl -n NAMESPACE_NAME get pod

    אם הפריסה בוצעה בהצלחה, הפלט אמור להיראות כך:

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

אם אתם מריצים את המערכת ב-GKE, אתם יכולים לבצע את הפעולות הבאות:

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

הזנת פרטי הכניסה באופן מפורש

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

  1. מגדירים את ההקשר לפרויקט היעד:

    gcloud config set project PROJECT_ID

  2. יוצרים חשבון שירות:

    gcloud iam service-accounts create gmp-test-sa

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

  3. מעניקים לחשבון השירות את ההרשאות הנדרשות:

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. יוצרים ומורידים מפתח לחשבון השירות:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. מוסיפים את קובץ המפתח כסוד לאשכול שאינו GKE:

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. פותחים את משאב Prometheus StatefulSet לעריכה:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. מוסיפים את הטקסט שמופיע בהדגשה למשאב:

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

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

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

    נושאים נוספים לאיסוף נתונים בהטמעה עצמית

    בקטע הזה מוסבר איך:

    • מסננים את הנתונים שמייצאים לשירות המנוהל.
    • להמיר את הגדרות הפריסה הקיימות.
    • מריצים את הקובץ הבינארי של Prometheus במצב זמינות גבוהה.
    • יוצרים ומריצים את הקובץ הבינארי של Prometheus החלופי.
    • הפעלת השירות המנוהל ל-Prometheus מחוץ ל- Google Cloud.

    סינון מדדים מיוצאים

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

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

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

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

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

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

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

    כדי לכלול מדדים מסוג histogram במסנן, צריך לציין את המדדים _count, _sum ו-_bucket. אפשר לעשות את זה גם באמצעות התאמה לתו כללי, לדוגמה, הסלקטור {__name__=~"histogram_metric_.+"}.

    אם אתם משתמשים בספרייה prometheus-operator, אתם יכולים להגדיר דגלים של --export.match באמצעות משתנה הסביבה EXTRA_ARGS של הקונטיינר. מידע נוסף זמין במאמר בנושא שימוש ב-prometheus-operator.

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

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

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

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

    שימוש ב-prometheus-operator

    אפשר להשתמש בקובץ הבינארי של Prometheus בשירות המנוהל ל-Prometheus גם עם פריסת GKE Prometheus קיימת שמנוהלת על ידי prometheus-operator.

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

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

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

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

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

    2. משנים את משאב Prometheus כדי להוסיף את הטקסט שמוצג באותיות מודגשות:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: NAMESPACE_NAME
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

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

    שימוש ב-kube-prometheus

    אתם יכולים להגדיר פריסות שנוצרו באמצעות הספרייה הפופולרית kube-prometheus כך שישתמשו בשירות מנוהל ל-Prometheus.

    ל-Kube-prometheus יש כמה תלות פנימית הדוקה במרחבי השמות ובחשבונות השירות שמוגדרים כברירת מחדל, ולכן מומלץ לשנות רק את המספר המינימלי של השדות שנדרשים לשליחת נתונים אל שירות מנוהל ל-Prometheus.

    בתוך manifests/prometheus-prometheus.yaml, מחליפים את מפרט התמונה ומשביתים את איסוף הנתונים בזמינות גבוהה על ידי הקטנת replicas ל-1:

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2
      ...
      replicas: 1
      version: v2.35.0
      ...

    אם אתם מפעילים את GKE ולא שיניתם את חשבון השירות שמוגדר כברירת מחדל בצומת, אחרי שתחיל את המניפסטים ששונו, הנתונים יתחילו להישלח באופן מיידי אל שירות מנוהל ל-Prometheus. אחרת, יכול להיות שתצטרכו להגדיר ולהחיל חשבון שירות. כשמריצים ב-GKE ומשתמשים ב-Workload Identity, יכול להיות שתצטרכו ליצור ולאשר את חשבון השירות prometheus-k8s במרחב השמות monitoring. כשמריצים באשכול Kubernetes שאינו GKE, פועלים לפי ההוראות בקטע בנושא prometheus-operator.

    שימו לב: kube-prometheus אוסף הרבה מדדים כברירת מחדל, ורובם לא נחוצים בסביבת Kubernetes מנוהלת כמו GKE. כדי לחסוך בעלויות של הכנסת נתונים, אפשר להתאים אישית את kube-prometheus כך שהוא יגרד רק את המדדים שחשובים לכם ויסנן את המדדים המיוצאים בצורה אגרסיבית.

    הצעות נוספות מופיעות במאמר אמצעים לבקרת עלויות ושיוך.

    פריסה עם זמינות גבוהה

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

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

    שרת ה-API של Kubernetes הוא קצה עורפי נתמך לבחירת מנהיג, ואפשר להפעיל אותו על ידי הגדרת הדגלים הבאים:

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    הערכים LEASE_NAMESPACE ו-LEASE_NAME מזהים את משאב ההשכרה שדרכו מתבצעת בחירת המנהיג. כל שרתי Prometheus שמפנים לאותו משאב שייכים לאותה קבוצת עותקים. לחשבון השירות של Kubernetes בפריסת Prometheus צריכה להיות הרשאה לקרוא ולכתוב את משאב ההשכרה המתאים. כשמריצים את שרת Prometheus מחוץ לאשכול Kubernetes, אפשר לספק הגדרה מפורשת באמצעות הדגל --export.ha.kube.config.

    אחרי שתעשו את זה, תוכלו להגדיל את הערך של replicas ל-2 או יותר.

    תוויות שמורות

    בשירות המנוהל ל-Prometheus נעשה שימוש ב-6 תוויות שמורות כדי לזהות משאב באופן ייחודי ב-Monarch:

    • ‫project_id: המזהה של Google Cloud הפרויקט שמשויך למדד. חובה.
    • location: המיקום הפיזי (Google Cloud אזור) שבו הנתונים מאוחסנים. הערך הזה הוא בדרך כלל האזור של אשכול GKE. אם הנתונים נאספים מפריסה של AWS או מפריסה מקומית, יכול להיות שהערך יהיה האזור הקרוב ביותר Google Cloud . חובה.
    • ‫cluster: השם של אשכול Kubernetes שמשויך למדד. אם לא מפעילים את התכונה ב-Kubernetes, אפשר להשתמש בה כרמת היררכיה שרירותית, כמו קבוצת מופעים. אופציונלי, אבל מומלץ מאוד.
    • ‫namespace: השם של מרחב השמות של Kubernetes שמשויך למדד. אם לא מפעילים את התכונה ב-Kubernetes, אפשר להשתמש בה כרמת היררכיה שרירותית, כמו קבוצת משנה של מופע. אופציונלי, אבל מומלץ מאוד.
    • ‫job: תווית העבודה של יעד Prometheus, אם ידועה. יכול להיות שתוצאות של הערכת כללים יהיו ריקות. חובה, ובדרך כלל מתווסף אוטומטית על ידי Prometheus.
    • ‫instance: תווית המופע של יעד Prometheus, אם ידועה; יכול להיות שיהיה ריק בתוצאות של הערכת כלל. חובה, ובדרך כלל מתווסף אוטומטית על ידי Prometheus. אם מגדירים או משנים את התווית באופן ידני, לא משתמשים בערכים שמוגדרים בהארדקוד כמו localhost, כי זה גורם להתנגשויות בסדרות הזמן.

    כשמריצים את הפקודה ב- Google Cloud, התוויות project_id, location ו-cluster מוספות אוטומטית לכל מדד.

    לא מומלץ להשתמש באפשרות הזו כשמריצים את Google Cloud, אבל אפשר לבטל את התוויות project_id, location, cluster ו-namespace באמצעות הקטע global.external_labels בהגדרות של Prometheus. מידע נוסף מופיע במאמר הפעלת איסוף שבוצע בהגדרה עצמית מחוץ ל-Google Cloud.

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

    הגדרה של statsd_exporter ומייצאים אחרים שמדווחים על מדדים באופן מרכזי

    אם אתם משתמשים ב-statsd_exporter ל-Prometheus, ב-Envoy ל-Istio, ב-SNMP exporter, ב-Prometheus Pushgateway, ב-kube-state-metrics, או אם יש לכם exporter דומה אחר שמתווך ומדווח על מדדים בשם משאבים אחרים שפועלים בסביבה שלכם, אתם צריכים לבצע כמה שינויים קטנים כדי שה-exporter יפעל עם שירות מנוהל ל-Prometheus.

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

    פריסות בינאריות

    אם רוצים להריץ בסביבה שלא מבוססת על קונטיינרים, אפשר ליצור ישירות את הקובץ הבינארי של Prometheus.

    בניית המקור

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

    כדי ליצור את הקובץ הבינארי הרגיל, צריך להתקין במחשב את ערכת הכלים של Go ואת הגרסאות העדכניות של NPM/Yarn. מידע נוסף זמין בהוראות לבניית upstream.

    1. משכפלים את המאגר:

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. בודקים את תג הגרסה הרצוי:

      git checkout v2.53.5-gmp.1

    3. כדי ליצור קובץ tarball של שירות מנוהל ל-Prometheus, מריצים את הפקודות הבאות:

      make build && make tarball

    קובץ ה-tarball והקובץ הבינארי שמתקבלים תואמים באופן מלא לגרסאות המקוריות שלהם מבחינת מבנה הספרייה והפונקציונליות.

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

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

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

    מידע נוסף מופיע במאמר פתרון בעיות.

    הפעלת איסוף שהופעל עצמאית מחוץ ל- Google Cloud

    בסביבות Compute Engine, בסביבות GKE או במכונה שבה הפעלתם את gcloud login עם חשבון בעל הרשאה מספקת, אתם יכולים להפעיל איסוף שבוצע באמצעות פריסה עצמית בלי לבצע הגדרות נוספות. מחוץ ל- Google Cloud, צריך לספק באופן מפורש פרטי כניסה, project_id שיכיל את המדדים ו-location (אזורGoogle Cloud ) לאחסון המדדים. מומלץ להגדיר גם את התוויות cluster ו-namespace, גם אם ההרצה מתבצעת בסביבה שאינה Kubernetes.

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

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

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

    אם מפעילים בסביבת Kubernetes, צריך להגדיר את הערכים cluster ו-namespace לאשכול ולמרחב השמות המקומיים. אם מריצים מחוץ ל-Kubernetes, צריך להגדיר ערכים שמתאימים להיררכיה. לדוגמה, בסביבה מבוססת מכונה וירטואלית שפועלת ב-AWS, מגדירים את הערך cluster ל-__aws__ ואת הערך namespace למזהה המופע. אפשר למלא את מזהה המופע באופן דינמי באמצעות כלל לשינוי תוויות שקורא לשרת המטא-נתונים המקומי.

    כדי להריץ קובץ בינארי מקומי של Prometheus עם מעקב עצמי, אפשר להשתמש בפקודה הבאה:

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    בדוגמה הזו, המשתנה REGION מוגדר לערך כמו us-central1.

    עם זאת, מומלץ להגדיר את תוויות היעד export לשירות המנוהל בקטע global.external_labels של קובץ ההגדרות של Prometheus. לדוגמה, בסביבות Kubernetes אפשר להשתמש בהגדרה הבאה:

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    הפעלת השירות המנוהל ל-Prometheus מחוץ ל- Google Cloud כרוכה בתשלום על העברת נתונים. יש עמלות על העברת נתונים אל Google Cloud, ויכול להיות שיהיו עמלות על העברת נתונים מענן אחר. אפשר לצמצם את העלות הזו למינימום על ידי הפעלת דחיסה באמצעות הדגל --export.compression=gzip.

    המאמרים הבאים