דשבורדים של Grafana: למה יש מדדים אבל אין תמונה
המדדים נאספים, סוכנים כותבים לאחסון, אבל על השאלה "מה קרה ברגע התקלה" הצוות עדיין עונה ידנית. דשבורדים של Grafana קיימים פורמלית — עשרות פאנלים, שנעשו למשימות שונות ובזמנים שונים.
אף אחד מהם לא מציג על מסך אחד את הקשר בין עומס, שגיאות והשהיה: התורן פותח חמישה לשוניות, משווה חותמות זמן בעיניים ומאבד את הדקות הראשונות של האירוע על משהו שאמור להיקרא במבט אחד.
כאב נפרד — התראות רועשות. הכללים נכתבו נקודתית לשירות מסוים, הספים נקבעו לפי העין ולא נבדקו מחדש לאחר שינויים בארכיטקטורה. ביממה מגיעים עשרות הפעלות, חלקם תוצאה של אירוע אחד, והכשל האמיתי טובע בזרם. ההרגל לא להסתכל על התראות נוצר מהר יותר מאשר מוצאת הסיבה.
ניתוח אירוע הופך לארכיאולוגיה: צריך להיזכר איזה פאנל אחראי על הצומת הרצוי, היכן נמצאת היסטוריית השינויים, למה הגרף מציג לא את מה שציפו.
כאשר הפאנלים מפוזרים, והמדדים נקראים בשמות שונים בצוותים שונים, נקודת תצפית אחידה לא נוצרת — הוויזואליזציה של התשתית חיה בראש של מהנדס אחד, ולא בכלי משותף.
אנחנו מתחילים מתיאור תרחישי ניתוח אמיתיים: מה התורן צריך לראות קודם, אילו מדדים עומדים זה לצד זה, לפי איזה סף התראה הגיונית. בהמשך — איך מזה נבנית נקודת תצפית אחידה ולמה היא משנה את מחיר הטעות.
מה משתנה לאחר הטמעת פאנלים אחידים לניטור
מסכים מפוזרים מוחלפים בהיררכיה אחת: מצב כללי של הפלטפורמה, אחר כך שירות, אחר כך צומת או תלות מסוימת. תמונה אחידה של שירותים נבנית מאותם מדדים ב-Grafana, לכן אין יותר פערים בין גרפים של צוותים שונים, והשאלה "ואיך אצלך?" נעלמת מהתכתבות ברגע התקלה.
זמן איתור התקלה מצטמצם מעשרות דקות לכמה דקות: המסלול מאות "השירות מגיב לאט" ועד לצומת מסוים הוא שתי-שלוש ניווטים בפאנל, ולא סדרה של ניחושים ובדיקות ידניות. באירועים בדרגת חומרה בינונית זמן ההשבתה מסתכם בכ�רבע מהקודם, כי התורן לא מבזבז זמן על איסוף הקשר.
שיעור ההפעלות הכוזבות יורד: כלל נבנה לא על סף בודד, אלא על כמה אותות וחלון אישור. ההתראה מגיעה כשהסטייה נמשכת, ולא כשמדד הבהב על צומת אחד. העומס על התורנים פוחת — קריאות לילה נשארות רק עבור כשלים אמיתיים, לא עבור רעש.
הכיסוי בניטור גדל בלי גידול במספר המסכים: שירות חדש מתחבר לפי תבנית מוכנה ויורש כללים, סימון וספים. שיעור השירותים תחת ניטור מגיע לכמעט מלא, ואזורים עיוורים מרכיבים שהושקו לאחרונה נסגרים ביום החיבור, ולא אחרי חודשים.
לא הדיווח משתנה, אלא התנהגות הצוות: התורן פועל לפי נתונים, לא לפי אינטואיציה, ההנהלה רואה ירידה בביצועים לפני המשתמשים. מכאן גם התוצאה המדידה — פחות דקות השבתה, פחות התראות שווא, יותר שירותים תחת ניטור.
דשבורדים של Grafana: השוואת גישות לוויזואליזציה
הבחירה בגישה לוויזואליזציה תלויה בכמה סביבות צריך לכסות, באיזו תדירות פאנלים משתנים והאם העמיתים מוכנים להחזיק אותם במאגר לצד תצורת השירותים. נבחן ארבע אפשרויות, שביניהן באמת בוחרים בהתחלה — עם נקודות התורפה שלהן, ולא רק עם היתרונות.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| ערכות פאנלים מוכנות | צריך סקירה של אשכול, צמתים ומסדי נתונים כבר ביום הראשון, מדדים טיפוסיים | נאספו עבור סטאק אחר: חלק מהשאילתות לא מחזירות נתונים, מדדים נקראים אחרת |
| בנייה עצמית מפאנלים טיפוסיים | סט מדדים וספים משל עצמך, צריך שליטה בכל גרף | לוקח יותר זמן בהתחלה: נדרש ניתוח מדדים והסכמה על שמות |
| פאנלים כקוד | כמה סביבות, צריך שחזוריות וסקירת שינויים | עריכות דרך הממשק לא נשמרות ואובדות בהטמעה הבאה |
| הגדרה ידנית של פאנלים | משימות חד-פעמיות: ניתוח אירוע, בדיקת השערה, הדגמה | לא מתרחב — אין גרסאות, אף אחד לא יודע איזה פאנל מעודכן |
בפועל משלבים גישות: ערכה מוכנה מזרזת את היום הראשון ונותנת נקודת ציון, בהמשך מעבירים גרפים נחוצים לקבצים ומתקנים דרך סקירה. אז הוויזואליזציה מפסיקה להיות חפץ אישי של מהנדס אחד — היא שורדת חילופי צוות, נפרסת על קונטור חדש על ידי צוות אחד ולא מתפצלת בין סביבות. תארו את המשימה — נחזור עם הערכה ותוכנית.
שלבי הטמעה: מביקורת מדדים ועד מסירה לתורנים
פאנלים חסרי תועלת אם אין מה לאסוף או שהנתונים סותרים. לכן אל Grafana אנחנו מגיעים עם סכמת איסוף פתורה — הולכים מהמקורות לאנשים, ולא להפך. סדר העבודות שלהלן הופך לתוכנית קבלה.
- ביקורת מקורות מדדים. עוברים על קונטורים: אילו אוספים כבר מחזירים נתונים, היכן יש מדדים אבל לא נאספים, אילו משכפלים זה את זה. התוצאה — רשימת אותות עם הערכת מהימנות ותדירות דגימה.
- סכמת איסוף נתונים. קובעים מרווחי דגימה, אחסון והתנהגות בעת ניתוק הקשר עם הצומת. תוויות מובאות למילון אחיד — אחרת הפאנל נשבר משינוי שם מארח.
- הגדרת פאנלים. אוספים 3-4 מסכים לפי תפקידים: סקירת שירותים, משאבים, מדדים עסקיים, מסך תורן. אגרגציה וספים נבחרים כך שהגרף יענה על השאלה "מה השתנה".
- בדיקה באירוע. מכבים צומת, מציפים תור, מדמים ירידה בביצועים של שירות חיצוני. בודקים תוך כמה דקות הסטייה נהיית מורגשת והאם אותות חשובים לא טובעים ברעש.
- כללי התראות. קושרים גרפים לספים ולמסלולי תורנים, מסירים כפילויות — תקלה אחת לא צריכה לייצר מפולת התראות.
- מסירה למשמרת תורנית. רושמים הוראות: מה לראות קודם, אילו ערכים להיחשב לנורמה, לאן ללכת בעת סטייה. השלב נסגר כשהתורן מסביר את הגרף בעצמו.
לאחר המסירה נשארים בעלים לכל מסך ותקנון עדכון — בלעדיהם מופיעים גרפים שאף אחד לא קורא.
מה נשאר אצלכם: פאנלים, הרשאות גישה ותקנונים
מערכת ניטור מוכנה — זה לא רק גרפים על המסך, אלא סט חפצים שנשאר בקונטור שלכם. דשבורדים של Grafana, הרשאות, תקנונים ותיעוד נמסרים יחד עם המערכת העובדת — כדי שהצוות יוכל לפתח אותה בעצמו, בלעדינו וללא סיכון לשבור התראות שכבר הוגדרו.
- תיאור פאנלים. לכל דשבורד — ייעוד, בעלים, מקורות מדדים, משתני תבנית לבחירת סביבה, שירות ותקופה; ספי צבעים אומרים אותו דבר בכל המדורים.
- פאנלים כקוד. מודלים של דשבורדים מונחים במאגר ונפרסים אוטומטית: עריכה דרך הממשק לא נשארת העותק היחיד, היסטוריית שינויים וחזרה לאחור נשמרות.
- מדיניות גישה. תפקידי צפייה, עריכה וניהול, קישור לקבוצות ספרייה ולכניסה אחידה, חשבונות נפרדים לאיסוף מדדים ולשליחת התראות.
- תפקידי תורנים. מי ומגיב לאילו אותות, סדר הסלמה, פאנלים תורניים וחלונות שקט בזמן עבודות מתוכננות.
- תיעוד ניטור. מפת מדדים ומקורותיהם, רשימת התראות עם ספים, הוראות קצרות "מה לראות קודם" בעת הפעלה.
- תקנון עדכון פאנלים. כיצד לחבר שירותים חדשים, מי מאשר שינויים, כיצד לבדוק פאנל לפני העלאה לקונטור הכללי ומתי נבדקים הספים מחדש.
- הפרדה לצוותים חיצוניים. גישת קבלנים ומחלקות סמוכות — רק לדשבורדים הנחוצים להם, עם תקופה מוגבלת.
סט כזה מסיר תלות במהנדס מסוים: תורן חדש מתמצא לפי התיעוד, ושינויים עוברים בדיקה, ולא נערכים ישירות בקונטור הפעיל.
מקרה בוחן: איתור תקלה ארך שעות, עכשיו דקות
באחד הפרויקטים מהנדס תורן בילה שלוש-ארבע שעות באיתור סיבת התקלה. המדדים היו על ארבעה פאנלים שונים: עומס על צמתים, תורים, שגיאות בכניסה, השהיות בתגובות. את הקשרים ביניהם המהנדס בנה ידנית, תוך השוואת סדרות זמן בעיניים — וטעה, כי הגרפים חיו בקני מידה שונים.
אספנו דשבורד אחיד ב-Grafana סביב מסלול המשתמש: בקשה עוברת ממאזן העומסים לשירות, משם — לתור ולכתיבה, וכל פאנל מציג את הקטע שלו על ציר זמן משותף. התראות קשרנו לסטייה מקו בסיס בשבועות האחרונים, ולא לספים סטטיים: קפיצה בעומס נמוך וגדילה איטית בעומס גבוה נראים באותה מידה טוב.
מה השתנה במדדים
זמן האיתור הממוצע הצטמצם משלוש שעות ל-12–15 דקות. הסיבה לשבעה מתוך עשרה אירועים נראית בפאנל הראשון, השאר נסגרים במעבר אחד לפירוט לפי תווית שירות. ניתוחי לילה הפסיקו לדרוש העלאת מהנדס שני.
בנפרד נעלם סוג הכשל שחזר על עצמו הכי הרבה — הצפת תור הכתיבה תחת עומס שיא. בעבר נודע על כך מתלונות משתמשים, כעת ההתראה מגיעה לפני הירידה בביצועים, והתורן מספיק להעלות מטפלים נוספים עד שההאטה נהיית מורגשת.
במה פאנלים של מדדים שונים מיומנים וטרייסינג?
שלושה סוגי נתוני ניטור עונים על שאלות שונות. מדדים — מספרים מצטברים עם תוויות לאורך מרווח: זולים באחסון, מראים "מה קורה" ומתי להעיר את התורן. יומנים — אירועים בודדים עם הקשר מלא, הם עונים על "למה", אבל מתייקרים באופן ליניארי עם מספר השירותים. טרייסינג מתאר את מסלול הבקשה הבודדת דרך כל השירותים ומראה היכן עבר הזמן.
| סוג נתונים | על איזו שאלה עונה | היכן אין לו תחליף | מגבלות |
|---|---|---|---|
| מדדים | מה ובאיזו מידה השתנה | ספים, התראות, דינמיקה לאורך חודשים | מיצוע מסתיר קפיצות נדירות, קרדינליות תוויות מנפחת את האחסון |
| יומנים | מה בדיוק קרה | ניתוח שגיאה, ביקורת, פרטי בקשה | הנפח גדל עם התעבורה, חיפוש במערך איטי |
| טרייסינג | היכן עבר הזמן | שרשראות איטיות משירותים רבים | נדרשת התאמת שירותים, לכיסוי — דגימה |
גבולות הפאנלים של מדדים חשוב להבין מראש: קפיצה בגרף אומרת שמשהו נשבר, אבל לא תמנה בקשה מסוימת.
הממוצע לאורך מרווח מסתיר כשלים קצרים, ותוויות חדשות עם קרדינליות גבוהה מנפחות את האחסון מהר יותר מאשר גדל התעבורה — לכן בחירת הכלי מתחילה משאלה, ולא מהרצון לשים את כל שלושת סוגי הנתונים בכל מקום.
הם עובדים יחד: התראה לפי מדד מצמצמת את החלון, יומנים נותנים הקשר, טרייסינג מוביל לקריאה מסוימת. ב-Grafana פאנל מדדים נקשר ליומנים ולטרייסינג לפי זמן ותוויות — המסלול מ"השירות מתדרדר" ועד לקטע האשם אורך דקות.
ספקות טכניים שכדאי להסיר לפני ההתחלה
פאנלים וכללי התראות — לא חפץ חד-פעמי, אלא חלק מהתשתית עם בעלים משלו ותקנון עריכות. להלן ארבע שאלות, שאת רובן אנחנו מסירים לפני ההתחלה.
יש לנו כבר פאנלים משלנו — האם נצטרך לצייר אותם מחדש?
מעבירים. הפאנלים מיוצאים ל-JSON ונשמרים במאגר יחד עם שאילתות, ספים ומשתנים: את הלוגיקה שומרים, כפילויות וגרפים מתים מנקים. מאפס כותבים מחדש רק פאנלים שבהם השאילתה מחשבת מדד לא נכון.
איך מפרידים בין קונטור בדיקות לקונטור מבצעי?
התבנית אחת, ההבדלים — בערכי המשתנים: מקור הנתונים והסביבה נבחרים בראש הפאנל. עותקים נפרדים לקונטור בדיקות ולקונטור מבצעי מתפצלים בנתונים כבר אחרי חודש, לכן אנחנו מגדירים מחדש פרמטרים, ולא מבנה.
תיתנו גישה לצוותים חיצוניים?
לפי הרשאות מינימליות: קריאה — לצוותים סמוכים, עריכה — לבעלי הפאנלים. קבלן חיצוני מקבל גישה לתיקייה נפרדת ולפרק זמן מוגבל, בלי זכות לשנות את התבנית הכללית.
מה יהיה עם הפאנלים אחרי ההטמעה?
הם נשארים במאגר, עריכות עוברות דרך סקירה, לכל דשבורד יש בעלים ואחראי על ההתראה. אנחנו מוסרים תקנון עדכון וסדר ניתוח הפעלות שווא, כדי שאחרי רבעון הוויזואליזציה לא תתפצל מהמצב האמיתי של המערכות.
נדון במשימה שלכם: מה לשלוח להערכה
כדי לחזור עם הערכת משימת ניטור ותוכנית עבודה, די לנו בנתוני מקור — אין צורך להכין מפרט טכני מלא ומצגות. ככל שהנתונים הראשוניים מדויקים יותר, כך יש פחות הנחות בתוכנית והמועדים הוגנים יותר.
- רשימת אובייקטים לניטור ועדיפויות: אילו שירותים, צמתים, מסדי נתונים ותורים צריכים להיראות בדשבורדים של Grafana ראשונים, ומה עובר לגל שני.
- גישות קריאה בלבד: למקור המדדים, למערכת ההתראות ולמלאי שבו מפורטים מארחים וסביבות.
- מצב נוכחי: ייצוא או צילומי מסך של פאנלים קיימים, רשימת כללי התראה ומה שעליו מתלוננת משמרת התורנים.
- הסכמי תורנות: רמות זמינות מטרה, חלונות תגובה, מי ובאיזה ערוץ מקבל התראה בלילה.
- הרכב התיעוד שאתם צריכים: מפת פאנלים ומדדים, תיאור כל כלל התראה וסף, הוראה למשמרת תורנית לגבי פעולות ראשונות.
- מגבלות הקונטור: רשת סגורה, דרישות אבטחה, תקנון שינויים — זה משפיע על אופן האספקה וסדר העבודות.
זה יספיק כדי לפרוס את העבודה לשלבים, למנות את הרכב התיעוד ואת סדר המסירה למשמרת תורנית. תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה.