ניטור MySQL עם Percona PMM: הגדרת Query Analytics והתראות

Percona PMM: מדוע צווארי בקבוק ב-MySQL נשארים בלתי מורגשים

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

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

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

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

מה נותן ניטור רציף של מסד נתונים

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

זמן גילוי תקלה

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

פירוק שאילתות איטיות עד הסיבה

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

זמינות השירות וסוגי כשל

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

עומס על המסד

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

מצבי איסוף מדדים וגישות לפריסה

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

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

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

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

שלבי הטמעת ניטור: מביקורת ועד מסירה

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

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

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

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

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

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

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

מקרה בוחן: ביטלנו סוג כשל ברפליקציה

מה היה

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

מה שינינו

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

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

מה נהיה

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

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

Percona PMM או ניטור בכתיבה עצמית: מה לבחור

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

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

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

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

ספקות טכניים לפני הטמעה

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

אילו הרשאות דרושות לסוכן?

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

מה לעשות עם מסדים מחוץ להיקף?

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

לא נטבע בהתראות שווא?

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

מה עם מדדים שכבר נאספים?

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

מי מתחזק את המערכת אחרי המסירה?

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

נדון במשימת הניטור שלכם

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

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

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