433 Breaking Down Observability with Nitay Milner

[קישור לקובץ mp3] פודקאסט מספר 433 של רברס עם פלטפורמה - התאריך היום הוא ה 1 בפברואר 2022 והיום אנחנו מתכבדים לארח את ניתאי מילנר, שמגיע אלינו מחברת Epsagon כדי לדבר על Observability ומה זה אומר בכלל.(רן) אז ניתאי, לפני שנצלול פנימה - ספר לנו קצת על עצמך וקצת על Epsagon, או על הגלגול הנוכחי של החברה:(ניתאי) אז קודם כל, אנחנו Epsagon - ואני Product Lead ב-Epsagonהייתי בעצם ה-Core Product Manager הראשון בחברהאני מגיע מעולמות היזמות וה-Product Management - בעיקר בסטארטאפים, פחות יצא לי להתנסות ב-Enterprises.שזה Spoiler להמשך . . . .ואנחנו Epsagon - אנחנו בעצם APM מודרני - כש-APM זה Application Performance Monitoring Toolזה מה שמאפשר למפתחים לנטר את הסביבות שלהםואנחנו בעצם APM שהוא Cloud-Native - אנחנו עוזרים למפתחים לפתור בעיות בעולמות שהם מאוד Native לסביבות ה-Cloud וה-microServices.וממש לפני חצי שנה נמכרנו ל-Cisco בערך בחצי מיליארד דולר - היה  אקזיט מאוד משמעותי - והיום אנחנו מפתחים מוצר חדש, מאוד גדול ומשמעותי באותם עולמות, אבל תחת המטריה  של Cisco.(רן) Cisco - שעד היום, לפחות למיטב ידיעתי, היו יותר באיזור של ה-Networking, של דברים שהם ככה מאוד Low-level, ובעצם אתם נותנים זוית אחרת לגמרי - זאת אומרת, אתם מתחילים מהאפליקציה כמו שאמרת . . .(אורי)  . . . Cisco עושה גם Server-ים ועושה גם כל מיני  . . . .(רן) כן - אבל לפחות לפי מיטב ידיעתי, אלו דברים שהם, ככה, Low-level, הרבה סוגים של חומרות - ופה אתה [ניתאי] מגיע מלמעלה, מזוית אחרת, מכיוון האפליקציה.(ניתאי) נכון - Cisco מגיעה יותר מעולמות ה-Hardware - זה יכול להיות Switch-ים וכל החומרה של Networking וכו’ועכשיו הם בעצם מנסים לשנות את הגישה ולהכנס מאוד חזק לעולמות האפליקציה ואפשר לראות ש-Cisco עושה השקעות מאוד משמעותיות בעולם הזה - למשל, היא הוציאה הרבה מאוד כסף בקנייה של AppDynamics, שזה גם APM מודרני, בקנה מידה הרבה יותר גדולוגם ThousandEyes, שזה כלי אפליקטיבי לניטור של בעיות רשתיותמשקיעים בדברים פנימיים - כלים כמו Intersight, שעוזר לך לעשות Monitoring על ה-IT שלךואתה רואה ש-Cisco מנסה לשנות את התדמית שלה - ולעשות אולי את מה ש-Microsoft עשתה לפני כמה שנים: להפוך להיות בעצם חברה מודרנית ואולי מהגדולות הבאות.(רן) בסדר, אז בוא נדבר על הנושא שלשמו התכנסנו: Observability - המילה בעלת אלפי האותיות . . . אז אני יודע מה זה Monitoring וגם יש לי Log-ים - למה צריך להמציא לכל זה מילה חדשה? מה זה Observability? מה נשתנה הלילה הזה?(ניתאי) כן, מעניין כמה פעמים אנחנו נגמגם כשנגיד Observability בפודקאסט הזה . . . . אז בוא נתחיל מה-Basics - בוא נשבור את זה מ-Buzzword למונחים שאנחנו מכיריםאת מה זה Monitoring? זה להבין את ה-State של המערכת שלי, כפי שהיא עכשיוזה אומר שאם יש לי איזושהי בעיה במערכת שלי - Error-ים שנזרקים בדרך כלל, ה-Latency לדף האינטרנט שאני מנסה לגשת אליו עולה - ואני צריך לדעת.זה Monitoring - וה-Traditional Monitoring לרוב קורה בעזרת מטריקות (Metrics).כמו שאנחנו מכירים ויש לנו Chart-ים מאוד יפים - ברגע שהוא עולה מעל איזשהו Threshold אנחנו מקבלים איזשהו Alert ואנחנו צריכים לטפל בזה.כש-Observability, לעומת זאת, זו הדרך לדבג (Debug) את הבעיה שה-Monitoring מצא לך - בעצם זה לקבל ויזיביליות (Visibility) לתוך המערכת שלך, כדי - בצורה Ad-hoc-ית - להבין איך היא מתנהגת כרגע ומה ה-Root Causeמה מקור הבעיה? מאיפה זה נובע? למה הוא נובע?ואיך אני מתקן את זה הכי מהר שאפשר.(רן) אמרת פה הרבה דברים . . . . אז נניח שיש לי End-Point, איזושהי HTTP End-Point, ופתאום היא יותר איטית.איך Observability יכול לעשות את הקסם הזה של לדבג - מה, אתה שם Breakpoint ויש לך Debugger?(ניתאי) מצויין . . . אז בעצם, Observability יתן לך להבין איזה Down-stream Service של אותו שרת HTTP . . . כי כמו שאמרנו, רוב המערכות שאנחנו מכירים היום הן מערכות מבוזרות, וזו הנקודה של למה Observability זה חשוב בעולמות המודרנייםאז אני צריך להבין איזה Down-stream Service של אותו HTTP End-Point גורם לבעיה - בוא נגיד שזה איזשהו  User שעשה Checkout.אז ה-Checkout הזה זה ה-HTTP Service הראשון שהוא פוגש - אבל אחרי זה הוא מתפצל ומנסה לדבר עם עוד חמישה Service-ים אחרים, ויכול להיות שהם מדברים עם עוד חמישה אחרים . . . .(רן) אז אתה אומר  . . . .(אורי) . . . . ובסוף כל זה מגיע לאיזשהו Database - שהוא איטי . . . .(ניתאי) בדיוק . . . . ואני צריך להבין איפה מקור הבעיה - ולמה היא קוראת עכשיו.(רן) אז אתה אומר שבעולם ה-Monolith זה היה יותר פשוט - יש End-Point, הכל קורה In-process, ואם יש משהו איטי אז מה זה כבר יכול להיות? אולי Disc IOPs, אולי Database, אולי דברים אחרים - אבל זה יחסית יותר פשוט.(אורי) אה . . . .(רן) . . . כן, גם שם יש בעיות . . .(אורי)  . . . זה יותר עכשיו לחפור בערימה של שחת מאשר להסתכל . . . (רן) ערימה של פחת . . . אוקיי, אבל זה קצת אולי יותר פשוט מאשר ה-HTTP Request הזה, שמתפזר בין חמישה שירותים שונים, וכל אחד מהחמישה האלה אולי הולך לעוד חמישה - ואחד מהם יכול להיות איטי.(ניתאי) אז בסביבות ה-Monolith זה לא היה יותר פשוט, כמו שאתה אומר - אבל כן היו לנו את הכלים לעשות את זה בצורה נוחה.אז היינו משתמשים ב-Stack Trace - ים ושוברים את הראש מה מקור הבעיה . . . .(אורי) או פשוט לראות איזו שורת Log קופצת הכי הרבה . . .(ניתאי) נכון, ועכשיו במערכות מובוזרות, כשזה הרבה מאוד Service-ים שמדברים אחד עם השני, ממש קשה לנו להבין, ואין לנו את הכלים, לפחות כרגע, בכלים שאנחנו מדברים עליהם עכשיו - אין לנו את הכלים בעצם להבין את מקור הבעיה.(רן) אוקיי, אבל עדיין אתה קצת מדבר בסיסמאות . . . בוא ננחית את זה: מה מקור הבעיה? יש איזשהו Oracle שבא ושם את האצבע על מקור הבעיה?(ניתאי) מצויין - אז כמו שאמרנו, הבעיה היא שהסביבה שלנו היא סביבה מבוזרתיש לנו הרבה מאוד Service-ים שמדברים אחד עם השני - ואנחנו צריכים להבין את מקור הבעיה.אז נוצר איזשהו Telemetry Data - כש-Telemetry Data זה סוג של Data שעוזר לי לנטר את הסביבה שלי - שנקרא Tracing.ומה זה Tracing? הוא בא לי כדי לענות בדיוק על הבעיה הזאת -  Tracing עוזר לי לנטר את הטרנזקציות בתוך המערכתזה לא מראה לי Log, זה לא מראה לי איזושהי נקודה ספציפית בזמן שבה קרתה פעולה ספציפית - זה מראה לי ממש את כל הטרנזקציה.אז בוא ניקח את הדוגמא שלקחנו מקודם - איזשהו שרת HTTP, נגיד Checkout, שאחרי זה מתפזר לעוד חמישה Service-ים אחרים, שכל אחד מהם מתפזר לעוד חמישה אחריםה-Trace יאפשר לי, בצורה ויזאולית, לראות את כל הטרנזקציה הזאת ולהבין, די מהר, מה מקור הבעיה שלי.(רן) אז אפשר לחשוב על ה-Trace הזה כמו על ה-Stack trace שהזכרנו מקודם . . . .(אורי) ב-Monolith יש לך Stack Trace . . . (רן) בסדר, וב-microServices המבוזרים, כשיש לך . . .(אורי) . . .  אז יש לך Distributed Tracing . . . . (רן) בסדר, אז איך מתקשרים Log-ים לכל הסיפור הזה?(ניתאי) אוקיי, אז מה  . . .(אורי) זה יכול להיות עוד הרבה יותר מורכב ומסובך - כשהמערכת שלך היא גם א-סינכרונית . . . . זאת אומרת - כש-Tracing מתחיל בקריאות א-סינכרוניות - שמחה וששון, לכל ילד בלון . . . (ניתאי) נכון, באמת העולמות ה-Tracing אתה צריך לבחור ב-Vendor ספציפי שיודע לתמוך גם בקריאות א-סינכרוניות, שזה בעצם אומר שה-Trace הזה יכול להיבנות תוך-כדיזה אומר שיכול להיות שאתה תיכנס עכשיו ל-Trace ואתה תראה איזושהי טרנזקציה - ואתה תכנס אליו בעוד איזה חצי שעה ותראה שיש עוד טרנזקציות, שהן א-סינכרוניות, שקרו רק אחרי זה - בדיעבד.(אורי) אבל בכלל - קורות לי מיליוני טרנזקציות כאלה בכל שניייה, ואני מנסה להבין בעיה של מערכת - או איטיות, או דברים כאלה - אני לא מתמקד בטרנזקציה אחת ספציפית.(ניתאי) נכון, אז זה איזשהו קונספט שאנחנו מתעסקים בו הרבה, האמת שזה אחד מהאתגרים הכי גדולים שאנחנו חווים כיום - שזה בעצם אגרגציות (Aggregations) על גבי Trace-ים.כי כמו שאתה מתאר - אתה אומר “מה זה בעצם Trace?” - זה כמו שתגיד לי “Log אחד” . . . בסדר, אבל מה אני יכול ללמוד מ-Log אחד? אני הולך ל-Kibana Dashboards ואני בונה לי Dashboard-ים על גבי הדאטה של ה-Log-ים האלה.אז מה שעכשיו מדברים עליו הרבה בעולמות ה-Tracing - ובכללי בעולמות ה-Telemetry - זה לנסות להבין האם אפשר להתייחס ל-Tracing כמו שאנחנו מתייחסים ל-Log-ים, ולעשות אגרגציות על גביהם.האתגרים, כמו שאתם מנחשים, זה אתגרים של קרדינליות - זה ממש קשה, זה הרבה מאוד Data . . .תחשבו שגם ב-Trace-ים יש לנו הרבה מאוד Payload - ו-Payload יכול להיות גם User ID למשל - ול-User ID יש קרדינליות מאוד גבוהה - ולכן ממש קשה לבצע את האגרגציות האלה.והרבה מאוד מה-Vendor-ים מנסים לעשות היום אגרגציות פשוטות יותר, על גבי Trace-ים, כדי לזהות את מקור הבעיה.(רן) אז בוא נחזור רגע אחורה - נגיד שיש לנו API של Checkout, ול-Checkout הזה יש איזשהו User ID מסויים. עכשיו, יכול להיות שבמקרה עבור ה-User ID הזה הפעולות הן יותר איטיות, מאיזושהי סיבה, לא יודע - איכשהו לוקח איזה Lock ב-Database שלוקח לו יותר זמן או איזושהי סיבה אחרת . . . אולי צריך לעשות לו . . . אולי זה User שמגיע ממדינה עם יותר רגולציה וצריך לעשות שם יותר פעולות - לא יודע, יש איזושהי סיבה שה-User הזה יותר איטי.איך אני עושה Pin-points לסיפור הזה? אז אתה אומר שמצד אחד, יש לי Tracing ותיאורטית המידע שם . . .  אבל המידע הזה קיים ביחד עם “טונות” אחרות של של מידע, אוקיי? איך אני מגיע ל-Root Cause הזה? איך אני מגיע לזה שזה ה-User הזה שאיטי, או לצורך העניין כל User-ים מצ’כיה הם יותר איטיים?(ניתאי) אז ה-Use case הזה הוא Use case שיותר קל לפתור, כי אתה מדבר באמת על Event ספציפי, על איזשהו Trace אחד ספציפי.אז מה אני עושה, כמפתח? אני לוקח את ה-User ID הזה - שכנראה יש לי, כי קיבלתי תלונה עליו או שנפתח לי Ticket במערכת - ואני  עושה Ctrl + C ו-Ctrl + V למערכת של ה-Tracing - ואני מקבל את כל הטרנזקציות האחרונות שלו.ואז אני יכול להתחיל להבין מאיפה נובעת הבעיה הזאתאני רוצה לנסות לקחת אותנו צעד אחורה, ולדבר על הסוגים השונים של Telemetry Data - אנחנו מתפקסים מאוד ב-Tracing עכשיו, שזה איזשהו Telemetry Data מודרני שעוזר לנו להתמודד עם הבעיות של הסביבות המבוזרות.אבל Tracing אף פעם לא עובד לבד - וזה בדיוק מה שדיברנו עליו לפני רגע - Tracing הוא אחד משלושת הפילארים (Pillars) המרכזיים של Observability, שהם מטריקות, Log-ים ו-Trace-ים  . . .אז אני מניח שרוב הקהל שלנו באמת מכיר מה זה אומר, אבל בואו ננסה לקחת איזושהי דוגמא כדי להבין את המשמעות, או את איך שאנחנו משתמשים בכל אחד מה-Telemery Data השונים האלה.אז בוא נגיד שיש לנו איזשהו שרת HTTP, וקיבלנו Alert שיש עליה בכמות ה-500 שנזרקים על ידי השרת הזה.עכשיו, בואו נגיד שהשרת הזה הוא User Facing - יש User-ים שיכולים לגשת אליו ושכמות ה-500 שהם מקבלים עכשיו עולה - אז הבעיה הזו היא, כמובן, דחופה.אז בעצם - מטריקות זה השלב הראשון: מה שתיארתי כרגע במילים זו מטריקה: דמיינו איזשהו Chart של כמות ה-500, שהוא עקבי לאורך זמן - ופתאום יש לי איזושהי אנומליה, ו . . .(רן) אז המטריקה עוזרת לך להבין שיש בעיה, אבל עדיין לא מספיק עוזרת לך להבין מה הבעיה - אבל אתה מבין שיש פה בעיה, אולי מישהו קיבל Pager בלילה והתעורר בלילה - יופי-טופי . . .(ניתאי) נכון, אז אנחנו מגדירים את המטריקות כה-”מה?” - מה קורה עכשיו במערכת שלי? האם יש איזושהי בעיה?אז זה השלב הראשון, זה השלב של “אוקיי, אני צריך את תשומת הלב של מישהו שיבוא ויטפל”.השלב השני זה להבין מה מקור הבעיה - כמו שאמרנו מקודם, ה-HTTP Server הזה הוא רק ה-End-Point האחרון שמדבר עם הלקוחצריך להבין שמאחוריו עומדים עוד עשרות של Service-ים שמדברים אחד עם השני, ואני צריך to Pin-Point מאיפה מגיעה הבעיה.אז כאן נכנסים Trace-ים - כשאני רואה שיש לי איזושהי עלייה בגרף של ה-500, אני הולך ל-Trace-ים, אני כותב “500” ואני נכנס לאחד מה-Trace-ים כדי לראות דוגמא.ואז נפתח לי איזשהו Trace מאוד יפה וגדול, ואני יכול לראות שבכלל איזשהו Service שמדבר עם איזשהו Service אחר, מתחת ל-HTTP Service הזה, הוא זה שמעביר את ה-Error, ומחלחל אותו כלפי מעלה.אז זה בעצם ה”איפה?”(רן) אז המטריקה בעצם עוזרת לך להבין שיש בעיה, ה-Tracing עוזר לך לעשות Zoom-in על המקור של הבעיה - ועכשיו אנחנו מגיעים לשלישי?(ניתאי) כן - אז הבנתי את מקור הבעיה, בוא נגיד שזה ב-Payment Serviceעכשיו אני צריך להבין מה בדיוק הבעיה באותו ה-Serviceוכאן, אין מה לעשות, Log-ים עושים עבודה ממש טובה - כי הם מאוד מפורטים, לעומת Trace-ים.אז אני נכנס ל-Log ואני יכול לראות בדיוק מה קרה באותה הקריאה, באותו ה-Container שממש הריץ את הטרנזקציה הזו באותו הרגע - ולהבין מה מקור הבעיהיכול להיות שנשלח לו איזשהו Payload חדש שהוא לא יודע איך להתמודד איתו, ולכן הוא שולח “500” חזרה אל אותו ה-Server.(רן) אוקיי, בסדר - אז סיימנו את כיתה א’, אבל זה יחסית קל: כשיש לך בעיה של “500” זה כאילו “בפרצוף”, לפעמים אתה יכול גם לעשות לזה Reproduce וב”תנאי מעבדה” להבין מה קרה.זה יותר מורכב כשיש לך מה שנקרא “פיחות זוחל” - לאט לאט ה-Service ניהיה איטי ואיטי יותר ויותר, ואתה לא מוצא איזושהי נקודה אחת בעייתית, שאולי קיימת, אבל העניין הוא למצוא את האיטיות הזוחלת הזאת, להבין מה המקור, איפה קיים איזשהו Bottleneck - ואולי יש כמה כאלה . . . אז איך מתמודדים עם זה?(ניתאי) אני חושב שהתשובה לזה היא בעצם הנקודה הבאה, שהיא אחד מהאתגרים הכי גדולים שיש היום - זה לחבר את הנקודות בין הסוגים השונים של הדאטה שיש לנו.אז זה מאוד נחמד שיש לנו את המטריקות - זה אומר לי שיש בעיה - ואת ה-Trace-ים, שאומרים לי איפה הבעיה, ואת ה-Log-ים שאומרים לי מה הבעיה.אבל איך אני מסנכרן ביניהם? איך אני יכול לפרוץ מזה שיש לי אינדיקציה לבעיה ללהבין איפה היא ולהבין מהי?אז העניין של קורלציה בין סוגי הטלמטריה השונים זה אחד מהאתגרים הכי גדולים שיש היום בעולמות ה-Observability.אם ניקח את הדוגמא שלנו - אז ב-Click אחד יכולנו להבין שיש פה בעיהואז ב-Click שני היינו קופצים לאיזושהי Example transaction כזווב-Click השלישי היינו קופצים לאותו ה-Logוכנראה שבעיות Production היו לוקחות [כדי] לפתור - במקום שלוש שעות - חצי דקה.אז העניין של קורלציה, נכון להיום, זה אחד מהדברים שמתעסקים בהם הכי הרבה בשוק ה-Observability.(רן) אתה מדבר על קורלציה אוטומטית - אני, כמישהו שמכיר את המערכת כבר עשר שנים, אולי יודע לעשות את הקורלציה הזאת בראש [והקומיטים שלי טובים], אבל פה אתה מדבר על היכולת של מהערכת לעשות אותה בשבילי, גם אם אני לא מכיר את המערכת.(ניתאי) נכון.(אורי) . . .  וגם להבין אנומליות - מתי מתפתח לי משהו שהוא לא נורמלי.(ניתאי) כן - אז זה נקרא . . . הגרסא הכי פשוטה  של “Anomaly Detection”, ואני שם מרכאות כי זו עוד Buzzword ואני - קצת קשה לי עם Buzzwords . . . (רן) שלוש סטיות תקן מעל הממוצע - Anomaly . . . (ניתאי) תודה! בדיוק . . .  אז זה נקרא, במילים יפות, Dynamic Thresholding - מה זה אומר? “תסתכל אחורה - אם זה נראה רגיל אז סבבה, ואם זה לא נראה רגיל וזה יצא מנורמה - תספר למישהו”.זה אחד מהשלבים הבאים, של להסתכל על הדאטה ולהגיד, בצורה אוטומטית, “יש פה בעיה, משהו פה נראה לא בסדר וזה כנראה משפיע על User-ים”.ואם נחזור באמת לדבר על העולמות של הקורלציה, אז בוא נדמיין את ה-Stack שיש לנו היום:אז יש לנו Grafana ו-Prometeus, שמטפלים לנו בעצם במטריקות ומספרים לנו שיש לנו איזושהי בעיה בתוך המערכת.יש לנו OpenTelemetry ו-Jaeger למי שממש אוהב Trace-יםויש לנו ELK למי שאוהב Log-ים ומשתמש ב-Kibanaושלושת הכלים האלה בעצם מייצגים לנו סוגים שונים של Telemetry Data - ואנחנו צריכים לקפוץ מאחד לשני בצורה שהיא Seamless-ית, מה שלא קורה, נכון להיום.אז אנחנו דיברנו עכשיו רק על כלים שונים של Telemetry Data והגענו לשלושה - ובכל אחד מהעולמות האלה יש עוד 20 כלים כאלה . . . (רן) אז אתה אומר - אם אני רוצה עכשיו לעשות Log-ים, אז קודם כל יש לי כמה אופציות: יש לי כמה אופציות שהן Open Source, אני יכול גם לכתוב כמה דברים משלי, ויש גם לא מעט Service-ים שאני יכול להשתמש בהם.אני רוצה עכשיו מטריקות? אז גם פה יש כמה אופציות, למכביר - Open Source ו-Service-ים וכל זה - ואולי כל אחד מהם טוב לכשלעצמו, אבל הבעיה היא איך מחברים אותם ואיך עושים את הקורלציה הזאת שעליה דיברת.(ניתאי) אז אני אעלה את רמת ה-Complexityעד עכשיו דיברנו על סוגים מאוד ספציפיים של כלים שמתמודדים בצורה טובה יחסית עם סוגים שונים של Telemetry Data.אבל יש גם כלים שהם Domain-specific - מה זה אומר? שהם משלבים כל מיני סוגים שונים של Telemetry Data.למה רק מטריקות? למה לא רק מטריקות ו-Log-ים? למה לא Trace-ים ומטריקות ו-Log-ים?אז אנחנו יכולים להסתכל על עולמות ה-APM, שמשלב את שלושת אלה, ומנסה לתת למפתחים בעצם אינדיקציה למה שקורה מבחינת Performance בתוך המערכת שלהם.ואפשר להסתכל על Cloud Vendor Monitoring - על CloudWatch שאני בטוח שכולם מכיריםועל Network Monitoring, כמו ThousandEyesועל IT Monitoring, ועל Language-specific Tools לכל מיני אפליקציות . . .והרשימה היא באמת אינסופית . . . והגענו למצב שבו הארגונים שאנחנו עובדים בהם משתמשים בעשרות כלים שונים של Monitoring - וזה Across the stack.(אורי) אני רוצה לדבר על עוד כלי אחד, בטח לא שמעתם עליו - פיתחנו אותו ב-Outbrain בדיוק בשביל הבעיות האלה, וההשראה לדעתי היא מהכלים ש-Netflix פיתחו לסביבה שהיא מרובת-microServices - וב-Outbrain יש מאות כאלה.אנחנו קוראים לו Greener - ובגדול יושבים בתוכו כל ה-microServices ואתה מסוגל ב-View אחד לראות בעיה - כל Service מיוצג לפי כמות ה-Request-ים שהוא מקבל, כמות ה-Error-ים שנוצרו בזמן נתון וה-Latency של כל אחד מה . . . ה-Latency הממוצע של הקריאות - לא זוכר אם זה ממוצע או Median, אבל יש גם 50 Percentile וכאלה.אתה מסוגל לסדר לך, בכל רגע נתון, את ה-Service-ים לפי הפרמטרים האלה, ודי מהר אתה רואה את ה-Trace של בעיה, כי אתה יכול לראות . . . מסתדרים לך בשורה כל ה-Service-ים שיצרו בעיה ויש בעיה עם ה-Latency שלהם או שיש בעיה עם ה-Error rate שלהם - ממש במבט אחד.(ניתאי) אתה יכול לראות קשרים ביניהם?(אורי) אתה מכיר את הקשרים ביניהם כי אתה יודע מה הטופולוגיה של ה-Service-ים - ואם אתה לא מכיר, אז יש גם כלי אחר, שנותן לך את כל מפת ה-Service-ים והקשרים ביניהם וכמה Traffic עובר מאחד לאחר . . .(רן) אני חושב, אורי, כמתבונן מהצד - מה שאתה מתאר זה נשמע מאוד שימושי, אבל אני חושב שזה גם מדגיש את הנקודה שניתאי בא להגיד: יש כלים ויש עוד כלים - וכולם שימושיים, אבל עכשיו האתגר הוא לחבר ביניהם . . . האתגר הוא לתת גם לעובד החדש, שלא מכיר את הארכיטקטורה ואין לו את הניסיון עם “ה-Service ההוא שתמיד עושה בעיות” - להתעורר באמצע הלילה ולהבין כמה שיותר מהר איפה הבעיה.אז ברור שהכלים האלה עוזרים - אבל עדיין, אתה יודע - תמיד יש את ה-Tradeoff, ברגע שאתה מוסיף עוד כלי או עוד View - אוקיי, עכשיו מה הקשר בינו לבין ה-Views האחרים?(אורי) מה שאני אומר שסוג של כלים כאלה מביאים לך קודם כל לפנים, מולך, את הבעיה.(ניתאי) כן, אז באמת בחלק מהמערכות זה יכול לעבוד.אני חושב שככל שרמת המורכבות של המערכת עולה, כך קשה יותר לעשות את הקורלציה הזאת ולהבין את המקור של הבעיה.בוא נדבר בעצם על הכאבים שמסביב לזה שיש לנו הרבה מאוד כלים של Monitoring - אז הדבר הראשון, כמו שרן אמר, זה באמת איך אני, כמפתח חדש שלא ממש מכיר את ה-Stack, מבין מה מקור הבעיה?אולי מישהו שעובד כבר 10 שנים בחברה ורואה את ה-Dashboard הזה יכול להגיד “אה! ה-Service הזה קשור לעוד Service-ים אחרים וכנראה שזה מקור הבעיה”.אבל אם אני מפתח חדש, שלא מכיר את ה-Stack שלי כמו שצריך, אז אני צריך איזשהו מקום אחד שהוא Centralized כדי להבין את מקור הבעיהאז זה הדבר הראשון.דבר שני - Finger-pointing . . . . בוא נקרא לילד בשמו, זה קורה בכל החברות הכי טובות: על מי האחריות של אותו ה-Production issue שקורה כרגע?ואז מתחיל שיח בין הצוותים השונים על מי גרם לבעיה הזאת? איזה שינוי אחרון שנדחף בעצם גרם לבעיה שאנחנו מתמודדים איתה כרגע ב-Production?ועוד פעם - זה נובע מזה שיש לנו הרבה מאוד כלים שמנטרים הרבה מאוד מערכות שונות, ואין לנו מקום אחד להגיד “אוקיי, זה מקור הבעיה”.למשל -” יש לי בעיית Network שמשפיעה על האפליקציה, וגורמת לאפליקציה שלי “לטחון CPU” לתשתית - ואז היא מקריסה לי גם את התשתית.”אז אני אצטרך להשתמש בלפחות שלושה כלים כדי להבין שמקור הבעיה בכלל מתחיל ב-Network - ובסוף הוא מגיע ל-IT שלי, בסוף הוא מגיע לתשתית שלי.אז באמת העניין של האחריות זה אחד מהכאבים הגדולים - וכמובן שזה זמן ארוך יותר עד לפתירת הבעיה - ככל שאין לנו ראייה אגרגטיבית על ה-Stack הטכנולוגי שלנו, ואנחנו לא מבינים, במקום אחד, איך הוא בנוי ואיך הוא נראה - יהיה לנו מאוד קשה לפתור בעיותואנחנו רואים את זה קורה יותר ויותר בחברות - ככל שהמערכת שלהן נהיית יותר Cloud-native, יותר microServices-oriented, הרבה יותר מורכבת.(אורי) יש לי שאלה במקום הזה, כי אתה דיברת על טלמטריה (Telemetry) ועל דאטה שה-Service-ים שלנו בעצם יודעים לחשוף - אז אם יש לנו את ה-Lib הנכון בתוך ה-Stack של ה-Services שלנו, אז אנחנו יודעים שה-Lib הזה יזרוק את ה-Log-ים ואת הטלמטריה, וזה  . . . התשתית-תוכנה של ה-Service-ים שלנו דואגת לזה.אבל מה עם ה-Database שאני משתמש בו? מה עם הרכיבי-רשת? גם הם חלק מהמערכת, גם הם גורמים לבעיות -  והם לא תחת שליטתי, אני לא יודע על איזה Lib הם קומפלו (Compile) . . . .(רן) בוא, אני אספר לך סיפור מעניין - אחת ההחלטות העקרוניות שעשו פעם ב-Google זה שהם אמרו שכל רכיב תוכנה חיצוני שאני מביא חייב לחשוף את אותו הממשק כמו השירותים הפנימיים שלי. זאת אומרת שאם יש Monitoring או Ping או Whatever, אז ברור של-Service-ים שלי יהיו - אבל גם לכל Database אחר שאני אביא, גם לכל דבר אחר. אם אני משתמש בכלים חיצוניים, אני תמיד עוטף אותם - הם אף פעם לא עובדים As-is: או שיהיה להם איזשהו Sidecar או שיהיה להם איזשהו משהו שיתן את השליטה הזאת, כדי שאני אוכל להתייחס אליו כמו אל אחד מהכלים שאני כתבתי. לפחות בזמנו ככה זה עבד, אני לא יודע להגיד מה קורה היום - אבל זו שיטה או דרך אחת לעשות מיטיגציה (Mitigation), אבל אני חושב שהבעיה הזאת עדיין קיימת, כי אתה לא יכול לעשות את זה גם ל-Switch-ים, נכון? אתה לא יכול לעשות את אותו הדבר בדיוק לכל סוג של רכיב . . . (אורי) כן . . . אתה יודע, זה מזכיר לי כמה לילות טרופים, שרדפנו אחרי בעיה במערכת - ובסוף זה היה כבל שלא מוכנס טוב ל-Port שלו ב-Switch . . . זה כזה Flickering כזה . . . . עכשיו לך תשים לזה Tracing . . . (רן) צריך מצלמות-אינטרנט על הכבלים, זה הכל . . . זו המסקנה(אורי) רק זה חסר לנו במה לעשות . . .  [יש מצב שברגעים אלו ממש מישהו מגייס מיליונים על הרעיון הזה](ניתאי) אז באמת בדברים שבהם אנחנו פחות מנהלים יש לנו פחות ויזיביליות (Visibility), וכל העולם הכללי של Observability ושל Monitoring מודרני הוא סביב הניסיון לייצר לך כמה שיותר ויזיביליות.גם בתוך הדברים שאתה לא מנהל - שם זה התחיל, כל ה-Observability.תחשבו שעברו לענן ועברנו ל-Kubernetes - מה הטבע של הענן ושל Kubernetes? הטבע שלו זה הוא למסך לנו כמה שיותר דברים שאנחנו לא צריכים לדעת . . . .אז מה זה אומר? Kubernetes עושים לי Restart-ים ל-Pod-ים, מעלים לי Container-ים, מורידים לי Container-ים - אני לא יודע מה הם עושים בכללהוא כל כך דינאמי ומשתנה, שאני חייב מערכות, שיסבירו לי מה קורה שם - כי אני לא עושה את זה, מישהו אחר עושה את זה בשבילי . . . זה יכול להיות Cloud Provider שמעלים או מורידים לי שרתים, וזה יכול להיות גם ה-Kubernetes שליולכן באמת ככל שנקבל יותר ויזיביליות גם “לכבלים הרופפים שלנו”, נוכל להבין יותר מה מקור הבעיה - ולפתור את זה בצורה יותר מהירה.(רן) אבל הנקודה פה היא שאתה מקבל יותר ויזיביליות, לצורך העניין לתוך Kubernetes - ועכשיו אתה טובע בים של אינפורמציה . . . . (1) - אתה לא מבין איך Kubernetes עובד ו (2) - יש לך “טונות של אינפורמציה” שאתם לא יודע מה לעשות איתה . . . (ניתאי) נכון - אז האמת שזה איזשהו נושא שאנחנו ניגע בו ממש בקרוב.אני קורא לו “Data Analytics” - זה הצד של ה-Vendor, מי שנותן לך את “שירותי ה-Observability”, למסך ממך - בדיוק כמו ש-Kubernetes עושה - למסך ממך כמה שיותר דאטה שהוא לא רלוונטי ולהצביע לך כמה שיותר על דברים שאתה צריך להתייחס אליהם בהקדםולהנגיש לך את הכל בצורה פשוטה, אם אתה רוצה לעשות חיפושים שהם Ad-hoc-יים ולא Pre-defined.וזו, בעצם, העבודה שלנו . . . (רן) כן - ודרך אגב, אני חושב שזה מעניין לקשר לפרק שעבר, שהקלטנו עם נתי שלום [432 Carburetor 32: 2022 DevOps Predictions], שבו אחת הטענות שלו לקראת 2022 זה שהכל ניהיה נורא מסובך, בגדול  . . . הכל ניהיה נורא מסובך. נכון - אנחנו נותנים יותר Kubernetes ואנחנו נותנים APIs יותר ויותר מתוחכמים, וזה באמת מאפשר לנו לעשות דברים יותר מהר - אבל זה גם סופר-מסובך, ועכשיו צריך לבנות כלים כדי להתמודד עם המורכבות הזו.(אורי) יש עבודה לכולם . . . .(ניתאי) כן, זה מצויין בשבילנו . . . (רן) יש עבודה, יש שפה - הכל בסדר.אבל בוא, רגע, נחזור ל-Track שלנו - אמרנו שיש לא מעט כלים שיודעים לעשות Log-ים ויש לא מעט כלים שיודעים לעשות Monitoring - והשאלה היא איך עושים את ה 1 + 1 = 3 ולא 2 . . . איך עושים את האינטגרציה ביניהם?(ניתאי) אז מה שאנחנו רואים שקורה בשוק - ואנחנו רואים שקהילת ה-Open-Source מתייחסת לזה וזו תמיד אינדיקציה טובה - אנחנו שמים לב לכך שה-multiplicicty of tools, של Monitoring tools, הוא כאב לא רק לאנשים שממש מתעסקים בזה אלא  גם “למפתחים הפשוטים”.למשל, אנחנו יכולים לראות פרויקט Open source שנקרא OpenTelemetry - או Otel בקצרהו-Otel מנסה לעשות בעצם סטנדרטיזציה על Telemetry Dataמה זה אומר? זה אומר שיהיה לך איזשהו “סט כלים אחוד” של APIs ו-SDKs, שידע לעשות Instrumentation: בעצם לנטר לך את המערכת, לאסוף את המידע שהוא מנטרולשלוח אותו לאיזה Backend שאתה רוצה - שזה כבר לא חלק מ-OpenTelemetry - בשביל לעשות אנליטיקה על אותו המידע.מה שזה נותן זה בעצם את החצי הראשון של הבעיה הזאת - זה בעצם אומר שלא יהיה לך Logstash בשביל להעביר את ה-Log-ים  ואתה לא תשתמש ב-Prometeus עם ה-Exporter-ים וה-Collector-ים שלואלא יהיה לך איזשהו כלי אחד שיאפשר לך לאסוף את כל ה-Telemetry Data באותו פרוטוקול - שכולם עובדים איתו וכולם מכירים.ואז ככה אנחנו נוכל, בעצם, גם לעשות את זה בצורה אחידה וגם, בלחיצת כפתור, לעבור Vendor - שזה . . .לנו זה קצת כואב, כ-Vendor - אבל זה טוב ללקוחאז בעצם תחשבו על זה שפעם היו לכם Agent-ים ש . . . Datadog ו-New Relic וכל מיני כלים כאלה ואחרים - שיושבים לכם על האפליקציה ומנטריםולכל אחד היה את הפרוטוקול שלו, והוא היה שולח את זה ל-Backend שלווהיה מאוד קשה לעבור מזה . . .  you’d get locked in . . . .ומה שקורה עכשיו זה שבעצם תיהיה דרך אחת לאסוף ולשלוח את זה- ולא יוכלו “לנעול” יותר“בלחיצת כפתור” נוכל לעבור ל-Vendor אחר.(רן) ועכשיו אני אתן את ההערות הציניות שלי מהצד . . . אז זה נשמע קצת כמו Multi-cloud, או הבעיה של Lock-in ב-Cloud-ים, שאתה יודע - תיאורטית זה מאוד יפה, אבל אף אחד לא מצליח לעשות את זה.ו-(ב): בדרך כלל מי שמשחק את המשחק הזה של Open Platform זה השחקנים החלשים - כי השחקנים החזקים, אין להם שום אינטרס לעשות את זה. מי שכבר כל הלקוחות אצלו, הוא לא רוצה לפתוח את הפלטפורמה שלו, להיפך - הוא רוצה לסגור אותה, ואז נשאלת השאלה מה הסיכוי שזה יתפוס . . . .אז מי נמצא שם בפנים? מה קורה שם היום?(ניתאי) אז לצערם של ה-Vendor-ים, הם לא אלו ש-Calling the shots והקהילה - ובאופן כללי הכלי, ככלי למפתחים ולצוותי SREs - תופס תאוצה פנומנלית.תכתבו Open Telemetry ב-Google ותשימו לב כמה שזה . . . איזו האצה יש בשנים האחרונות מסביב לזה.וצוותי  SREs וצוותי Observability והחברות השונות כבר מתחילות להתייחס לזה, כי הם מבינים את הכאב של להינעל לאיזשהו Vendor אחד ספציפיול-OpenTelemetry - העניין הוא שזה לא רק מאפשר לך לא להינעל ל-Vendor ספציפי - זה גם נותן לך הרבה מאוד Capabilities אחרים מסביב ל-Performance.אני חושב שזה קצת יותר עמוק - אולי נצלול לזה באיזשהו סשן אחראבל העניין הוא שה-Vendor-ים - הם לא מחליטים . . . אז מה שקורה עכשיו עם ה-Vendor-ים - תיכנסו קצת ל-Datadog ול-New Relic כמו שאמרנו, ותיכנסו ל-Docs שלהם - תראו שלכולם יש עכשיו סעיף של “איך לשלוח OpenTelemetry Data אל ה-Backend שלהם”.אז מה שהם עושים זה שהם מיישרים קו . . . (רן) כן - OpenTelemetry עשו להם Kubernetes, במילים אחרות . . . .(ניתאי) בדיוק.(רן) טוב, מעניין איך זה יתפתח . . . .(אורי) מי מאחורי OpenTelemetry?(רן) “Consortium של . . . ” אני מניח . . . (ניתאי) CNCF . . . of course, כמו כל הטובים והיפים . . .(רן) יש שם איזשהו Consortium בשם, לא? . . . . Cloud Native Computing Foundation(ניתאי) אז באמת, אנחנו נתחיל לראות Shift של ה-Vendor-ים, מ-”מי אוסף את הדאטה בצורה הכי יעילה?” ו-”למי יש את Agent-ים הכי טובים?” ו-”Agentless” וכל הדברים האלה . . .אנחנו נראה Shift מזה שכל ה-Vendor-ים יפסיקו לדבר על זה לאט-לאט, והם יותר יתעסקו בדברים החשובים, בעיני - יותר יתעסקו ב-Data Analytics, כמו שאמרנו מקודםלהבין איפה הבעיה שלי, להבין איך אני יכול לפתור אותה בצורה הכי מהירה ולהנגיש ל-User את המידע הזה בצורה הכי טובהו-User Experience - כן, בסוף שלמפתחים יהיה כיף ויותר קליל בשעות הנוראיות שלהם, כשהם On-call . . .(רן) מעולה - אז נראה לי שאנחנו ממש כבר מתקרבים לסיכום.אני מנחש שאתם ב-Epsagon . . . (אורי) קיבלנו PagerDuty? . . . .(רן) קיבלנו פה Alert על סוף הזמן . . . אז אני מניח שאתם מתעסקים בדברים האלה, ב-Epsagon - תרצה קצת לספר על מה אתם עובדים?(ניתאי) כן, אני אתן איזה טיזר - אז כל הבעיות שדיברנו עליהן היום, אנחנו מנסים To Address itואנחנו מנסים To Address it בעזרת גישה שנקראית  Full-Stack Observability מה זה אומר? כן, Observability זה טוב ויפה והסברנו למה זה חשוב בסביבות Cloud, בסביבות מודרניות ולמה זה כואב לנואבל בגלל שיש כל כך הרבה כלים  היום, של Monitoring, ובגלל שה-Stack שלנו כל כך מורכב ובנוי מכל כך הרבה שכבות שונות - כל עוד לא נקבל Full-Stack Observability, כל עוד לא נקבל ויזיביליות מכל הכיוונים במקום אחד, אנחנו לא באמת נצליח לפתור בעיות בצורה מהירה.וככל שתיהיה לנו יותר קורלציה בין ה-Telemetry Data השונים ובין השכבות השונות של ה-Stack - ה-IT וה-Network וה-Cloud וה-Application שלנו - אנחנו נוכל לפתור את זה בצורה הרבה יותר פשוטה ומהירהוזה מה שאנחנו עושים היום כחלק מ-Cisco - אנחנו בונים בעצם את חזון ה-Full-Stack Observability.(רן) שזו, בסופו של דבר, תיהיה אלטרנטיבה לחלק מהמוצרים שאנחנו מכירים היום? הזכרת קודם את Datadog או מוצרים אחרים - זו תיהיה אלטרנטיבה להם, או שזה משהו שבא להשלים?(ניתאי) אז אנחנו רוצים להיות גם וגם . . .אנחנו מאוד אוהבים ותמיד אהבנו לשחק בעולמות ה-Open garden, שזה אומר שאנחנו רוצים גם “לשחק יפה” עם כלים אחריםאם ללקוח שלנו יש כלי שהוא אוהב להשתמש בו והוא טוב בו, אז אנחנו לא רוצים לקחת את זה ממנו.אנחנו רוצים לתת עוד איזושהי שכבה, על גבי המידע שכבר יש לו, כדי שהוא יוכל לעשות את הקורלציה הזאת בצורה טובה יותר.(רן) הבנתי, בסדר.אני מנחש שאתם גם מגייסים עובדים?(ניתאי) נכון מאוד . . . .אנחנו Epsagon ונקנינו ע”י Cisco - אנחנו חלק מ-Cisco עכשיו - ואנחנו עדיין, גם אם זה קצת קלישאתי, “המשפחה הקטנה” שיושבת ברוטשילד - רוטשילד 3 בתל אביב.אנחנו עובדים כרגע עם הטכנולוגיות הכי חדשות שיש ואנחנו עובדים על האתגרים הכי גדולים שיש בשוק.ויש לנו את ה-Resources ואת הגב של Cisco . . . .אז דמיינו לכם איך זה לעבוד בסטארטאפ עם משאבים בלתי נדלים . . .  זה ממש כיף לבוא לעבוד איתנו.(רן) בהצלחה שיהיה לכם!תודה שבאת, להתראות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!