השירות המנוהל של Google Cloud ל-Prometheus

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

השירות המנוהל ל-Prometheus אוסף מדדים מ-Prometheus exporters ומאפשר לשלוח שאילתות על הנתונים באופן גלובלי באמצעות PromQL. המשמעות היא שאפשר להמשיך להשתמש בלוחות בקרה קיימים של Grafana, בהתראות מבוססות PromQL ובזרימות עבודה. הוא תואם לענן היברידי ולסביבות מרובות עננים, יכול לנטר את Kubernetes, מכונות וירטואליות ועומסי עבודה ללא שרת ב-Cloud Run, שומר נתונים למשך 24 חודשים ושומר על ניידות על ידי שמירה על תאימות ל-Prometheus. אתם יכולים גם להשתמש ב-PromQL כדי לשלוח שאילתות על יותר מ-6,500 מדדים בחינם ב-Cloud Monitoring, כולל מדדי מערכת בחינם של GKE, כדי להשלים את המעקב ב-Prometheus.

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

הסבר על השימוש בשירות מנוהל ל-Prometheus ב-Home Depot כדי לקבל תצפית מאוחדת על 2,200 חנויות שפועלות על אשכולות Kubernetes מקומיים:

סקירה כללית של המערכת

השירות המנוהל של Google Cloud ל-Prometheus מאפשר לכם להשתמש ב-Prometheus המוכר, עם תמיכה בתשתית הגלובלית, מרובת העננים והחוצה-פרויקטים של Cloud Monitoring.

השירות המנוהל ל-Prometheus מאפשר לכם לגשת לתכונות של Prometheus ו-Cloud Monitoring.

‫שירות מנוהל ל-Prometheus מבוסס על Monarch, אותו מאגר נתונים ניתן להרחבה גלובלית שמשמש את Google למטרות מעקב. השירות המנוהל ל-Prometheus משתמש באותם בק-אנד ובאותם ממשקי API כמו Cloud Monitoring, ולכן אפשר לשלוח שאילתות על מדדי Cloud Monitoring ועל מדדים שנקלטים על ידי השירות המנוהל ל-Prometheus באמצעות PromQL ב-Cloud Monitoring,‏ Grafana או כל כלי אחר שיכול לקרוא את Prometheus API.

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

  • איסוף הנתונים מתבצע על ידי כלי איסוף מנוהלים, כלי איסוף שמוטמעים באופן עצמאי, OpenTelemetry Collector או Ops Agent. הכלי Ops Agent סורק את נתוני הייצוא המקומיים ומעביר את הנתונים שנאספו אל Monarch. אפשר להשתמש באמצעי האיסוף האלה עבור עומסי עבודה של Kubernetes, של בלי שרת (serverless) ושל מכונות וירטואליות מסורתיות, והם יכולים לפעול בכל מקום, כולל בעננים אחרים ובפריסות מקומיות.
  • ‫Query evaluation מנוהל על ידי Monarch, שמבצע שאילתות ומאחד תוצאות בכל האזורים של Google Cloudועד 3,500 פרויקטים שלGoogle Cloud .
  • הערכת הכללים וההתראות מתבצעת באחת משתי דרכים: על ידי כתיבת התראות ב-PromQL ב-Cloud Monitoring שמופעלות באופן מלא בענן, או על ידי שימוש ברכיבי הערכת כללים שמופעלים ומגודרים באופן מקומי, ומבצעים הערכה של כללים והתראות מול מאגר הנתונים הגלובלי של Monarch, ומעבירים התראות שהופעלו אל Prometheus AlertManager.
  • אחסון הנתונים מתבצע על ידי Monarch, שמאחסן את כל נתוני Prometheus למשך 24 חודשים ללא עלות נוספת.

‫Grafana מתחבר למאגר הנתונים הגלובלי של Monarch במקום להתחבר לשרתי Prometheus נפרדים. אם הגדרתם שירות מנוהל ל-Prometheus collectors בכל ה-Deployments (פריסות), מופע Grafana יחיד יציג לכם תצוגה מאוחדת של כל המדדים בכל העננים.

איסוף נתונים

אפשר להשתמש בשירות מנוהל ל-Prometheus באחד מארבעה מצבים: עם איסוף נתונים מנוהל, עם איסוף נתונים בפריסה עצמית, עם OpenTelemetry Collector או עם סוכן תפעול.

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

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

אפשר להשתמש ב-OpenTelemetry Collector כדי לבצע scraping של Prometheus exporters ולשלוח נתונים לשירות מנוהל ל-Prometheus. ‫OpenTelemetry תומך באסטרטגיה של סוכן יחיד לכל האותות, שבה אפשר להשתמש במאסף אחד למדדים (כולל מדדי Prometheus), ליומנים ולעקבות בכל סביבה.

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

