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

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

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

  • מגדירים את הסביבה ואת כלי שורת הפקודה.
  • מגדירים חשבון שירות ל-Workload Identity Federation באשכולות עם 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. בשדה Project Name (שם הפרויקט), מזינים שם לפרויקט ולוחצים על Create (יצירה).

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

        לדף החיוב

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

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

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

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

      1. עוברים לדף Monitoring API library במסוףGoogle Cloud :

        לדף ספרייה

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

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

  • אשכול 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 gmp-test-sa, את התפקידים ב-Monitoring API שנדרשים לו כדי לכתוב נתוני מדדים.

אם כבר הקציתם לחשבון השירות 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, וחשבון השירות Google Cloudמקבל את כל ההרשאות הנדרשות לשימוש ב-Monitoring API.

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

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

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

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

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

    2. מבצעים Checkout לתג הגרסה הרצוי:

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

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