ניטור תורי הודעות: Kafka ו-RabbitMQ בשליטה

ניטור Kafka: היכן תורים מאבדים הודעות

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

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

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

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

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

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

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

מה נותן בקרה מקצה לקצה על תורי הודעות

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

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

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

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

סוג כשלים שמפסיק להגיע למשתמש

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

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

שקיפות עיבוד הזרם

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

שלוש דרכים לאיסוף מדדים: סוכן, אספן, תוסף

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

מה כל אפשרות נותנת ומה היא שוללת — בטבלה.

מה לבחור בעומס גבוה

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

איסוף משולב במתאר אחד

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

איך אנחנו מטמיעים ניטור תורים: שלבי עבודה

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

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

מה נדרש מצדכם בכל שלב

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

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

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

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

איך אנחנו מעבירים ידע לצוות שלכם

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

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

מקרה בוחן: איך הסרנו אובדן הודעות בעומסי שיא

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

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

מה בדיוק שינינו במתאר העיבוד

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

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

במה ניטור Kafka שונה מניטור RabbitMQ?

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

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

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

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

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

שאלות טכניות שנשאלות לפני ההתחלה

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

כמה האיסוף מעמיס על האשכול?

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

מה עם אבטחת הנתונים בתורים?

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

יש לנו כבר ניטור — לא יהיה קונפליקט?

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

היכן נגמרת האחריות שלכם?

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

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

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

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

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

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

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