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

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

הדיאגרמה הבאה ממחישה Deployment (פריסה) שמשתמש בכמה אשכולות בשני Google Cloud פרויקטים, ומשתמש בהערכת כללים ובהערכת התראות:

כדי להגדיר פריסה כמו זו שבתרשים ולהשתמש בה, חשוב לשים לב לנקודות הבאות:

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

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

  כדי לרכז את ניהול ההתראות בכמה אשכולות ב-AlertManager אחד, אפשר להשתמש במשאב של נקודות קצה ב-Kubernetes.

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

  הכלי העצמאי להערכת כללים מוגדר לשימוש ב-scoping_project_A, שמכיל את פרויקט 1 ואת פרויקט 2. כללים שמופעלים על scoping_project_A מופצים אוטומטית לפרויקטים 1 ו-2. צריך לתת לחשבון השירות הבסיסי את ההרשאות Monitoring Viewer עבור scoping_project_A.

  הכלי להערכת כללים מוגדר לשליחת התראות ל-Prometheus Alertmanager המקומי באמצעות השדה alertmanager_config של קובץ ההגדרות.

שימוש בכלי להערכת כללים שמוטמע באופן עצמאי עשוי להניב תוצאות לא צפויות, בהתאם לאופן שבו שומרים או צוברים את התוויות project_id, location, cluster ו-namespace בכללים:

• אם הכללים שלכם שומרים על התווית project_id (באמצעות סעיף by(project_id)), תוצאות הכללים נכתבות בחזרה ל-Monarch באמצעות הערך המקורי project_id של סדרת הזמן הבסיסית.

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

• אם הכללים לא שומרים על התווית project_id (כי לא נעשה שימוש בסעיף by(project_id)), התוצאות של הכלל נכתבות בחזרה ל-Monarch באמצעות הערך project_id של האשכול שבו פועל מעריך הכללים הגלובלי.

  בתרחיש הזה, אין צורך לבצע שינויים נוספים בחשבון השירות הבסיסי.

• אם הכללים שלכם שומרים את התווית location (באמצעות פסקה by(location)), תוצאות הכללים נכתבות בחזרה ל-Monarch באמצעות כל אזור Google Cloud מקורי שממנו נוצרה סדרת הזמן הבסיסית.

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

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