הגדרת ניטור לפי דייר (מדדים/יומנים לפי דיירים)

ניטור Per-tenant: היכן המערך המשותף מאבד את האות

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

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

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

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

מה נותנת הפרדת מדדים ולוגים: אפקט מדיד

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

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

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

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

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

מצבי איסוף: מערך משותף, הפרדה מלאה, היברידי

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

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

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

סדר היישום: ביקורת, סכמה, תיוג, בדיקה

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

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

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

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

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

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

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

ערכת האספקה: תצורות, סכמות, נהלים

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

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

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

מקרה בוחן: שירות אחד הפיל את מערך הניטור המשותף

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

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

התורן קיבל מבול של הפעלות, שבע מתוך עשר התבררו כשווא, וחקירת התקלה נמשכה 4-6 שעות: תחילה היה צריך להפריד את הרעש הזר מהתקלה שלו.

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

מדדים לפני ואחרי

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

ניטור Per-tenant מול לוח משותף: מה ההבדל?

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

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

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

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

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

מה מבררים לפני תיוג זרם המדדים

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

האם חובה להפריד את כל הזרם כולו?

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

מה יקרה לנתונים שכבר נאספו?

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

איך זה ישפיע על משמרת התורנות?

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

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

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

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

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