הגדרת OpenTelemetry Collector לאגרגציה של טלמטריה ב-Kubernetes

OpenTelemetry Collector ב-Kubernetes: היכן נשבר איסוף הטלמטריה

בעת הגדרת OpenTelemetry Collector ב-Kubernetes, הגרסה העובדת הראשונה כמעט תמיד נבנית על עותק אחד: קליטת אותות, אצווה, שליחה לאחסון.

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

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

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

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

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

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

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

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

בשלב הקבלה אנו מתעדים אפקטים מדידים:

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

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

OpenTelemetry Collector: אפשרויות פריסה באשכול

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

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

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

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

סדר היישום: מהמלאי של המקורות ועד למסירה

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

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

תצורות, סכמות ניתוב ונוהלים בפלט

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

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

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

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

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

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

מה שינינו בצינור

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

תוצאה במספרים

נפח הטלמטריה באחסון הצטמצם פי 4.5: 78% מהזרימה הנכנסת התבררו כמיותרים. זמן איתור סיבת הכשל ירד מ-90 דקות ל-12–15 — המהנדס פותח את הטרייס הנדרש, במקום לעבור על התאמות לפי שם השירות. אבדות מדידות בזמני שיא נעלמו: בעבר בהצפת תור אבדו עד 5% מהנקודות, כעת אף ספאן עם שגיאה לא נעלם. הכלל 'נזרוק רק את מה שאיש אינו קורא' עבד: מדדי רמת עסק וכל מה שמשתתף בהתראות נשמרים במלואם.

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

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

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

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

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

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

ספקות טכניים נפוצים לפני יישום

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

מה יקרה אם השער אינו זמין?

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

כיצד להגביל את נפח הנתונים הנאספים?

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

האם ניתן להפריד גישה בין צוותים?

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

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

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

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

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