Grafana Mimir: מדוע ניטור מפוזר אינו מתרחב
כל עוד יש כמה צוותים, המטריקות מתפזרות בין מערכות נפרדות: לכל קבוצה סוכן איסוף משל עצמה, אחסון משל עצמה, וכללי התראות משלה. פורמלית, ניטור יש לכולם, אך ניטור מפוזר אינו מספק תמונה אחודה על המוצר, וניסיון לכנס אותה למקום אחד נתקל באי-תאימות בין המקורות.
הבעיה השנייה היא קיצור היסטוריית המטריקות. כדי להיכנס לדיסק, תקופת השמירה נחתכת לשבועות, וניתוח תקלה שאירעה לפני חודש וחצי מתחיל מ"הנתונים כבר אינם". הידרדרות איטית, שיא עונתי, דליפה הדרגתית של משאב — כל מה שנראה רק בחלון ארוך, אין עם מה להשוות.
בהמשך מתפצלים הדשבורדים. שמות תוויות שונים, מרווח דגימה שונה, דרכי צבירה משל עצמן — שני גרפים לאותה תלות מציגים מספרים שונים. חיפוש סיבת הכשל הופך להשוואה ידנית של אירועים לפי זמן בין כמה פאנלים ולשאלות לעמיתים אצל מי הנתונים נשמרו זמן רב יותר.
מאגר מטריקות אחוד פותר זאת מעצם המבנה: הנתונים מכל הצוותים זורמים לשכבה אחת, אורך ההיסטוריה נקבע לפי מדיניות שמירה ולא לפי גודל הדיסק של מכונה מסוימת, ובשאילתה אחת רואים את כל התמונה. Grafana Mimir — אחת הדרכים להרכיב מאגר כזה; נבחן כיצד זה נסגר.
מה משתנה לאחר העברת המטריקות למאגר אחוד
לפני המאגר האחוד המטריקות חיות בכמה בסיסי נתונים מקומיים: חלק מהצמתים כותבים לאחד, חלק לאחר, ולכל אחד כללי שמירה משל עצמו ועומק היסטוריה משלו.
כאשר בסיס נתונים כזה נופל, התורן רואה חור בגרפים ואינו יכול להבחין בין תקלה אמיתית לבין החמצת נתונים — הניתוח מתארך, משום שתחילה יש להבין מה בדיוק שותק.
נקודת איסוף אחודה סוגרת זאת: כל האתרים כותבים לאשכול משותף, ודה-דופליקציה לפי זוג "מקור + סדרה" מכווצת עותקים שנוצרים באיסוף מכמה רפליקות ובמעבר צמתים.
בפאנל נשארת סדרה אחת נכונה במקום אוסף של סדרות סותרות, ואת השאילתה משרת ממשק משותף של Grafana Mimir, ולא בסיס נתונים מקומי.
שמירה ארוכת טווח של ההיסטוריה מועברת לאחסון אובייקטים, ולכן ההשוואה "איך היה לפני רבעון" מפסיקה לדרוש ייצוא והצלבה ידנית. הרחבה אופקית נעשית בהוספת צמתי קליטה וקריאה — גידול במספר הסדרות אינו נתקל בדיסק של שרת אחד, ובלוקים ישנים פשוט עוברים לשכבה קרה.
משתנה גם סוג התקלות. אובדן צומת אינו מפיל את הקליטה: הרפליקות ממשיכות לכתוב, הקריאה עוברת למופעים חיים, והשחזור מסתכם בהחלפת צומת בתוך דקות, ולא בניתוח גיבוי לאורך שעות. עמידות הניטור בתקלות מפסיקה להיות פרויקט נפרד — היא מובנית בפריסת הרפליקות ונבדקת בכיבוי צומת שגרתי.
אפשרויות אחסון מטריקות ב-Grafana Mimir: השוואת גישות
Grafana Mimir מסתיר את הטופולוגיה מאחורי API שאילתות אחוד, ולכן ניתן לשנות את מצב האחסון בלי לכתוב מחדש פאנלי ניטור וכללי התראות. בפועל, הבחירה היא בין צומת איסוף בודד, מצב אשכול עם שכפול מטריקות, ותרשים היברידי שבו חלק מהזרימה נשאר מקומי וחלק עובר לאחסון ארוך טווח.
ההבדל מתבטא בשני מקומות: כמה צמתים יכולים להיכשל בלי אובדן נתונים וכיצד משתנות מגבלות ההרחבה עם גידול מספר המקורות.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| צומת איסוף בודד | מתאר קטן, עשרות מקורות, סטנד לבדיקת כללים | אין רזרבה לתקלות: עצירת הצומת מפסיקה את קליטת המטריקות, הרחבה אנכית בלבד |
| מצב אשכול עם שכפול | פרודקשן עם דרישת רציפות, מאות מקורות | יקר יותר בתחזוקה: תיאום מצב, בקרת שכפול וניטור נפרד של הדיסק |
| תרשים אחסון היברידי | מטריקות טריות נדרשות מקומית ובמהירות, ישנות — רק להיסטוריה | ניתוב שאילתות מורכב יותר ונוצר מפגש מתארים כנקודת כשל חדשה |
המעבר בין התרשימים אינו דורש שינוי באינסטרומנטציה: שליחת המטריקות נשארת כשהייתה, ההיסטוריה נקראת דרך API משותף, והשכפול נקבע בפרמטר קונפיגורציה ולא בשינוי האיסוף.
לכן התחלה בצומת בודד אינה סוגרת את הדרך לאשכול — ההרחבה נעשית בהתאם לגידול מספר המקורות, בלי להעביר נתונים שכבר נצברו.
שלבי ההטמעה: מביקורת איסוף המטריקות ועד המסירה
אנו מטמיעים Grafana Mimir כשכבה אחודה לקליטה ושאילתות מטריקות, והעבודה מתנהלת בשלבים. כל שלב נסגר בארטיפקט בר-בדיקה — רשימת יעדים, קונפיגורציה, דוח עומס — ולכן רואים על מה המערכת עומדת ומה יישאר לצוות לאחר המסירה.
- ביקורת מקורות המטריקות. אוספים מלאי יעדים: אילו רכיבים מספקים מטריקות, באיזו תדירות, כמה סדרות זמן הם יוצרים. בנפרד מחשבים את הקרדינליות של התוויות — דווקא היא קובעת את נפח האחסון ואת מהירות השאילתות, ולא מספר השרתים.
- תכנון תרשים האחסון. פורשים את הנתונים לפי תקופות: תפעוליים — ברזולוציית שניות, ארוכי טווח — עם דילול. כללי מחיקה מגדירים מראש כדי שהמרשם לא יגדל ללא בקרה.
- הגדרת קליטת המטריקות. קליטה מבוזרת עם שכפול וחיץ למקרה של אי-זמינות צומת. קליטה תואמת מסוכנים קיימים מופעלת מיד, כדי לא לבנות מחדש את האיסוף בכל המארחים בבת אחת.
- הגדרת שאילתות והתראות. מרימים את שכבת השאילתות, מעבירים פאנלי ניטור וכללים: התורן צריך לקבל אות על הידרדרות, ולא זרם של רעש. בודקים שהפאנלים הישנים קוראים נתונים בלי עריכות.
- בדיקה תחת עומס. מריצים פרופיל הקרוב לזה של הפרודקשן: גידול בקרדינליות, שיא בכתיבה, שאילתות כבדות על פני תקופה ארוכה. בנפרד בוחנים את ההתנהגות בעת כשל צומת — הקליטה לא אמורה להיעצר.
- מסירה לתפעול. מוסרים גישות, תרשים, נוהל תורנות וסדר הרחבה. המשמרת מנתחת תקלות טיפוסיות בסטנד לימודי, ולא במתאר הפרודקשן.
- כיבוי איסוף מקביל. לאחר שווידאנו שהנתונים מלאים, מכבים מתארים כפולים ומקבעים את התרשים הסופי בתיעוד.
בהמשך — ליווי: סקירת קרדינליות אחת לרבעון ובחינה מחדש של תקופות השמירה לפי הצריכה בפועל.
מה נשאר לצוות שלכם לאחר הטמעת הניטור
ההטמעה מסתיימת לא בפאנלים עובדים, אלא בסט ארטיפקטים שהצוות מתחזק בעצמו. אנו מוסרים אותם לריפוזיטורי לצד קוד השירותים: עריכות עוברות ביקורת, היסטוריית השינויים נשמרת, והחזרה אחורה אורכת דקות.
- קונפיגורציות אחסון — כללי שמירת מטריקות לכל טננט, מגבלות על מספר הסדרות הפעילות, הגדרות האחסון ארוך הטווח של Grafana Mimir ומטמון השאילתות. הכול בקבצים, ולכן שינוי מוחזר בקומיט אחד.
- תרשים זרימות המטריקות — מהאוסף במארח דרך הקולטן ועד לאחסון: היכן הנתונים נצברים, היכן נזרקים, איזה צומת נתקל במגבלה ראשון. עונה על השאלה "מדוע יש חור בפאנל".
- מדיניויות גישה — אילו אגפים רואים אילו טננטים, היכן ההרשאות הן קריאה בלבד, כיצד מונפקים ומבוטלים מפתחות קליטת מטריקות, אילו חשבונות הם שירותיים.
- פאנלים וכללי התראות כקוד — תיאורים מגורסאים של גרפים וספים, בחלוקה ל"הפרודקשן בוער" ו"אפשר להסתכל בבוקר".
- תיעוד הניטור — מפת שירותים עם בעלים, רשימת המדדים הבסיסיים, סדר הניתוח: מה לפתוח ראשון עם תלונה על הידרדרות.
- נוהל תורנות — רמות הסלמה, זמני תגובה לכל מחלקת התראות, סדר כיבוי זמני של כללים רועשים וניתוח לאחר תקלה.
פעולות טיפוסיות — לחבר שירות חדש, לפתוח טננט, לשנות סף — מתוארות שלב אחר שלב, ולכן אחרי חודש-חודשיים הצוות מבצע אותן בעצמו. אנו מתחברים כשמשתנה ארכיטקטורת האחסון, ולא לתפעול יומיומי.
מקרה בוחן: זמן איתור סיבת הכשל הצטמצם פי כמה
ניתחנו מקרה עם פלטפורמה של כמה עשרות שירותים: את המטריקות אספו שלוש מערכות מפוזרות, כל אחת עם תקופת שמירה משלה ופאנל משלה. כששירות נפל, התורן תחילה ניחש לאיזו מהן להסתכל, אחר כך הצליב ידנית גרפים משני מקורות — איתור הסיבה ארך כ-40 דקות, ועוד כ-20 לאישוש ההשערה.
מה שינינו
כניסנו את האיסוף למאגר אחד על Grafana Mimir: סוכנים מקומיים שולחים מטריקות בפרוטוקול אחוד, השמירה ארוכת הטווח הועברה לאחסון אובייקטים, וכללי הכתיבה מצברים סדרות בתדירות גבוהה לסדרות נדירות יותר.
הפאנלים וההתראות הועברו למקור משותף, וההיסטוריה נשמרה במלואה — במקום שבועיים היא זמינה לכל תקופת הניטור.
- זמן איתור סיבת הכשל: היה ~40 דקות, הפך ל-5-7 דקות בתרחישים טיפוסיים.
- זמן שחזור השירות: הצטמצם מ-45 ל-12-15 דקות הודות להתראות מוכנות ולחיבור שבין מטריקות ללוגים.
- כיסוי: כל השירותים הקריטיים תחת ניטור במקום 60%, ולכל אחד סט אחוד של פאנלים בסיסיים.
בנפרד נעלם מחלקת תקלות שלמה — סתירות בין מערכות, כאשר גרפים הראו דברים שונים עבור אותו שירות. בעבר זה עלה שעות של ניתוח סיבות וערער את האמון בנתונים; כעת המקור אחד, והשאלה "לאיזה גרף להאמין" כלל אינה עולה.
מה לעשות אם הניטור כבר עובד על סטאק ישן?
התורנות מתנהלת, ההתראות מופעלות, והיסטוריית המטריקות נצברה לאורך שנים. מעבר ביום אחד משמעו שטח עיוור בדיוק בזמן התקלה ואובדן רטרוספקטיבה — והיא נדרשת דווקא ברגעים כאלה. לכן את ההגירה מובילים דרך שילוב שתי המערכות, ולא לפי התרשים "כיבינו את הישן — הדלקנו את החדש".
למקורות המטריקות — יצואנים ושרתי המתאר הישן — מוסיפים כתובת כתיבה שנייה, remote_write אל Grafana Mimir. שני בסיסי הנתונים מתמלאים במקביל כמה שבועות: את השאילתות וההתראות ממשיך לשרת הסטאק הישן, והחדש פועל בצל. אנו משווים את הפער לפי סדרות ביקורת ומוודאים שהמצברים תואמים.
את ההיסטוריה מעבירים בשני זרמים. תחילה מזרימים את החלון החם — השבועות האחרונים שלפיהם באמת תורנים ומחזירים גרסאות — ואחר כך את הארכיון בבלוקים, ברקע ובשעות שפל, כדי שהייבוא לא יתחרה על הדיסק והרשת עם הכתיבה הייצורית.
את התורנות מעבירים בחלקים: צוות אחרי צוות, מתאר אחרי מתאר, רק לאחר שהדשבורדים והכללים סודרו ונבדקו בהצלבת נתונים. את הכללים שומרים כקוד, ולכן הדרך חזרה נשארת עריכת קונפיגורציה, ולא כתיבה מחדש.
לפני הסרת הסטאק הישן משווים שלושה דברים: שלמות ההיסטוריה, התאמת הפעלות ההתראות, וזמן התגובה לשאילתות טיפוסיות. תארו את הקונפיגורציה שלכם — נחזור עם תוכנית מעבר והערכה.
ספקות טכניים: אחסון, עומס, גישות
לפני ההתחלה הלקוח בודק תמיד את אותו הדבר: כמה נפח יתפסו הנתונים, האם המערכת תעמוד בשיא, ומי יקבל גישה. להלן — תשובות קצרות למה שבדרך כלל נדון בפגישה נפרדת בעת הטמעת Grafana Mimir.
איזה נפח אחסון יתפסו המטריקות?
את הגידול מחשבים לפני ההתחלה — לפי מספר הסדרות הפעילות ותדירות הדגימה. בלוקים ישנים מתקפלים לפי כללי השמירה, ולכן המרשם גדל באופן צפוי, ורזרבה לשיאים עונתיים נכללת מראש.
האם המערכת תעמוד בעומס שיא?
האוספים מבצעים באפר לנתונים ומגבילים את המקביליות, ומגבלות מספר הסדרות מוגדרות לכל טננט — צומת כבד אינו דוחק את האחרים. את הגבול בודקים בהרצת עומס לפני העלייה לפרודקשן.
האם זרם ההתראות יציף את התורן?
כלל התראה הוא ביטוי על מטריקה בתוספת תקופת החזקה: האות נשלח רק אם התנאי מתקיים למשך הזמן שהוגדר. הפעלות קשורות מקובצות לסיכום אחד, והספים מכוילים לפי הפיזור בפועל.
האם ניתן לפרוס את המערכת במתאר סגור?
כן, בלי גישה יוצאת החוצה: הרכיבים, הפאנלים והכללים נשארים בתוך הפרמיטר, והעדכונים מובאים דרך מרשם אימג'ים פנימי.
כיצד נחלקות הרשאות הגישה?
לפי טננטים: צוות רואה את המטריקות והפאנלים שלו, התורן רואה הכול, אך בקריאה בלבד. עריכת כללים — תפקיד נפרד, כניסה דרך קטלוג ארגוני, והפעולות מתועדות בלוג.
נדון במשימה: נבנה תרשים ניטור למתאר שלכם
הערכה לפי תיאור "צריך ניטור" תמיד יוצאת מקורבת. כדי לחשב את היקף העבודה והמועדים, אנו זקוקים לנתוני קלט על המתאר — בדרך כלל הם כבר קיימים בידי צוות התורנות או בתיעוד התשתית. שלחו את מה שיש בהישג יד, בכל צורה: רשימה, תרשים ביד, ייצוא קונפיגורציות.
- רשימת הסביבות והמתארים — היכן נדרש איסוף מטריקות והאם יש מקטעים מבודדים בלי יציאה החוצה;
- מקורות: צמתים, קונטיינרים, בסיסי נתונים, תורים, מאזני עומס, היישומים עצמם;
- מה כבר עובד — אוספי סוכנים, שרת מטריקות מקומי, ייצוא ידני לטבלאות;
- הזרימה הצפויה ועומק השמירה: כמה נקודות בשנייה וכמה רחוקה ההיסטוריה הנדרשת;
- כללי התראות — מה נחשב להידרדרות, את מי מיידעים, כיצד בנויות התורנויות;
- דרישות לגישות, להפרדת תפקידים ולביקורת פעולות;
- מה כואב כעת: תקלות שהוחמצו, פאנלים איטיים, אחסון שתפח.
בתגובה אנו מחזירים תרשים ניטור: היכן מציבים את האוספים, כיצד מפרידים בין אחסון קצר לארוך, כיצד Grafana Mimir קולט את הזרימה ומגיש שאילתות על ההיסטוריה, וכיצד נבנים הכללים וההתראות.
לתרשים אנו מצרפים תוכנית הטמעה לפי שלבים, היקף עבודה עם תחומי אחריות והערכת מועדים — עם ההנחות שהערכה זו תלויה בהן.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית. אם חלק מהנתונים חסר, נבהיר את החסר בשיחה ונקבע מה אנו לוקחים על עצמנו ומה נשאר בצד שלכם.