הגדרת ניטור MongoDB Atlas: התראות, Prometheus, Grafana

למה בלי ניטור MongoDB Atlas מפספסים כשל מאוחר

קלאסטר MongoDB Atlas נדיר שנכשל בבת אחת — לרוב הוא מדרדר בהדרגה. זמן התגובה לשאילתות כבדות עולה בעשרות אחוזים, חלק מהפעולות כבר לא נכנסות לזמן שהוקצב, וגרפי העומס נשארים בטווח הרגיל. ניטור MongoDB Atlas נדרש לא כדי לתעד צומת שנפל, אלא כדי לזהות מגמה כזו ימים לפני הכשל.

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

הוסיפו לכך גידול הדרגתי בזיכרון ושאילתות ללא אינדקס — והקלאסטר מתקרב לגבול בלי שהציג ולו מחוון אדום אחד.

האות הראשון על הבעיה כמעט תמיד מגיע מהמשתמשים: ״לא נטען״, ״הנתונים לא נכונים״, ״ההזמנה נעלמה״. מכאן מתחיל פירוק ידני לפי יומנים, שבו כבר אין להבחין בין סיבה לתוצאה, ובלי היסטוריית מדדים של כמה שבועות אי אפשר להבין מתי החל הדרדור ומה הפעיל אותו.

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

מה נותן ניטור רציף של עומס ורפליקציה

ניטור בלי קריטריונים מדידים מתדרדר לאוסף גרפים שאיש אינו מסתכל עליהם עד הכשל הראשון. הצ׳קליסט שלהלן הוא מה שנבדק על התקנה חיה של MongoDB Atlas ובשילוב Prometheus עם Grafana: כל סעיף עונה על השאלה ״מה השתנה במספרים״, ולא ״כמה פאנלים צוירו״.

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

סט כללים כזה נבדק בתרחיש אימון: מכבים צומת, מעמיסים על קולקציה, בודקים אם האות הגיע וכעבור כמה זמן. סעיף שלא עבד מושלם עד קבלה, ולא נדחה.

דרכי איסוף מדדים: כלים מובנים, קו חוץ, היברידי

מדדי Atlas זמינים מיד בשלושה ערוצים: פאנלים ו-API של השירות עצמו, ייצוא דחיפה (push) של מדדים לנקודת קצה משלכם, וסקירה של הקלאסטר באמצעות יצואן חיצוני. הקו המובנה מספק התראות וגרפים מוכנים בלי תשתית, אך שומר היסטוריה לזמן קצר ופועל עם סט ספים קבוע.

ניטור מלא מתחיל במקום שבו המדדים מגיעים לאחסון משותף — אז אפשר להשוות אותם לעומס האפליקציה ולמצב הרשת.

הבחירה בין הסכמות מצטמצמת לשלוש שאלות: כמה עמוק צריך לשמור היסטוריה, עד כמה נדרשים תנאים מורכבים בהתראות וכמה תמיכה מוכנים להקצות.

בפועל הבחירה בין קו ניטור חיצוני להיברידי נתקלת במאמץ התמיכה: יצואן וסקרייפ נותנים גמישות, אך דורשים לעקוב אחר הרשאות לרפליקות, שמות מדדים ותוויות.

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

שלבי ההגדרה: מביקורת הסכמה ועד מסירת נהלים

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

בלי המפה הזו כל סט ספים יהיה קפיצה באפלה — או ישתוק לנוכח דרדור אמיתי, או יעיר את התורן בלילה בגלל גיבוי מתוכנן. הגדרת ניטור MongoDB Atlas בנויה כך שלכל אות יהיה בעלים ופעולה מובנת.

