ניטור כל מסדי הנתונים באמצעות Percona PMM: הגדרה והטמעה

ניטור בסיסי נתונים בעיניים עצומות: את ההידרדרות מזהים רק מתלונות

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

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

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

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

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

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

מה משתנה לאחר חיבור בסיסי הנתונים לניטור

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

גילוי מוקדם של הידרדרות במקום ניתוח השלכות

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

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

תמונה אחידה על פני בסיסי נתונים שונים

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

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

דרכי איסוף המדדים: סוכן מקומי, סקירה חיצונית, היברידי

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

מתי סקירה חיצונית מספיקה

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

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

מתי נדרש סוכן מקומי על הצומת

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

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

סדר ההטמעה: מאינבנטריזציה ועד מסירה

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

סכימת החיבור והפרדת הרשאות

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

בדיקת הספים וערוצי ההתראה

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

מה נשאר לצוות שלכם לאחר ההטמעה

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

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

סט קונפיגורציות וסכימות

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

נהלי תורנות ואסקלציה

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

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

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

מה היה לפני החיבור

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

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

מה השתנה לאחר מכן

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

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

במה שונה ניטור בסיסי נתונים בקלאסטר מניטור של צומת?

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

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

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

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

ספקות נפוצים לפני חיבור בסיסי הנתונים לניטור

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

היכן נשמרת ההיסטוריה ולכמה זמן?

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

בסיסי נתונים במעגל סגור, בלי גישה ישירה מהרשת הכללית

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

אצלנו כבר פרוסים אמצעי ניטור של צד שלישי

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

מי אחראי להתראות לאחר המסירה?

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

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

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

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

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