ההתראות עוזרות לכם לקבל מידע על התקינות והביצועים של הפריסות שלכם עם בידוד פיזי. הם מספקים התראות בזמן אמת כשמתקיימים תנאים מסוימים, ומאפשרים לכם:
- טיפול יזום בבעיות: זיהוי בעיות והגבה אליהן לפני שהן משפיעות על המשתמשים או על הפעילות העסקית.
- הפחתת זמן ההשבתה: צמצום השיבושים בשירות באמצעות נקיטת פעולות מתקנות במהירות.
- שמירה על רמות שירות: מוודאים שהאפליקציות עומדות ביעדי הביצועים והזמינות.
- קבלת תובנות תפעוליות: זיהוי מגמות ודפוסים בסביבה שלכם כדי לבצע אופטימיזציה של ניצול המשאבים והביצועים.
בדף הזה מופיעה סקירה כללית על יצירה וניהול של התראות בסביבות מבודדות (air-gapped) של Google Distributed Cloud (GDC). המאמר מסביר איך להשתמש בנתוני ניטור כדי לזהות באופן יזום אירועים קריטיים באפליקציות ובאינפראסטרוקטורה שלכם ולטפל בהם.
סוגים של כללי מדיניות התראות
כללי מדיניות להתראות שמבוססים על מדדים עוקבים אחרי נתוני ניטור ושולחים התראות לאנשים ספציפיים כשמשאב עומד בתנאי שהוגדר מראש. לדוגמה, מדיניות התראות שעוקבת אחרי ניצול המעבד של מכונה וירטואלית עשויה לשלוח התראה כשאירוע מפעיל את המדיניות. לחלופין, מדיניות שמנטרת בדיקת זמינות עשויה לשלוח התראה לצוותים בכוננות ולצוותי פיתוח.
מצד שני, כדי לעקוב אחרי אירועים חוזרים ביומנים לאורך זמן, אפשר להשתמש במדדים מבוססי-יומן כדי ליצור מדיניות התראות. מדדים מבוססי-יומנים יוצרים נתונים מספריים מנתוני רישום ביומן. מדדים מבוססי-יומן מתאימים אם אתם רוצים לבצע אחת מהפעולות הבאות:
- סופרים את המקרים שבהם ההודעה מופיעה ביומנים, למשל אזהרה או שגיאה. לקבל התראה כשמספר האירועים חוצה סף מסוים.
- כדאי לעקוב אחרי מגמות בנתונים, כמו ערכי זמן האחזור ביומנים. לקבל התראה אם הערכים משתנים באופן לא מקובל.
- אפשר ליצור תרשימים כדי להציג את הנתונים המספריים שחולצו מהיומנים.
ב-GDC, התראות יכולות ליצור דפים וכרטיסים לשגיאות קריטיות. דפים דורשים טיפול מיידי מצד נציג, ואילו כרטיסים פחות דחופים.
רכיבים מרכזיים
שירות ההתראות של GDC משתמש ברכיבים הבאים:
- Prometheus: מערכת ניטור בקוד פתוח שנמצאת בשימוש נרחב לאיסוף ולאחסון של מדדים. הוא מספק שפת שאילתות עוצמתית (PromQL) להגדרת כללי התראה.
- פלטפורמת מעקב: שירות מעקב מנוהל שאוסף מדדים ממקורות שונים, כולל Prometheus. הוא כולל תכונות מתקדמות כמו לוחות בקרה של Grafana, מדדים מותאמים אישית והתראות.
- Alertmanager: רכיב שאחראי לקבלת התראות, לעיבוד שלהן ולהפניה שלהן. הוא תומך בקיבוץ, בהשתקה ובמניעת התראות כדי להפחית רעשים ולשפר את היעילות.
תהליך עבודה של התראות
GDC מספק מסגרת התראות שמשתלבת עם מגוון כלי ניטור ושירותים. תהליך העבודה הרגיל כולל את השלבים הבאים:
- איסוף נתונים: אפשר להשתמש בכלים כמו Prometheus ו-Fluent Bit כדי לאסוף מדדים ויומנים מהאפליקציות, מהתשתית ומ-Kubernetes.
- מעקב: אחסון והצגה של הנתונים שנאספו במרכזי בקרה של Grafana.
- כללי התראות: הגדרת כללי התראות על סמך תנאים ספציפיים, כמו שימוש במעבד שחורג מסף מסוים או שגיאות באפליקציה שחורגות משיעור מסוים.
- Alertmanager: Alertmanager מקבל התראות שמופעלות על ידי הכללים המוגדרים ומטפל בהעברת התראות ובהשתקה שלהן.
- התראות: קבלת התראות בערוצים שונים, כמו אימייל, הודעות או ווּבְּהוּקים.
שיטות מומלצות
כשמגדירים התראות, מומלץ לפעול לפי השיטות המומלצות הבאות:
- הגדרת התראות ברורות ופרקטיות: חשוב לוודא שההתראות מספקות מידע ספציפי על הבעיה ומציעות פעולות מתאימות.
- הגדרת רמות חומרה מתאימות: סיווג ההתראות לפי ההשפעה והדחיפות שלהן כדי לתת עדיפות למאמצי התגובה.
- מניעת עייפות מהתראות: כדאי לכוונן את כללי ההתראות כדי למזער את מספר התוצאות החיוביות הכוזבות וההתראות המיותרות.
- בודקים את ההתראות באופן קבוע: מוודאים שההתראות מופעלות בצורה נכונה ושההודעות נשלחות כמצופה.
- תיעוד אסטרטגיית ההתראות: כדאי לתעד את כללי ההתראות, את ערוצי ההתראות ואת נהלי ההסלמה.