מדוע הגדרת Prometheus ב-Kubernetes נשברת כשהעומס גדל
כל עוד באשכול יש עשרה שירותים, ניטור תשתיות נראה כמו משימה שנפתרה פעם אחת: Prometheus מאתר יעדים, מדדים נכתבים, התראות מגיעות. גידול בעומס משנה את התמונה — מספר היעדים וסדרות הזמן גדל מהר יותר מקצב האיסוף ועומק האחסון שמצליחים להדביק אותו. הגדרת Prometheus ב-Kubernetes, שנבנתה לקנה המידה הנוכחי, מתפרקת כבר בשלב הבא.
הצוואר בקבוק הראשון באיסוף מדדים — יעדים שנשמטים. אחרי ריסטארט פודים מקבלים כתובות חדשות, חלקם נופלים מהסקר, ובלוחות במקום מספרים מופיעים פערים.
השני — הצפת האחסון: נתונים ישנים נדחקים לפי עומק האחסון, ותוויות כמו שם הפוד, מרחב השמות, נתיב הבקשה וקוד התשובה יוצרות גידול מתפרץ במספר סדרות הזמן. שאילתות היסטוריה מאטות בדיוק כשהנתונים נחוצים לחקירה.
השלישי — רעש בהתראות. צומת אחד שנפל מייצר מאות הפעלות בשירותים תלויים, התורן מפסיק לקרוא התראות, ונפילה אמיתית הולכת לאיבוד בין שגויות. לצד זה — כשלים של שירותים בלי התראות: כללים מתארים מצב חומרה, אבל לא תורים, שגיאות של תלויות חיצוניות וגידול בזמן התגובה. על כשל כזה הצוות לומד מהמשתמשים — כלומר מאוחר יותר מכפי שהתחיל, ובלי נתונים היכן בדיוק.
כל הנקודות האלה קשורות זו לזו: כל עוד היעדים מתגלים אוטומטית, ההתראות מקובצות לפי משמעות, ועומק האחסון ומספר התוויות מוגבלים במודע, איסוף המדדים נשאר צפוי. בהמשך נפרק איך זה נסגר — מגילוי יעדים ועד לכללים שבהם התורן מבין מיד לאן ללכת.
מה נותן ניטור מנוהל: מהירות תגובה ופחות השבתות
ניטור מנוהל מתחיל בכך שהמדדים נאספים מכל השכבות — צמתים, קונטיינרים, אפליקציות ומאזני עומס — ומתכנסים למערכת אחת עם שפת שאילתות אחידה. ב-Prometheus זהו סט סוכני איסוף, כללי רישום וסכמת תוויות צפויה שלפיה נחתך כל חתך. נראות האשכול אינה לוח גרפים לתורן, אלא מעגל שבו הדרדרות נראית לפני שהמשתמש מרגיש בה.
זמן גילוי הכשל יורד מ״לקוח כתב לתמיכה״ להתראה אוטומטית עם אובייקט מדויק: צומת, קונטיינר, תלות חיצונית. התראות מנוסחות לפי סימפטומים ולא לפי סיבה — לא ״עומס גבוה״, אלא ״שיעור התשובות השגויות נשאר מעל הסף יותר מחמש דקות״. זה מסיר רעש ומשאיר אותות שלפיהם התורן פותח מיד את ההוראה הנדרשת.
סוגי כשלים שנתפסים לפני המשתמש: דליפות זיכרון בקונטיינרים, מיצוי משאבים בצמתים, הידרדרות בפעולות דיסק, תורים תקועים, תעודות שעומדות לפוג, חוסר סנכרון בין רפליקות. לכל אחד יש מדד מבשר, ולפיו נבנה סף ההפעלה.
עלות ההשבתה נקבעת לא רק לפי משך הזמן, אלא גם לפי היקף הפעולות שנעצרו יחד עם השירות. כשהחלון בין הסטייה הראשונה של המדד לתחילת השחזור מצטמצם לדקות, חלק מהאירועים נסגרים במצב מתוכנן — בלי עבודת חירום ובלי מעבר ידני על לוגים.
שיטות איסוף מדדים ב-Kubernetes: סוכן, אופרטור, איסוף חיצוני
איסוף מדדים ב-Kubernetes לעתים רחוקות מסתדר בסכמה אחת: נתונים מגיעים גם מצמתים, גם מקונטיינרים וגם ממערכות חיצוניות. מהבחירה בין סוכן בכל צומת, אופרטור בתוך האשכול או איסוף חיצוני תלויים היקף העבודה הידנית בכל עדכון שירותים והצפויות של מאגר המדדים.
סכמות והמגבלות שלהן
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן בכל צומת | קונטור קטן עם סט שירותים יציב, נדרשים מדדי צמתים וקונטיינרים | יעדים מתוארים ידנית; בשינויים תכופים מופיעים פערים וכפילויות של סדרות |
| אופרטור באשכול | אשכול עם עדכונים תכופים, נדרשים גילוי יעדים אוטומטי וכללי תיוג אחידים | יעדים חיים כאובייקטים נפרדים; בשדרוג האשכול צריך לעקוב אחרי תאימות התיאורים |
| איסוף חיצוני | כמה אשכולות, רשתות מבודדות, נקודת אחסון אחת לכל הקונטורים | תלוי בנגישות רשתית ובהרשאות; בין האירוע למדד נוצר עיכוב |
אחסון מדדים נבחר לפי אותו עיקרון: אחסון מקומי עם תקופה מוגבלת מחזיק היסטוריה אחרונה ועונה מהר לשאילתות, וחיצוני — סדרות ארוכות לחקירת אירועים בדיעבד.
בפועל משלבים סכמות: אופרטור אחראי לגילוי אוטומטי של יעדים בתוך האשכול, וכתיבה מרוחקת מעבירה סדרות לאחסון חיצוני — כך Prometheus מפסיק להיתקל בגבול גודל הדיסק המקומי.
שלבי הטמעת ניטור: מביקורת ועד מסירת נהלים
לפרוס Prometheus באשכול זה עניין של כמה שעות. הקשיים מתחילים מאוחר יותר: המדדים נאספים, אבל לא עונים על השאלה ״מה בדיוק הידרדר ומי הולך לתקן״, התראות מגיעות בצרורות או שותקות מול בעיה אמיתית. לכן העבודה מתנהלת ברצף קבוע, שבו כל שלב נשען על הקודם ומסתיים בארטיפקט שאפשר לבדוק.
- ביקורת ניטור. עורכים מלאי של מקורות המדדים — צמתים, מצב האשכול, שירותים — מפרקים גרפים וכללים שעברו בירושה, ומאתרים אזורים עיוורים: מקומות שבהם יש נתונים אבל אף אחד לא מסתכל עליהם. התוצאה — מפת פערים ורשימה של מה שחסר.
- סכמת איסוף מדדים. מגדירים שכבות — תשתית, אפליקציות, אירועים עסקיים מרכזיים — ורמת פירוט: תדירות הסקר, תקופת האחסון, הרכב התוויות. תוויות מיותרות מנפחות את האחסון מהר יותר מגידול במספר השירותים.
- הרכבת הקונטור. מרימים Prometheus באשכול, מחברים גילוי יעדים אוטומטי כדי שפודים חדשים ייכנסו לאיסוף בלי עריכה ידנית של התצורה. מפרידים בין סביבות, אחרת קפיצות בבדיקות מעוותות את תמונת הפרודקשן.
- הגדרת כללי התראה. כותבים כללים לפי סימפטומים — אי־זמינות, גידול בשגיאות, מיצוי משאבים — ולא לכל חיבור שנדחה. מגדירים קיבוץ ודיכוי של אותות קשורים, ניתוב לפי תורנים; לכל כלל יש בעלים וסדר תגובה ראשונה.
- בדיקה תחת עומס. מזרימים תעבורה בשיא ומוציאים מהכלל בזה אחר זה צומת, אחסון, רשת עד השירות. בודקים אם ההתראה הופעלה בזמן הצפוי, אם הגיעה לאדם הנכון ואם לא העירה חצי צוות בהתראת שווא.
- מסירת נהלים והכשרת תורנים. מוסרים תיאורי תגובה, עוברים שלב־שלב על התראת תרגול, מתעדים את סדר ההסלמה. אחרי זה הצוות משנה ספים וכללים חדשים בעצמו.
תצורות, סכמות ונהלים: מה נשאר אצל הצוות שלכם
אחרי ההטמעה נשאר לצוות לא אוסף מסכים שהוגדרו ידנית, אלא מערכת משוכפלת: תצורות נמצאות במאגר קוד, שינויים עוברים בדיקה, והפריסה חוזרת על עצמה בכל קונטור. להלן רשימת הארטיפקטים שנמסרים יחד עם קונטור הניטור העובד.
- קבצי תצורה. תיאורים דקלרטיביים של איסוף מדדים, יעדי סקר וכללי חישוב מראש — עם היסטוריית עריכות ובדיקת שינויים לפני החלה.
- סכמות איסוף נתונים. מפת סקר: אילו צמתים ושירותים נכנסים למעקב, באיזה מרווח, היכן נמצאים הסוכנים ובמה נבדלות הסביבות.
- כללי התראה. ספי הפעלה, קיבוץ אותות קשורים, דיכוי כפילויות וניתוב לפי אחראים — התורן מקבל אות משמעותי אחד, לא מפולת.
- לוחות גרפים. מסכים לכל שירות: עומס משאבים, השהיות תגובה, שיעור שגיאות, עומק תורים — בפילוח לפי סביבות ועם תקופת השוואה.
- מדיניות גישה. תפקידים והרשאות: מי רק צופה, מי משנה כללים, למי יש גישה לנתונים רגישים. כניסה דרך חשבון אחיד, מפתחות לא נשמרים בגלוי.
- נוהל תורנויות. מי אחראי בשעות עבודה ומחוצה להן, סדר ההסלמה, חלונות תחזוקה שבהם התראות מדוכאות במודע.
- הוראות להפעלות טיפוסיות. מה לבדוק קודם, היכן להסתכל בגרפים, איך להחזיר שינוי לאחור ומתי להרים אירוע.
- תיעוד. תקופות אחסון מדדים, נפח האחסון אחרי ניקוי, סדר הוספת שירות חדש לניטור — בלי לפנות אלינו.
מקרה בוחן: זמן גילוי הכשלים התקצר, הפעלות שווא נעלמו
אשכול בניהול Kubernetes תוחזק בדיעבד: מדדים נאספו מחלק מהצמתים, חוברו ידנית, ושירות חדש יכול היה לחיות בלי מעקב. על כשל התורן למד מתלונת משתמשים — בממוצע אחרי חצי שעה, ויותר ממחצית ההתראות הגיעו בגלל קפיצה בודדת והתעלמו מהן באופן רגיל.
מה שינו
הגדרת Prometheus ב-Kubernetes נפרסה עם גילוי יעדים אוטומטי: הרשימה נמשכת מה-API של האשכול, ולכן עומסי עבודה חדשים נכנסים לאיסוף בלי עריכת תצורה. כללי ההתראות נכתבו מחדש — אירוע קריטי דורש סטייה יציבה לאורך כמה חלונות, לא מדידה אחת. בניתוב מטפל Alertmanager: התראות דומות מודבקות, קשורות מדוכאות, ולכל אחת רמת דחיפות משלה.
מה התוצאה
זמן התגובה של התורן הצטמצם מחצי שעה לשלוש דקות — הכשל נתפס לפני פניית משתמשים. שיעור ההפעלות השווא ירד משישה מקרים מתוך עשרה לאחד מתוך עשרים. נפח המדדים הנשמרים קטן פי שלושה באותו אופק: הסירו סדרות כפולות והגדירו מחזור חיים לנתונים במקום מצב ״לשמור הכול״.
תועלת נפרדת — חקירת אירועים: התורן מגיע לגרפים מוכנים ורואה איזו תלות הידרדרה ראשונה. גם המעקב עצמו תחת בקרה: אחרי בריאות האספן עוקבות בדיקות נפרדות, כדי ששקט בערוץ לא יתפרש כבריאות.
מה לעשות אם הניטור כבר פרוס, אבל ההתראות חסרות תועלת
ניטור פרוס כשלעצמו לא אומר דבר: אם התורן מתעלם מההתראות, הכללים מדווחים לא על מה שחשוב אלא על מה שנוח למדוד. סיבה טיפוסית — בדיקות שתלויות על כל מדד זמין: אי־זמינות של תהליך בודד, גידול בצריכת זיכרון, שגיאות בודדות ביומן. חלק מהספים נמוכים מהתנודה הטבעית של העומס, חלקם כפולים זה לזה, והאות האמיתי טובע ברעש.
מתחילים במדידה: איזה חלק מההפעלות אושר כאירוע אמיתי, ואיזה נסגר בלי פעולה. רואים אילו התראות מגיעות בצרורות באותה דקה ומתארות אירוע אחד מכמה צדדים. זה נותן רשימת כללים שאפשר להסיר בלי לאבד רגישות.
בניית כללי ההתראה מחדש יוצאת לא מהמדדים אלא מהסימפטומים: כלל מופעל על מה שהמשתמש הבחין בו — אי־זמינות שירות, זמן תגובה שעלה, אי־התאמה בנתונים. מדדים פנימיים נשארים בגרפים לצורך חקירה, אבל מפסיקים להעיר בלילה. מוסיפים קיבוץ של אותות קשורים ועיכוב לאישור, כדי שקפיצה קצרה לא תהפוך לקריאה לתורן.
הגירת התצורות מתבצעת בהדרגה ובלי לעצור שירותים: כללים מועברים למאגר קוד, מיושרים לצורה אחידה, נבדקים על נתונים היסטוריים ועוברים סקירה לפני הפעלה. הסט החדש עובד במקביל לקודם, וכללים ישנים מכובים אחד לאחד כל עוד רואים שהכיסוי לא נפגע.
בסופו של דבר התורן מקבל בודדות של התראות במשמרת במקום מאות, וכל אחת דורשת פעולה קונקרטית. הפעלות שווא מפסיקות להיות רקע, והזמן עד לתגובה מתקצר: האות נראה מיד, ולא אחרי מעבר על הפיד.
ספקות טכניים: עומס, נפח נתונים, הפעלות שווא
לפני ההתחלה הצוות הטכני שואל אותן שאלות: כמה משאבים יאכל הניטור עצמו, היכן יהיו המדדים בעוד חצי שנה, מה לעשות עם מדדים לא סטנדרטיים והאם אפשר להרים את כל זה על אשכול חי בלי לעצור שירותים. להלן איך אנחנו סוגרים כל סעיף בפועל.
איזה עומס יוצר הניטור עצמו?
Prometheus סוקר יעדים לפי לוח זמנים, ולכן הצריכה צפויה ותלויה במספר היעדים ובמרווח האיסוף, ולא בתעבורה של האפליקציה. האיסוף עובר דרך node-exporter ו-kube-state-metrics, המרווח שאנחנו קובעים הוא 15–30 שניות, ושאילתות כבדות מחושבות מראש בכללים — לוחות והתראות קוראים סדרות מוכנות. על הצומת אלה שברי אחוז מזמן המעבד, ונפח בסיס הנתונים גדל באופן ליניארי וצפוי.
כמה זמן לשמור מדדים ומה לעשות עם ישנים?
חלון חם — 15–30 ימים: זה מספיק כדי לחקור אירוע ולהשוות התנהגות שירות לפני ואחרי שחרור. בהמשך אנחנו לא מוחקים את הנתונים, אלא מדללים אותם ומעבירים לאחסון מרוחק — סדרות מפורטות נשארות זמינות לחקירה, ומגמות ארוכות בודקים לפי נקודות דחוסות. הדיסק מפסיק להיות מגבלה, וההיסטוריה נשמרת לשנים.
ומה אם המדדים לא סטנדרטיים?
לתרחישים משלנו אנחנו כותבים אקספורטרים ואוספים נתונים דרך אספן טקסט, ומשימות קצרות־חיים מחזירות תוצאה עם סיום. בהמשך — כללי צבירה ותוויות: מדדים עסקיים, עומק תורים, זמן תגובה של מערכות חיצוניות נכנסים לאותם לוחות והתראות כמו מדדי האשכול הרגילים.
האם אפשר להטמיע בלי לעצור שירותים?
כן. הניטור מותקן במרחב שמות נפרד ואינו מיירט תעבורה: אקספורטרים רק קוראים כתובות מדדים פתוחות. הפריסה מתבצעת בשלבים — קודם קונטור בדיקות, אחר כך סביבת עבודה, עם בדיקה אחרי כל שלב; תצורות וכללים מנוהלים בגרסאות, והחזרה לאחור היא פקודה אחת. עבודות תקנוניות בשירותים שלכם לא נדרשות.
ארבע התשובות האלה מסירות את עיקר השאלות לפני ההתחלה. השאר — פרטים של הקונטור הספציפי: אותם נפרק בשלב ההערכה.נדבר על המשימה: תוכנית הטמעת ניטור לאשכול שלכם
הערכת המשימה נבנית לא על שאלון, אלא על נתוני הקונטור שלכם: כמה אשכולות וצמתים, אילו שירותים קריטיים לעסק, מה כבר נאסף היום ואיזה עומק היסטוריית מדדים נדרש לחקירת אירועים. מזה תלויים גם הרכב העבודה וגם סדר החיבור של איסוף המדדים לקונטור העובד בלי לעצור שירותים.
להלן — מה יידרש מצדכם ומה ייכנס לתוכנית הטמעת הניטור.
- גישות: read-only לאשכול, הרשאות ל-namespace נפרד למערכת הניטור, חלונות שינויים מסוכמים.
- מלאי: רשימת שירותים וצמתים, מדדים קריטיים, ספי הפעלה, אחראים בתורנות.
- תוכנית הטמעת ניטור: שלבים, סדר חיבור יעדי איסוף, קריטריוני מוכנות לכל שלב.
- הרכב העבודה: פריסה ותצורה של איסוף מדדים, כללי התראות, לוחות מחוונים, אינטגרציה עם ערוצי התראה.
- הערכת המשימה: לוחות זמנים לפי שלבים, דרישות למשאבי אחסון, סיכונים — גידול בקרדינליות המדדים ונפח ההיסטוריה.
- ליווי הניטור: חקירת הפעלות שווא, עדכון כללים לשירותים חדשים, נוהל תגובה לאירועים.
- מסירה: runbook לתקלות טיפוסיות, תיעוד תצורה, הכשרת משמרת תורנים.
תארו את המשימה וכתבו את הסכמה הנוכחית של הקונטור — נחזור עם הערכת לוחות זמנים ותוכנית לפי שלבים.