מערך נראות: מדדים, לוגים וטרייסים עם קורלציה

מחסנית Observability: מדוע מטריקות, לוגים וטрейсы מתפצלים

מחסנית observability מורכבת נראית לעיתים קרובות כך: מטריקות — במערכת אחת, לוגים — בשנייה, טрейсы — בשלישית, וכל אחת מוגדרת בפני עצמה. גרפים נבנים, רשומות נכתבות, בקשות עוברות טрейсинг — בנפרד הכול נראה תקין. הפיצול מתגלה ברגע האירוע: אין במה לאסוף מתמונה אחת משלושה מקורות, מפני שאין ביניהם מפתח משותף.

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

מזהה הבקשה בטрейсинг ובלוג נוצרים על ידי ספריות שונות, ולכן ההשוואה נעשית לפי התאמת שירות וטווח — כלומר באופן מקורב.

מכאן מתחיל חיפוש ידני של סיבת התקלה. התורן רואה עלייה בהשהיה בגרף המסכם, פותח לוגים ומסנן אותם לפי שירות, ואז עובר לטрейсинг ומחפש בקשה דומה.

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

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

מה נותנת מחסנית observability אחודה: אפקט במספרים

כאשר מטריקות, לוגים וטрейсинг מבוזר חיים במערכות שונות, התורן משווה ביניהם ידנית לפי חתימות זמן. לאיתור סיבת התקלה נדרשות עשרות דקות, וחלקו העיקרי של זמן ההשבתה מוקדש לאיתור ולא לתיקון.

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

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

מה משתנה באופן מדיד:

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

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

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

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

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

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

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

שלבי ההטמעה: ביקורת זרימות, סכימה, הגדרה, מסירה

הטמעת קונטור הנראות מתקדמת ממלאי מלאי למסירה: כל שלב נשען על הנתונים של הקודם. להלן הרצף שלפיו אנו מובילים את הפרויקט; הוא מגן מפני טעות טיפוסית שבה הכלים כבר פרוסים, והקורלציה בין מטריקות, לוגים וטрейсы עדיין לא נוצרה.

1. ביקורת מקורות טלמטריה. אוספים רשימת שירותים, בסיסי נתונים, brokers ותלויות חיצוניות: מי כבר מספק מטריקות, היכן הלוגים יושבים כקבצים, מי לא עבר אינסטרומנטציה כלל. כאן גם מתעדים את נפח הזרימה — הוא קובע את עוצמת האחסון.
2. סכימת איסוף ואחסון. מחליטים היכן הנתונים עוברים buffering בזמני שיא, מה עובר לאחסון חם ומה לארכיון, ואילו תקופות שמירה מכסות את ניתוח האירועים. מחשבים את גידול הנפח מראש, כדי שהאחסון לא ייגמר בחודש השלישי.
3. תיוג שירותים ובקשות. מציגים תוויות אחידות: שירות, סביבה, גרסת build, מזהה בקשה. הן בדיוק אלה שמחברות בהמשך מטריקה, לוג וטрейс לתמונת אירוע אחת.
4. הגדרת איסוף, פאנלים והתראות. מחברים סוכנים, מדללים מטריקות בתדירות גבוהה, בונים פאנלים לפי מסלולים מרכזיים וכללי התראה לפי מדדים משמעותיים, ולא לפי כל התפרצות.
5. בדיקה על תקלה מתורגלת. שוברים שירות בחלון מוסכם: האם הגיעה התראה, האם נמצאה לפי מזהה הבקשה כל השרשרת, והאם האיתור עמד בזמן היעד.
6. מסירת קונטור התפעול. לצוות התורני — נהלים, צ'ק-ליסטים, ניתוח התקלה המתורגלת והדרכה; נשארים בקשר עד שהתורנויות ייכנסו לשגרה רגילה.

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

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

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

בנפרד אנו מוסרים מערכת בדיקות שמאמתת את הקונפיגורציות לפני יישום: שינוי ששובר את הקורלציה בין מטריקות, לוגים וטрейсы לא עובר לסביבת העבודה.

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

מיקרה מבחן: קיצרנו פי כמה את זמן איתור סיבת התקלה

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

איחדנו את שלושת הקונטורים לשכבת ניטור אחת על Grafana: נקודת כניסה אחת לתורן, מזהה בקשה רוחבי במטריקות, בלוגים ובטрейсы, תוויות משותפות של שירות וסביבה.

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

מטריקות לפני ואחרי

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

מה לעשות אם חלק מהשירותים כבר כותבים לאחסון אחר

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

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

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

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

אם חלק מהשירותים כבר כותבים אל Elasticsearch, מפעילים העשרה בזמן קריאה: שכבת השאילתות מאחדת את הפלט של שני הקונטורים ומחברת אותו לפי מזהה הטрейс. כך הקונטור החדש מתמלא בהדרגה, והגישה לנתונים הקודמים לא אובדת באף שלב.

ספקות טכניים: אחסון, עומס, הרשאות

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

האם האיסוף לא יתחיל להאט את שירותי העבודה?

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

כיצד להפריד את הגישה ללוגים?

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

מה יקרה אם צומת האיסוף ייפול?

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

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

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

רשימת נתוני הפתיחה שלרוב מספיקה לחישוב:

• שירותים וסביבות: רשימת הרכיבים, מספר הסביבות, הבעלים שלהן וסדר ה-deploy;
• איסוף נוכחי: סוכנים ו-exporters, פורמטי מטריקות ולוגים, מה שולף טрейсы, ולאן הכול נכתב;
• נפחים: כמה טורי זמן ורשומות לוג ביום, קרדינליות של תוויות, עומק השמירה הנדרש;
• קורלציה: האם מזהה בקשה רוחבי עובר בין השירותים, האם מטריקה, לוג וטрейс של תקלה אחת מקושרים;
• אותות: אילו אירועים בתורנות, למי ולאן מגיעים, כמה התראות שווא במשמרת;
• מגבלות: דרישות למיקום הנתונים, סגמנטים ברשת, הרשאות, קונטורים ללא יציאה החוצה;
• קריטריוני קבלה: מה נחשב לתוצאה — זמן מהשגיאה ועד האות, שיעור הבקשות עם טрейс מלא, זמן ניתוח האירוע.

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