מדדים מבוססי לוגים: ניטור שגיאות והשהיות בזמן אמת

למה log-based metrics סוטות מהמציאות

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

מטריקות שמבוססות על לוגים (log-based metrics) יורשות את כל הפגמים של זרם הקלט: אם אירוע לא מתואר באופן מובנה או מסונן בשלב האיסוף, הוא לא ייכנס למונה, לגרף או להתראה.

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

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

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

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

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

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

Log-based metrics: אפקט מדיד לתפעול

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

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

זמן עד זיהוי והתאוששות

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

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

רעש בהתראות והמחיר של התראות שווא

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

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

משווים גישות: מונים בזרימה, אצווה והיבריד

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

מתי מצב זרימה מיותר

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

מה הולך לאיבוד בצבירת אצווה

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

איך אנחנו מטמיעים ניטור שגיאות והשהיות

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

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

בדיקה בעומס שיא

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

מגבלות ונקודות כשל של הסכמה

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

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

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

מוסרים לידיים:

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

מדיניות גישה ותפקידים

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

נהלי תורנויות ואסקלציה

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

מקרה בוחן: איך הסרנו רעש וזירזנו זיהוי כשלים

נקודת מוצא ומגבלות

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

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

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

מה יצא לפי המטריקות

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

במה עיבוד זרימה של לוגים שונה מאצווה?

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

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

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

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

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

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

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

קרדינליות, רעש ואובדן אירועים: ספקות נפוצים

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

איך להסיר רעש בהתראות בלי להחמיץ דגרדציה אמיתית?

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

מה קורה לאירועים בניתוק תקשורת עם הקולט?

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

יהיה צריך לשמור לוגים לנצח?

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

כבר פרסנו ניטור — יהיה צריך לעשות הכול מחדש?

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

נדבר על המשימה: מה לשלוח להערכה ולתוכנית

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

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

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