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

כדי להגדיר פריסה כמו זו שבתרשים ולהשתמש בה, חשוב לשים לב לנקודות הבאות:
הכלי להערכת כללים מנוהלים נפרס אוטומטית בכל אשכול שבו פועל איסוף מנוהל. ההגדרות של בודקי התאימות הן:
אפשר להשתמש במשאבי כללים כדי להפעיל כללים על נתונים במרחב שמות. צריך להחיל משאבי כללים בכל מרחב שמות שבו רוצים להפעיל את הכלל.
משתמשים במשאבי ClusterRules כדי להפעיל כללים על נתונים בכל האשכול. צריך להחיל משאבי ClusterRules פעם אחת לכל אשכול.
כל ההערכות של הכללים מתבצעות מול מאגר הנתונים הגלובלי, Monarch.
- משאבי הכללים מסננים באופן אוטומטי את הכללים לפי הפרויקט, המיקום, האשכול ומרחב השמות שבהם הם מותקנים.
- משאבי ClusterRules מסננים באופן אוטומטי כללים לפרויקט, למיקום ולאשכול שבהם הם מותקנים.
- כל התוצאות של הכללים נכתבות ב-Monarch אחרי ההערכה.
פריסה ידנית של מופע Prometheus AlertManager בכל אשכול. כדי להגדיר את המעריכים של הכללים המנוהלים, עורכים את מקור OperatorConfig כדי לשלוח את כללי ההתראה שהופעלו למופע המקומי של AlertManager. בדרך כלל, טיפול בשקט, באישור ובזרימות עבודה של ניהול אירועים מתבצע בכלי של צד שלישי, כמו PagerDuty.
כדי לרכז את ניהול ההתראות בכמה אשכולות ב-AlertManager אחד, אפשר להשתמש במשאב נקודות קצה של Kubernetes.
בתרשים שלמעלה מוצג גם המשאב האופציונלי GlobalRules. מומלץ להשתמש ב-GlobalRules במשורה, למשימות כמו חישוב של SLO גלובלי בפרויקטים או להערכה של כללים באשכולות בתוך פרויקט יחיד Google Cloud . מומלץ מאוד להשתמש ב-Rules וב-ClusterRules בכל הזדמנות. המשאבים האלה מספקים אמינות גבוהה יותר ומתאימים יותר למנגנוני פריסה נפוצים של Kubernetes ולמודלים של דיירות.
אם משתמשים במשאב GlobalRules, חשוב לשים לב לנקודות הבאות מהתרשים הקודם:
אשכול יחיד שפועל בתוך Google Cloud מוגדר כאשכול הגלובלי להערכת כללים עבור היקף המדדים בפרויקט. הכלי המנוהל הזה להערכת כללים מוגדר לשימוש ב-scoping_project_A, שמכיל את פרויקטים 1 ו-2. כללים שמופעלים אוטומטית על scoping_project_A מתפשטים לפרויקטים 1 ו-2.
צריך לתת לחשבון השירות הבסיסי את ההרשאות Monitoring Viewer עבור scoping_project_A. מידע נוסף על הגדרת השדות האלה זמין במאמר בנושא הערכה של כללים גלובליים וכללים בכמה פרויקטים.
כמו בכל האשכולות האחרים, בבודק הכללים הזה מוגדרים משאבי Rules ו-ClusterRules שבודקים כללים בהיקף של מרחב שמות או אשכול. הכללים האלה מסוננים אוטומטית לפרויקט המקומי – פרויקט 1 במקרה הזה. מכיוון ש-scoping_project_A מכיל את פרויקט 1, כללים וכללים שהוגדרו ב-ClusterRules מופעלים רק על נתונים מהפרויקט המקומי, כצפוי.
בנוסף, באשכול הזה יש משאבי GlobalRules שמבצעים כללים מול scoping_project_A. הסינון של GlobalRules לא מתבצע באופן אוטומטי, ולכן הן מופעלות בדיוק כמו שהן כתובות בכל הפרויקטים, המיקומים, האשכולות ומרחבי השמות ב-scoping_project_A.
כללי התראה שהופעלו יישלחו ל-AlertManager באירוח עצמי כמצופה.
השימוש ב-GlobalRules עלול להניב תוצאות לא צפויות, בהתאם לאופן שבו שומרים או צוברים את התוויות project_id, location, cluster ו-namespace בכללים:
אם הכלל GlobalRules שומר על התווית
project_id(באמצעות פסקהby(project_id)), תוצאות הכלל נכתבות בחזרה ל-Monarch באמצעות הערך המקוריproject_idשל סדרת הזמן הבסיסית.בתרחיש הזה, צריך לוודא שלחשבון השירות הבסיסי יש הרשאות Monitoring Metric Writer לכל פרויקט שנכלל בהיקף של scoping_project_A. אם מוסיפים פרויקט חדש למעקב ל-scoping_project_A, צריך גם להוסיף באופן ידני הרשאה חדשה לחשבון השירות.
אם כלל GlobalRules לא שומר על התווית
project_id(כי לא נעשה שימוש בסעיףby(project_id)), תוצאות הכלל נכתבות בחזרה ל-Monarch באמצעות הערךproject_idשל האשכול שבו פועל מעריך הכללים הגלובלי.בתרחיש הזה, אין צורך לבצע שינויים נוספים בחשבון השירות הבסיסי.
אם GlobalRules שומר על התווית
location(באמצעות פסקהby(location)), תוצאות הכלל נכתבות בחזרה ל-Monarch באמצעות כל אזור Google Cloud מקורי שממנו נוצרה סדרת הזמן הבסיסית.אם GlobalRules לא שומר את התווית
location, הנתונים נכתבים בחזרה למיקום של האשכול שבו פועל מעריך הכלל הגלובלי.
מומלץ מאוד לשמור את התוויות cluster ו-namespace בתוצאות של הערכת הכלל, אלא אם מטרת הכלל היא לצבור את התוויות האלה. אחרת, יכול להיות שביצועי השאילתות ירדו ותיתקלו במגבלות של עוצמת הקשר. לא מומלץ להסיר את שתי התוויות.