למה ניטור ClickHouse נשבר כשהעומס גדל
כל עוד האשכול קטן, מספיקים חיישני מארח בסיסיים, וניטור ClickHouse נראה כמו משימה פתורה: המעבד לא בתקרתו, הזיכרון פנוי, הדיסק מגיב. הבעיה היא שצווארי הבקבוק של האשכול אינם נמצאים ברמת החומרה, אלא בתוך ה-DBMS עצמה — בתור השאילתות, במיזוגי חלקים ברקע, בתור השכפול. חיישנים חיצוניים לא מראים אותם עד שעומס היתר כבר קרה.
הראשון שנכנע הוא זרם השאילתות האנליטיות הכבדות. דוח ללא הגבלות מרים מאות תהליכונים, דוחק את מטמון העבודה ומאלץ את המערכת לקרוא שוב נתונים מהדיסק. שאילתות איטיות מפסיקות להיות בודדות: מה שהגיב בשברירי שנייה מתחיל להגיב בשניות, והתור רק מצטבר. ניטור עומס ברמת המארח באותו רגע מדווח בזריזות שהכול תקין.
הפיגור של הרפליקות מתפתח בשקט יותר. הכתיבה עוברת לצומת אחד, מעובדת דרך תור, וכאשר זרם ההוספות עולה על קצב העיבוד שלו, חלק מהרפליקות מתחילות להחזיר נתונים מיושנים. שירות הקריאה לא מקבל שגיאות — השאילתה מצליחה, פשוט התשובה שגויה, וזה משוחזר לא בכל הצמתים.
התוצאה צפויה: על כך שהשאילתות האיטיות הידרדרו או שרפליקה פיגרה, הצוות לומד מהמשתמשים. התורן רואה תהליך חי ופורט שמגיב, כלומר לפי לוח המחוונים שלו הכול תקין. הפער הוא בדיוק כאן — יש הרבה נתונים, אבל אין מחווני מצב שלפיהם מקבלים החלטה.
נפרק איך סוגרים את זה: אילו מדדים לאסוף בתוך השרת, היכן להציב ספים ואיך לבנות אותות שמופעים לפני התלונות.
מה משתנה לאחר הטמעת מערכת התראות ולוחות מחוונים
לפני הטמעת התראות, מדדי ClickHouse בדרך כלל כבר נאספים, אבל איש לא מסתכל עליהם ברגע של גידול בעומס: תור ההוספות גדל שעות, הפיגור של הרפליקות מתגבר בהדרגה, ואנחנו לומדים על כך מהמשתמשים, לא מהמערכת. לאחר הגדרת ערכי סף ולוחות מחוונים, משתנה עצם אופן העבודה עם האשכול.
תמונה אחודה של האשכול
לוח אחד מרכז את מצב כל הצמתים: תור המיזוגים, פיגור הרפליקות, צריכת זיכרון, משך השאילתות האיטיות, חיבורים פעילים, שגיאות קריאה. המהנדס עונה על השאלה "איפה צוואר הבקבוק" תוך דקה במקום חצי שעה של מעבר על צמתים ולוגים.
התראות לפי מדדים במקום תגובה בדיעבד
הספים נקבעים לא "בעין", אלא לפי פרופיל עומס היסטורי — בנפרד לשיאי דיווח, בנפרד להעברות לילה. האות מגיע בסטייה מתמשכת, ולכן התראות שווא לא מעירות את התורן, וגידול אמיתי בתור ההוספות נראה לפני שהשאילתות מתחילות ליפול בגלל timeout.
ההידרדרות נראית לפני הכשל
זמן התגובה לאירוע מתקצר משעות לדקות, ורוב הבעיות נתפסות בשלב שבו המדד עולה, ולא אחרי תלונות על דוחות איטיים. סוג התקלות בגלל הצפת תור שלא זוהתה או פיגור רפליקות נעלם לחלוטין: המערכת לא מאפשרת לפספס את הרגע שבו מלאי המשאבים התחיל להצטמצם.
אפשרויות לאיסוף מדדים: סוכן, exporter, טבלאות מערכת
מדדי ClickHouse כברירת מחדל חיים בטבלאות המערכת של השרת עצמו: רואים אותם רק מהמארח ורק ברגע נתון. כדי לבנות גרפים ולנתח אירועים בדיעבד, נדרש קו איסוף נפרד — וכאן באמת עובדות שלוש סכמות, שביניהן בוחרים.
| סכמה | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן איסוף בכל מארח | בסיסי נתונים על שרתים ייעודיים, אשכול מכמה צמתים, נדרש איסוף מכל צומת | דורש גישה למערכת הקבצים והרשאות לקריאת לוגים; בעת עדכון image של המארח יש לבנות מחדש את הסוכן |
| Exporter חיצוני לצד השרת | פריסות container, שבהן אי אפשר להתקין דבר על המארח; נקודת חיבור אחודה לבסיס הנתונים | מחזיק חיבור קבוע לשרת, רגיש להפעלות מחדש שלו, ובאמצעות exporter אחד נאסף כל הזרם |
| סקר טבלאות מערכת לפי לוח זמנים | התחלה מהירה, בדיקות חד-פעמיות, דיבוג מדדים לא שגרתיים | רזולוציה נמוכה בזמן, אין היסטוריה, וכל שאילתה היא עומס נוסף על בסיס הנתונים העובד |
תדירות הסקר קובעת מה בכלל תראו: מרווח נדיר ממצע את הקפיצות ומסתיר קפיצות קצרות בזיכרון ובתקלות.
שמירת ההיסטוריה מועברת מתוך בסיס הנתונים העובד אל מאגר נפרד לסדרות זמן: נקודות גולמיות נשמרות לפרק זמן מוגבל, לאחר מכן נשארים צבירים בדקות ובשעות — כך שעומק של חודשים לא הופך לגידול בעומס על השרת עצמו.
בפועל משלבים בין הסכמות: סוכן או exporter נותן זרם, וטבלאות המערכת נשארות כלי לאבחון ממוקד. נפרק איך להרכיב מזה קו איסוף יציב.
שלבי הטמעה: מביקורת הסכמה ועד מסירת נהלים
העבודה מתבצעת ברצף: קודם מתעדים את תמונת העומס בפועל ואת המדדים שכבר זמינים, ורק אחר כך בונים את סכמת האיסוף. כל שלב מסתיים בארטיפקט — קונפיגורציה, כלל או נוהל, ולכן את התוצאה אפשר לבדוק, לא לקבל באמונה.
- ביקורת הסכמה והעומס. מפרקים את השאילתות המובילות, התורים, ההתפלגות בין רפליקות: איפה צוואר הבקבוק — דיסק, זיכרון או השאילתות עצמן. בפלט — רשימת מדדים שבאמת כדאי לסקור, ומרווח הסקר המתאים לקצב הנוכחי.
- תכנון סכמת האיסוף. מחליטים אילו צמתים נסקרים ישירות ואילו דרך אספן ביניים, איך נשמרת ההיסטוריה ולכמה זמן היא מספיקה. את הסכמה מתאמים לפני שמשהו מותקן.
- הגדרת הסקר. מרימים exporters על הצמתים, מאחדים מדדים לשמות אחידים, מסירים כפילויות ובודקים שהאיסוף עצמו לא יוצר עומס מורגש על בסיס הנתונים.
- כללי התראות ולוחות. את הספים מציבים לא "כברירת מחדל", אלא מערכים נצפים: בנפרד להידרדרות, בנפרד לכשל, בדחיפות שונה. לוחות מרכיבים סביב שאלות אמיתיות — מה מאט עכשיו ומה השתנה במשך היממה.
- בדיקה בסביבת סטנד. מכבים באופן מלאכותי רפליקה, ממלאים את הדיסק, עוצרים את האספן: בודקים אם הכלל הופעל, אם ההתראה הגיעה לתורן, ואם אין התראות שווא. בדיקת עומס מראה שאיסוף המדדים לא גוזל משאבים מבסיס הנתונים עצמו.
- מסירת נהלים. מוסרים תיעוד: מה משמעות כל אות, מה עושה התורן, לאן להסלים. מדריכים את המשמרת על סטנד חי.
מה נשאר אצל הלקוח: לוחות מחוונים, התראות, תיעוד
כל מה שאנחנו מגדירים נשאר אצלכם כקבצים והגדרות רגילים בתוך הקו שלכם — לא "קופסה שחורה" שתלויה בקבלן. להלן רשימה מלאה של ארטיפקטים שאנחנו מוסרים יחד עם הגישות, כדי שאת המערכת אפשר יהיה לפתח בכוחות עצמכם או למסור לצוות אחר.
- לוחות Grafana — תיאורי לוחות מחוונים במערכת בקרת גרסאות: סקירת אשכול, פילוח לפי shards ורפליקות, השהיות בהוספות ובמיזוגים, תור לכתיבה.
- כללי התראות — ספים וחלונות הפעלה: אי-זמינות של רפליקה, פיגור שכפול, גידול בהוספות מושהות, מיצוי הדיסק, זינוק בשגיאות בלוגים.
- קונפיגורציות לאיסוף מדדים — יעדי איסוף, מרווחים, חתכים לפי צמתים, מדיניות שמירה: מה מחזיקים חודשים ומה מגלגלים לסדרות מסוכמות.
- גישות ותפקידים — הפרדת הרשאות לצפייה ולשינוי, חשבונות שירות ל-exporters, חיבור ל-SSO ולקבוצות שלכם.
- נוהל תורנויות — מי מקבל התראה, סדר הסלמה, חלונות שקט בזמן עבודות מתוכננות, תיעוד ניתוח של כל הפעלה.
- תיעוד — מפת מדדים עם פירוש, נימוק לספים, סדר חיבור צומת חדש, תרשים מעבר האות מהאספן ועד להתראה.
- הוראות לתקלות אופייניות — תרחישים צעד-אחר-צעד: exporter לא מגיב, חלק מההיסטוריה אבד, התראת שווא.
- צ'ק-ליסט קבלה — הפעלת התראה לבדיקה, בדיקת תפקידים, שלמות ההיסטוריה, שחזור לוח מתוך התיאור.
כל האמור לעיל מתואם בשלב ההרצה, כדי שהקבלה תהיה פורמלית ומהירה, ולא "על סמך מילה". תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.
מקרה בוחן: זמן התגובה לכשל התקצר משעות לדקות
לפני הטמעת הניטור, הצוות למד על בעיות באשכול ClickHouse מהמשתמשים: דוחות החזירו שגיאות לפני שהתורן ראה את האות הראשון. אבחון ראשוני ארך כארבעים דקות — הלוגים הועלו ידנית, זמני האירועים הושוו לפי קבצים, התמונה הורכבה מחתיכות, וכל אותו זמן הנפילה נמשכה.
מה שינו
אספנו מדדים מכל צומת והרכבנו לוח מחוונים לפי טבלאות: מהירות הוספה וקריאה, פיגור רפליקות, מספר מיזוגים שלא הושלמו, צריכת זיכרון ומקום בדיסקים, שיעור השאילתות שנתקלות במגבלות.
ספי ההתראה הוגדרו לפי קצב השינוי של המדד, לא לפי ערך מוחלט — האות מגיע באזהרה, 10-15 דקות לפני שהמשתמש יבחין בהידרדרות.
מה קיבלנו
זמן הגילוי התקצר ל-3-5 דקות, ניתוח האירוע — מכמה שעות ל-15-20 דקות: המרווח הנדרש כבר בגרפים, ורואים איזה מדד עלה ראשון. סוג התקלות שקודם הגיע עד ללקוח (הצפת דיסק לנתונים זמניים, פיגור רפליקה אחרי עומס שיא), עכשיו נסגר בשלב האזהרה, בלי נפילה.
תסמינים זהים כבר לא נחקרים מחדש: כלל וסף נכתבים פעם אחת, והמקרה הדומה הבא נסגר אוטומטית — לפני שנודע עליו מבחוץ.
במה שונה ניטור ClickHouse מבפנים ומבחוץ
תשובה קצרה: אלה לא חלופות, אלא שני רבדים שעונים על שאלות שונות. הקו החיצוני מראה אם השירות חי ומה מצב הצומת, הפנימי — מה קורה בתוך המנוע: איך מתקדמים המיזוגים, האם הרפליקות מדביקות, האם התורים גדלים.
מבפנים האיסוף נעשה מטבלאות מערכת — system.metrics, system.events, system.query_log ומדדים אסינכרוניים. משם רואים את מה שאי אפשר לנחש מבחוץ: פיגור שכפול, מספר מיזוגים ומשכם, פגיעות במטמונים, פיזור הזמן לפי שלבי ביצוע. המחיר — תקורה: כל סקר הוא בעצמו שאילתה, נכנס ללוג, ובמרווח תדיר מתחיל לעוות את התמונה.
מבחוץ אוספים את מצב התהליך והצומת: זמינות וזמן תגובה, מילוי הדיסק, זיכרון, חיבורים פתוחים. הקו הזה ממשיך להגיב כשהמנוע כבר שותק — דווקא הוא תופס כשל, ולא הידרדרות.
| גישה | מה מציגה | מגבלות |
|---|---|---|
| מבפנים המנוע | מיזוגים, שכפול, תורים, מטמונים, זמן שלבי השאילתה | יוצר עומס בעצמו; בכשל מנוע אין נתונים |
| קו חיצוני | זמינות, זמן תגובה, דיסק, זיכרון, חיבורים | לא רואה תורים פנימיים ופיגור רפליקות |
בפועל משלבים את הקווים יחד: סקר תדיר מבחוץ ונדיר מבפנים — מרווחים שונים לסוגי מדדים שונים, כדי שהשלמות לא תירכש בעומס מיותר. מפרידים בין ההתראות לפי משמעות: הרובד החיצוני אחראי ל"השירות אינו זמין", הפנימי — ל"השירות עובד אבל מידרדר".
ספקות טכניים נפוצים לפני תחילת העבודה
איסוף מדדים בעצמו הופך לעומס — החשש מוצדק, אבל רק בסכמה שגויה. Exporter קורא מוני מערכת שכבר חושבו על ידי השרת, ולא סורק את נתוני הטבלאות. להלן שאלות שמועלות לרוב בפגישה הראשונה.
הסקר לא יהפוך לעומס מיותר על האשכול?
הדגימה נעשית לפי מוני מערכת מהזיכרון של הצומת, ולא לפי נתוני הטבלאות: ההוצאה היא רשת וכתיבה למאגר המדדים. מדדים חמים נלקחים כל 15–30 שניות, קיבולת וגדלים — כל דקה. שאילתות כבדות להיסטוריה לא נכנסות לסקר.
כמה היסטוריה לשמור כדי שהמאגר לא יגדל בלי סוף?
נקודות גולמיות חיות בחלון קצר — הוא מספיק לניתוח אירוע. לאחר מכן פועלים כללי צבירה: קיפול בדקות ובשעות נשמר חודשים, ולכן גרפים לרבעון נשארים, והנפח גדל באופן צפוי.
ההתראות לא יהפכו לזרם של התראות שווא?
כללים בונים על נגזרות: השהיית שכפול, תור מיזוגים, שיעור כשלים — ולא על "מקום קטן מהסף". לכל אחד מוגדר פרק יציבות, והאות יוצא רק אם המצב נמשך כמה מחזורים. התורן רואה מה בדיוק הידרדר ובאיזה צומת.
אצלנו כבר פרוס ניטור — הכול צריך לבנות מחדש?
קודם מלאי: מה נאסף, אילו לוחות חיים, היכן כללים מכפילים זה את זה. משתלבים בקו הקיים — משלימים מקורות וכללים, שומרים את היסטוריית המדדים ומחברים ללוחות חדשים, ואת הישנים משאירים לעבוד.
נדבר על המשימה ונחזור עם הערכה ותוכנית עבודה
כדי לחזור עם תוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים נתוני קלט על הקו שלכם. מספיקה טופולוגיה: כמה צמתים ו-shards, איך בנוי השכפול, מאיפה מגיעות ההוספות ואילו צרכנים קוראים את הנתונים.
אם כבר היו תקלות, תארו איך הן באו לידי ביטוי — השהיית שכפול, כשלים במיזוגים, גידול בתור להוספה או כשל של צומת אחד.
את הגישות מתכננים מראש, כדי לא לפגוע בדבר בקו הייצור: משתמש נפרד לקריאה בלבד של טבלאות מערכת, איסוף מדדים מצמתי ClickHouse ומהאספן, נתיב רשת נפרד ללוחות עם גרפים. אף אחת מהעריכות האלה לא דורשת הרשאות כתיבה לנתונים.
מצדנו נחזור לא בספרה אחת, אלא בניתוח שאפשר לקבל לפיו החלטה:
- נתוני קלט על הקו: מספר צמתים ו-shards, סכמת שכפול, מקורות הוספה, נפח הנתונים.
- גישות: משתמש לקריאה בלבד של טבלאות מערכת, כללי רשת לצמתים וללוחות.
- היסטוריית תקלות: איך באו לידי ביטוי, תוך כמה דקות שמתם לב, כמה זמן לקח האבחון.
- ספים והתראות: אילו מדדים חשובים דווקא לכם ומי מקבל אות לתורן.
- היקף העבודה והגבולות: מה עושים אנחנו, מה נשאר בצד שלכם — רשת, הרשאות, שינויי קונפיגורציה.
- תוכנית עבודה לפי שלבים עם לוחות זמנים ונקודות שבהן אתם רואים תוצאה ביניים.
- הערכת הפרויקט: היקף העבודה, תלויות וסיכונים, ולא ספרה אחת בלי הסברים.
תארו את המשימה בצורה חופשית — כתבו מה כבר כואב ואילו מדדים הייתם רוצים לראות בלוחות המחוונים. נחזור עם הערכה, הרכב עבודות ולוחות זמנים.