1. ביקורת התקנה. מתעדים את הרכב הקלאסטר, צווארי בקבוק באינדקסים, מגבלות חיבורים והתראות מובנות נוכחיות — מה כבר מוגדר ומה משוכפל.
2. סכמת מדדים. מגדירים מדדי בריאות: השהיית רפליקציה, תור פעולות, שיעור שאילתות איטיות, גידול קבצי דיסק, שגיאות אימות. כל מדד נקשר להשלכה עסקית, כדי שיהיה במה להצדיק את הסף.
3. חיבור איסוף. פורסים יצואן מדדים עם חשבון נפרד לקריאה בלבד, קובעים מרווח סקירה ותקופת שמירת היסטוריה. מדדי הסטאק עוברים לאחסון משותף — לצד נתוני שאר התשתית.
4. הגדרת התראות. מפרידים רמות: אזהרה לערוץ העבודה, קריטית — לתורן. ספים קובעים לפי סטייה מקו בסיס, ולא לפי ערכים מוחלטים שמתיישנים כשהעומס גדל.
5. בדיקת התראות. מריצים עומס מלאכותי וכשלים מבוקרים: מכבים צומת, ממלאים דיסק, מנתקים רפליקציה. בודקים מה עבד, מה שתק, האם ההודעה הגיעה לתורן וכעבור כמה זמן.
6. נוהל תורנויות. מתארים רמות קריטיות, סדר הסלמה, חלונות עבודה מתוכננת ורשימת פעולות אופייניות לכל אות.
7. מסירה לצוות. מוסרים פאנלי ניטור, הנחיות לאירועים אופייניים וניתוח התראות שווא — המהנדסים שלכם מפעילים את המערכת בלעדינו.

מה נשאר אצל הצוות: קונפיגורציות, פאנלים, נהלים

אנחנו לא משאירים את הניטור כ״שירות אצלנו״ — בונים אותו בתוך הקו שלכם, כדי שהרשאות, קונפיגורציות ופאנלים יישארו אצל הצוות שלכם. להלן סט ארטיפקטים שאיתם התורן עובד בלעדינו, ומהנדס חדש פורס את האיסוף בסביבה חדשה.

• קונפיגורציות איסוף — פרמטרים של סוכנים ואינטגרציה עם API של Atlas: תקופת סקירה, רשימת מסדי נתונים וקולקציות, חריגים למרחבי מערכת.
• מפת מדדים — טבלת ״מדד → מקור → סף → בעל השירות״: רואים מאין מגיע המספר ואת מי להעיר בחריגה מהגבולות.
• פאנלי ניטור — סקירות לפי רמות: קלאסטר ורפליקציה, צמתים, חיבורים, תורי פעולות, פרופיל שאילתות איטיות.
• קונפיגורציות התראות — כללים עם ספים, חלונות דיכוי, מסלולי הודעות והסלמה לפי רמות תורנויות.
• הוראות תורן — סדר פירוק: מה לבדוק קודם, פעולות אופייניות בעת כשל, נקודת הסלמה, תיעוד האירוע.
• כללי גישה — תפקידים בפאנל ובהתראות, מפתחות נפרדים עם הרשאות מוגבלות ורוטציה.
• נוהל סקירה — תדירות בחינה מחדש של ספים, כדי שההתראות לא יהפכו לרעש שמפסיקים לקרוא.
• תיעוד פריסה — כיצד להרים איסוף בקלאסטר חדש ומה לבדוק לאחר החיבור.

כל זה נשמר במאגר ובקו הענן שלכם: הצוות שלנו עוזב, יכולות הניטור — לא.

מקרה בוחן: קיצרנו את זמן זיהוי הכשל, הסרנו התראות שווא

אלינו הגיע לקוח עם קלאסטר MongoDB Atlas בעומס: ההתראות היו מוגדרות על מעבד וערכי מדדים ממוצעים. הסף פעל כבר לאחר הדרדור, וחצי מההתראות הליליות התבררו כרעש — התורן העיר מפתח, ושניהם הסתכלו על זינוק עומס רגיל.

מה שינינו בכללים

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

מדדים לפני ואחרי

זמן הזיהוי הצטמצם מעשרות דקות לשתיים-שלוש: את הבעיה רואה התורן, לא המשתמש. שיעור התראות השווא ירד מרוב ההתראות הליליות לפחות מעשירית — את הרעש חתכו חלונות ומדדים נגזרים במקום ספים מיידיים. שיעור האירועים שהתורן סוגר בלי מפתח עלה מרבע לרוב: יש בידיו דשבורד וסדר פעולות לכל כלל. התעוררויות ליליות הפכו לבודדות — עבור הצוות זה האפקט העיקרי.

בנפרד נעלם סוג כשל שנתפס קודם לפי תלונות: מיצוי חלון יומן הפעולות על רקע פיגור רפליקה. כעת הגידול בפיגור נראה הרבה לפני שהצמתים המשניים מתחילים להחזיר נתונים מיושנים — נותר מרווח זמן להתערב לפי הנוהל.

