OpenTelemetry Collector או Fluent Bit: העיבוד העשיר גובה יותר CPU

לאיסוף לוגים והעברתם מכל node ב־Kubernetes, Fluent Bit הוא לרוב נקודת פתיחה חסכונית יותר. OpenTelemetry Collector מתאים כאשר צריך לעבד לוגים, מדדים ו־traces בצינורות מוגדרים ולנתב אותם ליעדים שונים, אבל בתצורות שנבדקו הוא דרש יותר CPU. בבדיקת Parseable נמדדו בעומס מדדים דומה כ־41%–42% שימוש ממוצע בליבת CPU ל־Collector, לעומת כ־27%–28% ל־Fluent Bit.

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

מה באמת נמדד בהשוואת ה־CPU

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

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

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

מה קורה ללוגים בעומס ובסיבוב קבצים

בנצ׳מרק Kubernetes של VictoriaMetrics מדד בקצב של כ־10,000 רשומות לוג בשנייה 0.491 ליבת CPU ו־106.83MiB זיכרון ל־OpenTelemetry Collector, מול 0.260 ליבה ו־78.10MiB ל־Fluent Bit. מחוללי לוגים ב־Pods כתבו רשומות JSON, והאספנים קראו את קובצי הלוג תחת מגבלה זהה של ליבת CPU אחת ו־1GiB זיכרון, בלי כוונון ביצועים. זהו עומס אחר ממדדי node-exporter, ולכן הכיוון הדומה בשתי התוצאות אינו יוצר יחס חיסכון כללי.

גם בתוך ניסוי הלוגים ההשוואה אינה בידוד מוחלט של תוכנת האיסוף. הכלים שלחו נתונים למאמת באמצעות פרוטוקולים שונים: Fluent Bit העביר JSON Lines ו־Collector העביר OpenTelemetry. נמדדה אפוא שרשרת קליטה וייצוא שלמה. בצד החיובי של Fluent Bit, צריכת המשאבים בעומס הייחוס הייתה נמוכה יותר; בצד התפעולי, הזיכרון שלו עבר בשיא את מגבלת הקונטיינר והתהליך הופסק.

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

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

איזה עיבוד מקבלים מכל כלי

התיעוד הרשמי של OpenTelemetry Collector מציג רכיב לקבלה, עיבוד וייצוא של טלמטריה, עם receivers, processors, exporters ו־connectors, וכן דפוסי פריסה כסוכן וכ־gateway. המבנה מאפשר להגדיר במפורש באיזה צינור ייקלט כל סוג אות, מה יעבור עיבוד ולאיזה יעד יישלח. הוא שימושי כאשר כמה צוותים צריכים כללי סינון, אצווה, ניסיונות שליחה חוזרים או טיפול במידע רגיש לפני הייצוא.

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

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

למה מיקום ה־collector משנה את העלות

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

Gateway מרכזי של Collector מתאים כאשר רוצים להחיל מדיניות עיבוד וניתוב משותפת על מקורות רבים. אפשר גם לשלב Fluent Bit ליד קובצי הלוג עם Collector בשכבה המרכזית, אם פורמט ההעברה ושדות הרשומה נשמרים כנדרש. בדרך זו מפחיתים את העבודה בכל node ומקצים את העיבוד הכבד במקום מרוכז. המחיר אינו נעלם: ה־gateway צריך קיבולת לקליטה המצטברת, לתורים ולניסיונות חוזרים כאשר היעד מתעכב.

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

בחירה לפי עומס, אותות ותקינות

• לוגים בלבד, עם מעט סינון: Fluent Bit מתאים כנקודת פתיחה על כל node. היתרון שנמדד הוא בצריכת משאבים בתצורות מסוימות; כדי להכריע יש להביא בחשבון גם את שיא הזיכרון ואת שלמות הרשומה בזמן סיבוב קבצים.
• לוגים, מדדים ו־traces באותו מערך: שני הכלים מסוגלים לטפל באותות הללו. Collector מתאים במיוחד כשנדרשים צינורות מוגדרים ועיבוד משותף; Fluent Bit נשאר מועמד כאשר פעולות העיבוד פשוטות והתצורה שלו מכסה את הפורמטים הדרושים.
• Nodes מוגבלי משאבים ועיבוד מרכזי עשיר: שילוב של Fluent Bit ליד המקור ו־Collector כ־gateway מפריד בין עלות הקריאה המקומית לעלות הטרנספורמציה. התנאי הוא שהמעבר ביניהם ישמור על השדות ועל קצב הנתונים הדרושים בהמשך.
• רגישות לאובדן או לרשומות פגומות: השוואה מועילה צריכה לכלול תפוקה, שיאי זיכרון ושלמות נתונים תחת סיבוב קבצים והאטה ביעד. CPU נמוך בממוצע אינו מפצה על רשומה שהגיעה בלי השדות שעליהם נשענת הפעולה הבאה.

קראו גם:

• Ahrefs או Semrush: נתון גדול יותר אינו בהכרח נתון מדויק יותר
• Claude Code או Cursor: סוג המשימה חשוב יותר משם המודל
• אופציות או RSU בישראל: המסלול קובע יותר משם ההטבה