Grafana Alerting: למה התראות מגיעות מאוחר מדי
לרוב הגדרת Grafana Alerting מסתיימת בדיוק במקום שבו הכלל התחיל לחשב מטריקה: הסף הוגדר, הבדיקה רצה לפי לוח זמנים, ההתראה יוצאת לצ׳אט משותף. פורמלית הקונפיגורציה עובדת, אבל היא לא קשורה לתורנויות — והשינוי הראשון בהרכב המשמרת או בלוח הזמנים הופך אותה למקור רעש.
מכאן נכנסת לפעולה מכניקה מוכרת למשמרת תורנים. הסף תופס שיא עומס, לכלל אין השהיה בזמן, הקיבוץ לא מפריד בין סיבות — לצ׳אט מגיעה סדרה של הודעות זהות על שירות אחד. התראות שווא הופכות לרקע, את הערוץ מפסיקים לקרוא, והכשל האמיתי טובע ביניהן.
בעיה נפרדת היא התראות בלי נמען. לכלל אין בעלים של שירות מסוים, ולכן בלילה ההודעה יוצאת למקום שבו אף אחד לא תורן, ובבוקר מעבירים עליה מבט בלי לקרוא. השהיית ההתראה נמשכת שעות — בדיוק כמידת התפשטות התקלה.
התוצאה — אירוע שהוחמץ, שהצוות לומד עליו מהמשתמש ולא מהמערכת. עד לרגע הזה השחזור מתבצע בעיוורון: אין היסטוריית התראות ולא ברור מה הידרדר ראשון.
אנחנו מפרקים איך סוגרים את זה: איך לקשור כללים לתורנויות, לבנות ניתוב לפי שירותים ולוודא שההתראה הגיעה לאחראי ולא נשארה בפיד.
מה משתנה אחרי הגדרת ניתוב התראות
אחרי הפעלת ניתוב התראות ב-Grafana Alerting משתנה לא מספר האותות, אלא למי ומתי הם מגיעים. כלל שקודם נפל לערוץ משותף מנותב עכשיו לבעלים של השירות ומטופל לפי עדיפות.
האפקט המדיד הראשון — שיעור התראות השווא. קיבוץ אותות לפי שירות והתחשבות בקשרים ביניהם מסירים את המפולת: כשצומת לא זמין, הבדיקות שתלויות בו לא נשלחות כהודעות נפרדות. הרעש בתורנויות יורד מחצי מהזרם לאחוזים בודדים, והתורן מטפל בסיבה ולא בתוצאות שלה.
השני — הזמן עד להתראה. אות קריטי יוצא ישירות לערוץ של המשמרת, ולא למייל שבודקים פעם בחמש עשרה דקות. הנתיב הטיפוסי מתקלה ועד האחראי מצטמצם לדקה עד שלוש, ואם האות לא אושר, הוא מועבר לבא בתור בשרשרת — בלי שיחות ידניות "מי זמין".
השלישי — סוג הכשלים שנסוג. מדובר בהידרדרויות "שקטות", כשהשירות עונה אבל לאט או עם שגיאות בחלק מהבקשות. בדיקות לפי סימפטומים — זמינות, שיעור שגיאות, השהיית תגובה — פועלות לפני שהלקוח כותב על הבעיה.
הרביעי — עומס צפוי על התורנים. האותות מופרדים לפי קריטיות: מה שלא דורש התערבות מיידית עובר לשעות העבודה, והדחוף מעיר. במשמרת מגיעים כמה מקרים מנותחים במקום עשרות, והיסטוריית ההתראות והאישורים נשמרת לניתוח אחרי האירוע.
אפשרויות ניתוב התראות והמגבלות שלהן
כללים במקור פועלים הכי מהר וממשיכים לעבוד גם אם קו מרכזי לא זמין. המחיר לכך — התפשטות הקונפיגורציה: ספים זהים נערכים בצוותים שונים, אין רשימת נמענים אחידה, והיסטוריית ההתראות מפוזרת בין כמה מאגרים.
כללים מרכזיים מרכזים את הערכת התנאים, ניתוב לפי תגים וחלונות שקט בנקודה אחת. הסרת כפילויות וקיבוץ מתחילים לעבוד על כל המערכת, אבל מופיעה נקודת כשל משותפת ותלות קשיחה בקישוריות בין מקור המטריקות למרכז.
היברידי מחלק את הכללים לפי קריטיות: מה שדורש תגובה מיידית של התורן חי במרכז, ומטריקות של סביבות פיתוח ושירותים פנימיים נשארות במקור.
מה מגביל כל אפשרות
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כללים במקור | מעט צוותים, מינימום תלויות, דרישות קשיחות להשהיית פעולה | ספים משוכפלים, אין הסרת כפילויות משותפת, החלפת נמען — עריכה של כל מקור |
| מרכז התראות יחיד | הרבה צוותים ושירותים משותפים, נדרש ניתוב אחיד וניתוח אירועים | נקודת כשל משותפת, רגישות לקישוריות, דורש תגים מתואמים בכל המקורות |
| תוכנית היברידית | קריטיות שונה בין קווים, יש סימון בשל של שירותים וסביבות | שני מקומות עריכה, נדרשים נוהל ובקרה, אחרת ההתראות משוכפלות ומרעישות |
הבחירה נקבעת לפי הסימון: אם תגי השירותים והסביבות מוגדרים באופן אחיד, הניתוב לפיהם עובר למרכז בלי לשכתב כללים. כשהסימון לא אחיד, המרכז משלים בכללים במקור — אחרת חלק מההתראות לא מגיע לתורן, והכשל צף רק מהמשתמשים.
איך אנחנו מטמיעים התראות: שלבי עבודת הנדסה
לפני הגדרת הכללים אנחנו בונים מפת ניטור: אילו מקורות מספקים מטריקות ולוגים, אילו בדיקות זמינות כבר קיימות, מה נחשב לתקלה ומי באותו רגע בתורנות. בלי זה ההתראות הופכות לרעש שהתורן מפסיק לקרוא.
- ביקורת מקורות. עורכים מלאי של מטריקות, לוגים ובדיקות חיצוניות, מסמנים פערים וכפילויות: אותה תקלה לא צריכה להגיע משלושה מקומות בו-זמנית.
- תרשים נתיבים ואסקלציה. מפרקים אירועים לקבוצות ולנמענים, מגדירים קיבוץ, דיכוי כפילויות, חלונות שתיקה בזמן עבודות וסדר העברת תורנות.
- הגדרת ערוצים. מחברים נקודות קשר — צ׳אט, מייל, שיחה, פניות בטרקר, — בודקים הרשאות, מגבלות ושההודעה מכילה הקשר: מה נשבר, איפה וממתי.
- כללים וספים. מנסחים תנאים לפי סטייה מהנורמה, ולא לפי קפיצה בודדת, ומגדירים השהיית פעולה כדי שקפיצה קצרה לא תקרא לתורן בלילה.
- בדיקה באמצעות הפעלה. שוברים שירות בסביבת בדיקה: מודדים זמן מהאירוע ועד ההתראה, בודקים אם היא הגיעה לאדם הנכון, וחוזרים על ההרצה אחרי תיקונים.
- מסירה לתפעול. כללי Grafana Alerting ונתיבים נשמרים במאגר כקונפיגורציה, מצרפים תרשים אסקלציה והוראה לתורן, ומנתחים התראות שווא של השבועות הראשונים.
פעם ברבעון מעיינים מחדש בספים לפי סטטיסטיקת ההתראות — כללים חיים יחד עם התשתית, ולא נשארים במצב "הגדרנו פעם אחת".
תרשימים, מדיניות אסקלציה ונוהלים ביציאה
Grafana Alerting היא קונפיגורציה שצריך לנהל בגרסאות ולהעביר יחד עם האחריות. אם כללים ונתיבים נוצרו בקליקים בממשק ולא נשמרו בשום מקום, אזי בהחלפת תורן או בחיבור שירות חדש משחזרים את ההגדרות מהזיכרון. לכן אנחנו מוסרים לא רק התראות עובדות, אלא גם ערכת חפצים שלפיה הצוות ממשיך לעבוד בלעדינו.
- קונפיגורציות של כללים ונתיבים כקבצים נפרדים: החלה דרך אוטומציה, היסטוריית שינויים והחזרת כלל למצבו הקודם.
- תרשים נתיבים: אילו קבוצות נמענים קיימות, איזו קריטיות לאן עוברת, היכן נמצאת אגרגציה ודיכוי כפילויות.
- מטריצת הרשאות ומדיניות: מי עורך כללים, מי רק מאשר התראות, אילו הרשאות יש לחשבונות שירות.
- תפקידי תורנים ונוהל תורנות: סדר תורנויות, זמן תגובה לפי רמות קריטיות, סדר העברת משמרת.
- תרשים אסקלציה: אחרי כמה דקות נכנס הרמה השנייה ולמי עובר האות אם התורן הראשון לא ענה.
- הוראות עריכה: איך מוסיפים שירות, משנים סף, בודקים שההתראה הגיעה לנמען.
- תיעוד התראות: רשימת כללים פעילים עם ייעוד, בעלים ומקור מטריקה.
הערכה נשארת אצלכם במאגר ושורדת גם החלפת תורנים וגם החלפת ספק חיצוני.
מקרה בוחן: איך צמצמנו את זרם התראות השווא
לפנינו היה תרחיש טיפוסי: כמה עשרות שירותים, התראות ב-Grafana מוגדרות "על הכול", והתורן קיבל זרם הודעות שבו האותות השימושיים היו מיעוט. המהנדסים בהדרגה הפסיקו להגיב להתראות בודדות — האמון בניטור ירד מהר יותר משצמחה התשתית. פירקנו אילו כללים פועלים בתדירות הגבוהה ביותר ולמה.
מה היה לפני ההטמעה
התורן קיבל יותר מ-500 הודעות ביממה, מהן תקלות מאושרות — לא יותר מ-15%. את השאר נתנו קפיצות קצרות, רעש מתחזוקה מתוכננת וכפילויות לאותה בעיה ממקורות שונים. זמן התגובה הממוצע לאירוע אמיתי הגיע עד 40 דקות: האות אבד בזרם המשותף, וחלק מהכשלים צף רק מתלונות משתמשים.
מה שינינו ומה נהיה
הפרדנו כללים לפי קריטיות וקיבצנו התראות לפי שירות וסוג סיבה — בעיה אחת נותנת עכשיו התראה אחת. הוספנו תנאי משך, כדי שקפיצות קצרות לא יעירו את התורן, וניתוב: קריטי עובר למשמרת התורנים, אזהרות — לצ׳אט העבודה. דיכוי אותות תלויים הסיר את מפולת ההודעות בנפילת צומת אחד.
אחרי חודש הזרם ירד ל-30-40 הודעות ביממה, שיעור התקלות המאושרות עלה ל-80%, וזמן התגובה הצטמצם ל-5-7 דקות. תקלות שהוחמצו ברבעון — אפס. הכללים והנתיבים נמצאים במאגר: שינויים עוברים ביקורת ומוחזרים כמו קוד.
במה ניתוב שונה מדיכוי התראות?
ניתוב עונה רק על השאלה "מי יקבל את ההתראה". הכלל משווה תגי התראה לעץ נמענים ומוסר הודעה לצוות מסוים — לתורן הפלטפורמה, לבעלים של השירות. פספוס בתג נראה מיד: אם אף נתיב מוכל לא התאים, פועל נמען ברירת המחדל.
קיבוץ ודיכוי פותרים את המשימה ההפוכה — כמה התראות בכלל יגיעו. קיבוץ מדביק התראות עם מערכת תגים משותפת להודעה אחת: נפילת צומת מגיעה ככרטיס אחד עם רשימת אובייקטים, ולא כארבעים שורות. חלון דיכוי משתיק התראות שחופפות בתגים לפרק זמן מוגדר — בזמן עבודות או אירוע רועש ידוע.
שקט לפי לוח זמנים מוגדר מראש ביומן ומכסה חלונות נוהל שגרתיים, ולא מופעל ידנית ברגע האירוע. התורן לא תלוי בשאלה אם מישהו יזכור להשתיק את ההתראות בלילה.
אסור לערבב מנגנונים בכלל אחד: הנתיב מחושב ברגע ההתראה לפי התגים הנוכחיים, והדיכוי — לפי יומן או ידנית. אם תנאי "לשתוק" נכתב לתוך הנתיב, הוספת תג חדש שוברת גם את הנמען וגם את הדיכוי — ההתראה עוברת למקום הלא נכון או נעלמת לגמרי. את ההיעלמות אף אחד לא חוקר, כי עליה לא יודעים.
התרשים העובד — בשכבות: ניתוב תמיד קובע את הנמען, קיבוץ מפחית נפח, שקט וחלונות דיכוי מונחים מעל עם תוקף מפורש ואחראי. אחרי האירוע רואים לאן עברה ההתראה ולמה חלק הושתק.
ספקות טכניים נפוצים לפני הטמעה
הספקות של מהנדסים לפני העברה הם בדרך כלל אותם ספקות: מה יקרה להתראות הישנות, איך המערכת תתנהג כערוץ ההתראות לא זמין והאם תורנים יתחילו לקבל כפילויות. להלן תשובות קצרות לכל אחד.
מה לעשות עם כללים שהוגדרו בפאנל הקודם?
כללים וספים מומרים לפורמט החדש, סימון לפי תיקיות וקבוצות נשמר — ההעברה מתבצעת בלי לשכתב תנאים ידנית. לפני המעבר שני הקווים עובדים במקביל: משווים התראות ורק אחר כך מסירים את הכפילות.
מה יקרה אם ערוץ ההתראות לא זמין?
האירוע לא הולך לאיבוד: הוא נשאר בתור, חוזר לפי פרק הזמן שהוגדר, ובהתראה מוצג סימן "לא נמסר". אם הערוץ שותק יותר מהסף, התורן מקבל אות בנתיב גיבוי — על התקלה לומדים לא מתוך השקט בצ׳אט.
האם יתחילו כפילויות ממקורות שונים?
אירועים של אותו מקרה מקובצים להודעה אחת עם רשימת הצמתים שנפגעו, ולכן כמה התראות לא הופכות לזרם. כל עוד האירוע פתוח, חזרות לפי אותו כלל לא נשלחות, ובסגירה מגיעה תמצית.
איך מגדירים ספים שונים למשמרת תורנים?
ספים מוציאים לכללים נפרדים עם תג משמרת, והניתוב בוחר נמען לפי התג הזה. ביום ההתראות מגיעות לפי סף רך, בלילה — רק לפי קריטי, כדי לא להעיר אנשים על כל קפיצה.
Grafana Alerting בתשתית שלכם: איך להתחיל
כדי לחזור עם הערכה, ולא עם ניסוחים כלליים, צריך חתך של המצב הנוכחי: איך Grafana Alerting עובד אצלכם עכשיו ואיפה ההתראות הולכות לאיבוד. מספיק ייצוא של כללים, רשימת מקורות נתונים ותיאור נתיבים — את השאר נדייק בניתוח התרשים יחד עם המהנדס שלכם.
הניתוח אורך פגישה אחת. דנים במשימת ההתראות באופן ענייני: אילו כשלים חייבים להעיר את התורן בלילה, אילו ממתינים ליום עבודה, איפה עכשיו כפילויות והתראות שווא. ביציאה — הרכב העבודה להטמעה עם סדר שלבים והערכה שאפשר להגן עליה בפני ההנהלה.
מה לשלוח להערכה מהירה:
- ייצוא של כללי התראות — קבצי קונפיגורציה או ייצוא מהממשק, איך שנוח יותר;
- רשימת מקורות נתונים בחלוקה לפי צוותים וסביבות;
- נקודות התראה ומדיניות ניתוב: לאן ובאיזו צורה נשלחות הודעות;
- השתקות קבועות וחלונות שקט — לרוב דווקא הם מסבירים למה ההתראות שותקות;
- כמה הודעות טיפוסיות ביממה, כדי להעריך את נפח הרעש;
- מגבלות: היכן פרוסה ההתקנה, אילו הרשאות ניתנות, דרישות אבטחה;
- הרכב תורנים וכללי אסקלציה, אם הם כבר מתוארים.
ההכנה להטמעה — זה חצי שעה שלכם לאיסוף הייצואים והפגישה שלנו. אנחנו לא מבטיחים "מפתח ביד ביום": קודם ניתוח, אחר כך תוכנית, אחר כך עבודות. תארו את המשימה — נחזור עם הערכה ותוכנית.