במה התראות מובנות נבדלות מקו חוץ

התראות מובנות של Atlas הן הקו הראשון שמפעילים כשמעלים קלאסטר לעבודה. הן עוקבות אחר מדדי הפרויקט: עומס מעבד ודיסק, מספר חיבורים פעילים, פיגור רפליקציה, נפח פעולות קריאה וכתיבה, זמינות צומת.

הסף מוגדר בממשק, ההודעה נשלחת למייל, למסנג׳ר או לכתובת חיצונית — זה מספיק כדי לתפוס כשל צומת, מיצוי מקום או תעבורה שהתנפחה.

מכאן מתחילות המגבלות. הספים סטטיים וחיים בנפרד מעומס האפליקציה, חלון המיצוע נקבע על ידי הפלטפורמה, ועומק היסטוריית המדדים מוגבל לתקופת השמירה שלה. לא ניתן עוד להשוות גידול עומס לריליס מלפני שבוע או לבנייה מחדש של אינדקסים — פשוט אין נתונים בחלון הנדרש.

קו חוץ אוסף את אותם מדדים בעצמו ומניח אותם במסד נתוני סדרות זמן משלו. את עומק ההיסטוריה קובעים אנחנו: חודש לפירוקים תפעוליים, שנה ויותר למגמות ותכנון קיבולת.

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

בפאנלים הקלאסטר מופיע לצד שרת האפליקציה, המאזן והתור. האירוע נראה בשלמותו: זינוק בזמן התגובה, גידול במספר החיבורים ופיגור רפליקה נקראים בגרף אחד, ולא נאספים ידנית משלושה ממשקים.

נפרט כיצד זה נסגר: אילו מדדים לאסוף קודם, היכן לקבוע ספים וכיצד לקשור קו חוץ להתראות מובנות כדי שאותות לא ישתכפלו.

שאלות טכניות נפוצות לפני תחילת העבודה

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

ניטור MongoDB Atlas מורכב משני זרמים: טלמטריה תפעולית של הקלאסטר ומדדים מצד האפליקציות. הראשון מציג מצב צמתים, רפליקציה, תורים וקלט-פלט דיסק, והשני — כיצד שירות מסוים עומד בעומס. להלן פרטים טכניים שלרוב מבררים בשלב הזה.

הקלאסטר עובד בעומס — איך מחברים ניטור?

ניטור מתחבר לקלאסטר פעיל ולא דורש עצירה שלו. הסוכן קורא סטטיסטיקה תפעולית ולא מתערב בעיבוד שאילתות; את צריכת המשאבים של האיסוף אנחנו מגבילים כדי שלא יתחרה בעומס העבודה. הפעלה מחדש בגלגול והחלפת טופולוגיה בשלב הזה אינם נדרשים.

איך לחתוך רעש מעומסים מתוכננים?

ספים אנו בונים על סטייה מקו בסיס, ולא על ערכים מוחלטים: אינדוקס מחדש וגיבוי ליליים לא אמורים להיראות כמו אירוע. חלונות של עבודה מתוכננת וייצואים המוניים מסמנים כצפויים — ההתראות עליהם מדוכאות. לתורנות נכנס רק מה שדורש פעולה.

היכן וכמה זמן נשמרים המדדים?

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

נדון במשימה: שלחו סכמה — נחזור עם תוכנית

כדי שהערכה תהיה עניינית ולא ״בעין״, לשיחה מספיק לצרף כמה נתוני פתיחה — אנחנו מפרקים אותם לפני השיחה, ולכן הפגישה עוברת לעניין: מבררים פערים ועוברים מיד לתוכנית ההגדרה.

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

בנפרד מתעדים מה נחשב לנורמה בשעות שיא העומס — בלי קו ייחוס זה כל סף יהיה שרירותי, וההתראות יתחילו או לשתוק או להעיר את התורן בלי סיבה.

נחזור עם תוכנית הגדרה: רשימת כללים והעדיפויות שלהם, דרך בדיקת כל התראה על כשל אמיתי, הערכת עבודה לפי שלבים ונוהל מסירת הניטור — כדי שמשמרת התורן תתחזק את המערכת בלעדינו. תארו את המשימה בצורה חופשית, זה מספיק כדי להתחיל.