אם יש לכם שירות Cloud Run שכותב מדדי Prometheus או מדדי OTLP, אתם יכולים להשתמש בקובץ עזר ובשירות מנוהל ל-Prometheus כדי לשלוח את המדדים ל-Cloud Monitoring.

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

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

  • אוסף מנוהל:

    • הגישה המומלצת של Google לכל סביבות Kubernetes.
    • הפריסה מתבצעת באמצעות ממשק המשתמש של GKE, ה-CLI של gcloud, ה-CLI של kubectl או Terraform.
    • התפעול של Prometheus – יצירת הגדרות גירוד, שינוי קנה מידה של ההטמעה, הגדרת כללים לנתונים הנכונים וכו' – מתבצע באופן מלא על ידי Kubernetes operator.
    • הגדרת הגירוד והכללים מתבצעת באמצעות משאבים מותאמים אישית (CR) קלי משקל.
    • מתאים למי שרוצה חוויה מנוהלת באופן מלא, בלי התערבות מצד המשתמש.
    • העברה אינטואיטיבית מהגדרות של prometheus-operator.
    • תמיכה ברוב תרחישי השימוש העדכניים ב-Prometheus.
    • עזרה מלאה מצוות התמיכה הטכנית של Google Cloud .

  • איסוף שמוטמע באופן עצמאי:

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

  • ‫OpenTelemetry Collector:

    • כלי איסוף יחיד שיכול לאסוף מדדים (כולל מדדי Prometheus) מכל סביבה ולשלוח אותם לכל קצה עורפי תואם. אפשר להשתמש בו גם כדי לאסוף יומנים ועקבות ולשלוח אותם לכל קצה עורפי תואם, כולל Cloud Logging ו-Cloud Trace.
    • הפריסה מתבצעת בכל סביבת מחשוב או Kubernetes באופן ידני או באמצעות Terraform. אפשר להשתמש בו כדי לשלוח מדדים מסביבות בלי שמירת מצב, כמו Cloud Run.
    • הגירוד מוגדר באמצעות הגדרות שדומות להגדרות של Prometheus במקלט Prometheus של האוסף.
    • יש תמיכה בתבניות של איסוף מדדים מבוסס-דחיפה.
    • מטא-נתונים מוזרקים מכל ענן באמצעות מעבדי זיהוי משאבים.
    • אפשר להפעיל כללים והתראות באמצעות מדיניות התראות של Cloud Monitoring או באמצעות כלי הערכת הכללים העצמאי.
    • המודל הזה תומך הכי טוב בתהליכי עבודה חוצי-אותות ובתכונות כמו דוגמאות.
    • עזרה מוגבלת מהתמיכה הטכנית של Google Cloud .

  • סוכן התפעול:

    • הדרך הכי קלה לאסוף ולשלוח נתוני מדדים של Prometheus שמקורם בסביבות Compute Engine, כולל הפצות של Linux ו-Windows.
    • הפריסה מתבצעת באמצעות ה-CLI של gcloud, ממשק המשתמש של Compute Engine או Terraform.
    • הגירוד מוגדר באמצעות הגדרות דומות לאלה של Prometheus במקלט Prometheus של הסוכן, שמבוסס על OpenTelemetry.
    • אפשר להפעיל כללים והתראות באמצעות Cloud Monitoring או באמצעות כלי הערכת הכללים העצמאי.
    • הוא מגיע עם סוכני רישום אופציונליים ומדדי תהליכים.
    • עזרה מלאה מצוות התמיכה הטכנית של Google Cloud .

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

אם משתמשים בשירות המנוהל מחוץ ל-Google Kubernetes Engine או ל- Google Cloud, יכול להיות שיהיה צורך בהגדרות נוספות. אפשר לעיין במאמרים הפעלת איסוף מנוהל מחוץ ל-Google Kubernetes Engine, הפעלת איסוף בפריסה עצמית מחוץ ל-Google Cloud או הוספת מעבדים של OpenTelemetry.

הערכת שאילתות

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

אתם יכולים להשתמש ב-PromQL כדי לשלוח שאילתות על יותר מ-6,500 מדדים בחינם ב-Cloud Monitoring, גם בלי לשלוח נתונים לשירות מנוהל ל-Prometheus. אפשר גם להשתמש ב-PromQL כדי לשלוח שאילתות על מדדי Kubernetes בחינם, על מדדים מותאמים אישית ועל מדדים שמבוססים על יומנים.

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

מידע על שליחת שאילתות על מדדי Cloud Monitoring באמצעות PromQL זמין במאמר PromQL ב-Cloud Monitoring.

הערכת כללים והתראות

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

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

למידע על הערכת התראות באמצעות Cloud Monitoring, ראו התראות PromQL ב-Cloud Monitoring.

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

למידע על הערכת כללים באמצעות איסוף בפריסה עצמית, OpenTelemetry Collector ו-סוכן תפעול, אפשר לעיין במאמר בנושא הערכת כללים והתראות בפריסה עצמית.

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

אחסון הנתונים

כל הנתונים של שירות מנוהל ל-Prometheus נשמרים למשך 24 חודשים ללא עלות נוספת.

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

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

מידע נוסף זמין במאמר בנושא מכסות ומגבלות במסמכי התיעוד של Cloud Monitoring.

חיוב ומכסות

השירות המנוהל ל-Prometheus הוא Google Cloud מוצר, ולכן חלות עליו מכסות חיוב ושימוש.

חיוב

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

מכסות

השירות המנוהל ל-Prometheus חולק מכסות של קליטה וקריאה עם Cloud Monitoring. מכסת ברירת המחדל להעלאת נתונים היא 500 שאילתות לשנייה לכל פרויקט, עם עד 200 דגימות בכל קריאה, ששווה ל-100,000 דגימות לשנייה. מכסת ברירת המחדל לקריאה היא 100 שאילתות לשנייה לכל היקף מדדים.

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

תנאים והגבלות ותאימות

השירות המנוהל ל-Prometheus הוא חלק מ-Cloud Monitoring, ולכן הוא מקבל בירושה הסכמים ואישורים מסוימים מ-Cloud Monitoring, כולל (אבל לא רק):

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