מהי OpenTelemetry וכיצד היא יכולה לשפר את איכות הקצה האחורי שלך?

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

פתרון מצוין לארגון ניטור הוא OpenTelemetry - ערכת כלים מודרנית שיכולה לשמש לניפוי באגים וניתוח ביצועים של מערכות מבוזרות.

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

היסטוריה קצרה של OpenTelemetry

חברות טכנולוגיה גדולות התמודדו לראשונה עם האתגר של רישום ומעקב מבוזר בסוף שנות ה-2000. בשנת 2010 פרסמה גוגל מאמר, Dapper, תשתית מעקב אחר מערכות מבוזרות בקנה מידה גדול , שהניח את הבסיס לכלי האיתור של טוויטר, Zipkin, שיצא ב-2012.

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

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

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

מה יש בפנים?

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

**בואו נסתכל מקרוב על כל רכיב: \

הקשרים

OpenTelemetry מציגה את הרעיון של הקשרי פעולה. הקשר כולל בעיקר תכונות כמו `trace_id` (מזהה עבור הפעולה הנוכחית) ו `span_id` (מזהה עבור בקשת משנה, כאשר לכל ניסיון חוזר של בקשת משנה יש `span_id` ייחודי).

בנוסף, הקשר יכול להכיל מידע סטטי, כגון שם הצומת שבו האפליקציה פרוסה או שם הסביבה (prod/qa). שדות אלה, הידועים כמשאבים בטרמינולוגיה של OpenTelemetry, מצורפים לכל יומן, מדד או מעקב לצורך חיפוש קל יותר. הקשרים יכולים לכלול גם נתונים דינמיים, כמו המזהה של נקודת הקצה הנוכחית ( `http_path: "GET /user/:id/info"` ), אשר ניתן לצרף באופן סלקטיבי לקבוצות של יומנים, מדדים או עקבות.

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

הנה כמה דוגמאות להפצת הקשר:

1. B3-Propagation זוהי קבוצה של כותרות ( x-b3-* ) שפותחה במקור עבור מערכת המעקב של Zipkin. זה הותאם ל-OpenTracing והשתמשו בו כלים וספריות רבות. B3-Propagation נושא trace_id / span_id ודגל המציין אם יש צורך בדגימה.

   
   

2. W3C Trace Context שפותח על ידי קבוצת העבודה של W3C, תקן זה מאחד גישות הפצת הקשר שונות לתקן אחד והוא ברירת המחדל ב-OpenTelemetry. דוגמה טובה ליישום תקנים אלו היא מעקב אחר ביצוע בקשה העוברת דרך מיקרו-שירותים המיושמים בטכנולוגיות שונות מבלי לפגוע בניטור ובדיוק ניפוי הבאגים.

מַעֲקָב

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

בהדמיה, כל סרגל נקרא "span" ויש לו "span_id" ייחודי. טווח השורש מכונה "trace" ויש לו "trace_id" , המשמש כמזהה עבור כל הבקשה.

סוג זה של הדמיה מאפשר לך:

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

יומנים

למרות הפשטות הנראית לעין, הרישום נותר אחד הכלים החזקים ביותר לאבחון בעיות. OpenTelemetry משפר את רישום הרישום המסורתי על ידי הוספת מידע הקשרי. באופן ספציפי, אם קיים מעקב פעיל, תכונות 'trace_id' ו-'span_id' מתווספות אוטומטית ליומנים, ומקשרות אותם לציר הזמן של המעקב. יתרה מכך, תכונות יומן יכולות לכלול מידע סטטי מההקשר של OpenTelemetry, כגון מזהה הצומת, כמו גם מידע דינמי, כמו מזהה נקודת הקצה הנוכחי של HTTP (`http_path: "GET /user/:id").

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

מדדים

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

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

אספנים מדדים

אספנים מדדי OpenTelemetry תואמים לתקני Prometheus ו-OpenMetrics, ומאפשרים מעבר קל לפתרונות OpenTelemetry ללא שינויים משמעותיים. ה-SDK של OpenTelemetry מאפשר לייצא דוגמאות של trace_id יחד עם מדדים, מה שמאפשר לתאם מדדים עם דוגמאות יומן ועקבות.

מתאם איתות

ביחד, יומנים, מדדים ומעקב יוצרים מבט מקיף על מצב המערכת:

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

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

דְגִימָה

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

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

כדי לפתור בעיה זו, מנגנוני הפצת ההקשר של OpenTelemetry משדרים דגל דגימה יחד עם ה-`trace_id`/`span_id`. זה מבטיח שאם השירות הראשוני שמקבל את בקשת המשתמש יחליט שיש לנטר את הבקשה בפירוט, כל שאר המערכות ילכו בעקבותיה. אחרת, על כל המערכות לייצא אותות חלקית או לא כדי לחסוך במשאבים. גישה זו נקראת "דגימת ראש" - החלטה שהתקבלה בתחילת עיבוד הבקשה, באופן אקראי או על סמך תכונות קלט מסוימות.

חוץ מזה, OpenTelemetry תומך ב-"Tail Sampling", שבו כל היישומים תמיד מייצאים את כל האותות בפירוט, אבל קיים מאגר ביניים. לאחר איסוף כל הנתונים, מאגר זה מחליט אם לשמור את הנתונים המלאים או לשמור רק מדגם חלקי. שיטה זו מאפשרת מדגם מייצג יותר של כל קטגוריית בקשה (מוצלחת/ארוכה/שגיאה) אך דורשת הגדרת תשתית נוספת.

כְּבוּדָה

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

דוגמה לכותרת להעברת כבודה לפי תקן W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

הנה כמה דוגמאות לשימוש בכבודה:

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

• פרמטרי תצורה ספציפיים הגדרות עבור SDKs או תשתית.

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

  
  

יישום תשתית

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

התהליך מורכב מארבעה שלבים:

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

   
   

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

   
   

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

   
   

4. הדמיית נתונים לבסוף, נתונים מעובדים מוצגים כלוחות מחוונים במערכות כמו Grafana (עבור מדדים ועקבות) או Kibana (עבור יומנים). זה מאפשר לצוותים להעריך במהירות את תקינות המערכת, לזהות בעיות ומגמות ולהגדיר התראות על סמך אותות שנוצרו.

יישום יישום

כדי להשתלב עם אפליקציה, עליך לחבר את ה- OpenTelemetry SDK המתאים לשפת התכנות שבשימוש או להשתמש בספריות ובמסגרות התומכות ישירות ב-OpenTelemetry. OpenTelemetry מיישמת לעתים קרובות ממשקים בשימוש נרחב מספריות מוכרות, ומאפשרים תחליפים נגררים. לדוגמה, ספריית המיקרומטר משמשת בדרך כלל לאיסוף מדדים במערכת האקולוגית של Java. ה-SDK של OpenTelemetry מספק את ההטמעות שלו של ממשקי מיקרומטר, המאפשר ייצוא מטרי מבלי לשנות את קוד היישום הראשי. יתרה מכך, OpenTelemetry מציעה הטמעות של ממשקי OpenTracing ו-OpenCensus ישנים יותר, מה שמאפשר העברה חלקה ל-OpenTelemetry.

מַסְקָנָה

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