שירות איתור, OpenTracing ויגר

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

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

אילו בעיות ניתן לפתור באמצעות מעקב?

1. מצא צווארי בקבוק בביצועים הן בתוך שירות בודד והן על פני כל עץ הביצוע בין כל השירותים המשתתפים. לדוגמה:
   • שיחות עוקבות רבות בין שירותים, למשל, לקידוד גיאוגרפי או למסד נתונים.
   • המתנה ארוכה של קלט/פלט, כגון העברת נתונים ברשת או קריאה מהדיסק.
   • ניתוח נתונים ארוך.
   • פעולות ארוכות הדורשות מעבד.
   • קטעי קוד שאינם נחוצים להשגת התוצאה הסופית וניתן להסירם או לדחות אותם.
2. להבין בבירור באיזה סדר מה נקרא ומה קורה בעת ביצוע הפעולה.
   
   ניתן לראות, למשל, ה-Request הגיע לשירות WS -> שירות WS השלים את הנתונים דרך שירות R -> ואז שלח את הבקשה לשירות V -> שירות V הוריד הרבה נתונים מה- שירות R -> הלך לשירות P -> שירות P הלך שוב לשירות R -> שירות V התעלם מהתוצאה והלך לשירות J -> ורק אז החזיר את התשובה לשירות WS, תוך כדי המשך חישוב משהו אחר ב הרקע.
   ללא מעקב כזה או תיעוד מפורט לכל התהליך, קשה מאוד להבין מה קורה לאחר שמסתכלים על הקוד בפעם הראשונה, והקוד מפוזר על פני שירותים שונים ומוסתר מאחורי שלל שעועית וממשקים.
3. איסוף מידע על עץ הביצוע לצורך ניתוח דחוי לאחר מכן. בכל שלב של ביצוע, ניתן להוסיף מידע שזמין בשלב זה למעקב ולאחר מכן להבין אילו נתוני קלט הובילו לתרחיש כזה. לדוגמה:
   • זהות המשתמש
   • זכויות
   • סוג השיטה שנבחרה
   • שגיאת יומן או ביצוע
4. הפיכת עקבות לתת-קבוצה של מדדים וניתוח נוסף בצורה של מדדים.

איזה מעקב יכול לרשום. לְהַקִיף

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

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

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

Opentrace, Jagger וכיצד יישמנו את זה עבור הפרויקטים שלנו

יש תקן משותף Opentrace, המתאר כיצד ומה יש לאסוף, מבלי להיות קשור בעקבות למימוש ספציפי באף שפה. לדוגמה, ב-Java כל העבודה עם traces מתבצעת דרך ה-API הנפוץ של Opentrace, ומתחתיו ניתן להסתיר, למשל, Jaeger או מימוש ברירת מחדל ריק שלא עושה כלום.
אנו משתמשים יגר כיישום של Opentrace. הוא מורכב ממספר מרכיבים:

• Jaeger-agent הוא סוכן מקומי המותקן בדרך כלל בכל מחשב ושירותים מחוברים אליו ביציאת ברירת המחדל המקומית. אם אין סוכן, אז העקבות של כל השירותים במחשב זה בדרך כלל כבויים
• Jaeger-collector - כל הסוכנים שולחים אליו עקבות שנאספו, והוא מכניס אותם למסד הנתונים הנבחר
• מסד נתונים - המועדף עליהם הוא קסנדרה, אבל אנחנו משתמשים ב-elasticsearch, יש הטמעות לכמה מסדי נתונים אחרים ויישום בזיכרון שלא שומר שום דבר בדיסק
• Jaeger-query הוא שירות שנכנס למסד הנתונים ומספק עקבות שכבר נאספו לניתוח
• Jaeger-ui הוא ממשק אינטרנט לחיפוש וצפייה בעקבות, הוא פועל ב-jaeger-query

ניתן לקרוא לרכיב נפרד מימוש של opentrace jaeger עבור שפות ספציפיות, שדרכו נשלחות טווחים ל-jaeger-agent.
חיבור ג'אגר בג'אווה מסתכם ביישום ממשק io.opentracing.Tracer, שלאחריו כל העקבות דרכו יעברו לסוכן האמיתי.

ניתן גם לחבר רכיבי קפיץ opentracing-spring-cloud-starter ויישום מ-Jaeger opentracing-spring-jaeger-cloud-starter שתגדיר מעקב אוטומטית לכל מה שעובר דרך הרכיבים הללו, למשל בקשות http לבקרים, בקשות לבסיס הנתונים דרך jdbc וכו'.

רישום עקבות ב-Java

איפשהו ברמה העליונה יש ליצור את Span הראשון, ניתן לעשות זאת באופן אוטומטי, למשל על ידי בקר הקפיץ בעת קבלת בקשה, או באופן ידני אם אין. לאחר מכן הוא מועבר באמצעות Scope למטה. אם שיטה כלשהי למטה רוצה להוסיף Span, היא לוקחת את ה-activeSpan הנוכחי מ-Scope, יוצרת Span חדש ואומרת שההורה שלה קיבל ActiveSpan, והופכת את ה-Span החדש לפעיל. כאשר קוראים לשירותים חיצוניים, הטווח הפעיל הנוכחי מועבר אליהם, ושירותים אלה יוצרים טווחים חדשים המקושרים לטווח זה.
כל העבודה עוברת דרך המופע של Tracer; אתה יכול לקבל אותה דרך מנגנון DI, או GlobalTracer.get() כמשתנה גלובלי אם מנגנון DI לא עובד. כברירת מחדל, אם ה-Tracer לא אותחל, NoopTracer יוחזר שלא עושה כלום.
לאחר מכן, ה-Scoop הנוכחי מתקבל מה-Tracer דרך ScopeManager, נוצר scope חדש מהנוכחי עם ספירה חדשה מצורף, ואז נסגר ה-Scoop שנוצר, מה שסוגר את ה-Scoop שנוצר ומחזיר את ה-Scoop הקודם למצב הפעיל . היקף קשור לשרשור, לכן בעת ​​תכנות מרובה-הברגה, עליך לזכור להעביר את הטווח הפעיל לשרשור אחר, להפעלה נוספת של ה-Scoop של חוט אחר המחובר לטווח זה.

io.opentracing.Tracer tracer = ...; // GlobalTracer.get()

void DoSmth () {
   try (Scope scope = tracer.buildSpan("DoSmth").startActive(true)) {
      ...
   }
}
void DoOther () {
    Span span = tracer.buildSpan("someWork").start();
    try (Scope scope = tracer.scopeManager().activate(span, false)) {
        // Do things.
    } catch(Exception ex) {
        Tags.ERROR.set(span, true);
        span.log(Map.of(Fields.EVENT, "error", Fields.ERROR_OBJECT, ex, Fields.MESSAGE, ex.getMessage()));
    } finally {
        span.finish();
    }
}

void DoAsync () {
    try (Scope scope = tracer.buildSpan("ServiceHandlerSpan").startActive(false)) {
        ...
        final Span span = scope.span();
        doAsyncWork(() -> {
            // STEP 2 ABOVE: reactivate the Span in the callback, passing true to
            // startActive() if/when the Span must be finished.
            try (Scope scope = tracer.scopeManager().activate(span, false)) {
                ...
            }
        });
    }
}

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

private ExecutorService executor = new TracedExecutorService(
    Executors.newFixedThreadPool(10), GlobalTracer.get()
);

עבור בקשות http חיצוניות יש TracingHttpClient

HttpClient httpClient = new TracingHttpClientBuilder().build();

בעיות שהתמודדנו איתנו

• שעועית ו-DI לא תמיד פועלים אם הנותב אינו משמש בשירות או ברכיב, אז חוטי אוטומטי ייתכן ש-Tracer לא יעבוד ותצטרך להשתמש ב-GlobalTracer.get().
• הערות אינן פועלות אם זה לא רכיב או שירות, או אם קריאת השיטה מגיעה משיטה שכנה מאותה מחלקה. אתה צריך להיות זהיר, לבדוק מה עובד, ולהשתמש ביצירת עקבות ידנית אם @Traced לא עובד. אתה יכול גם לצרף מהדר נוסף להערות Java, ואז זה אמור לעבוד בכל מקום.
• במגף קפיץ וקפיץ ישן, התצורה האוטומטית של ענן קפיץ פתוח לא עובדת בגלל באגים ב-DI, אז אם אתה רוצה שעקבות ברכיבי קפיץ יפעלו אוטומטית, אתה יכול לעשות זאת באנלוגיה עם github.com/opentracing-contrib/java-spring-jaeger/blob/master/opentracing-spring-jaeger-starter/src/main/java/io/opentracing/contrib/java/spring/jaeger/starter/JaegerAutoConfiguration.java
• נסה עם משאבים לא עובד בגרובי; אתה חייב להשתמש נסה לבסוף.
• לכל שירות חייב להיות spring.application.name משלו שתחתיו יירשמו עקבות. מה דעתך על שם נפרד למכירות ולבדיקה, כדי לא לערבב ביניהם.
• אם אתה משתמש ב-GlobalTracer וב-tomcat, אז לכל השירותים הפועלים ב-tomcat זה יש GlobalTracer אחד, כך שלכולם יהיה אותו שם שירות.
• בעת הוספת עקבות לשיטה, אתה צריך להיות בטוח שהיא לא נקראת בלולאה פעמים רבות. עליך להוסיף מעקב אחד משותף לכל השיחות, אשר יתעד את זמן הפעולה הכולל. אחרת, יווצר עומס עודף.
• פעם אחת ב-jaeger-ui הם הגישו בקשות גדולות מדי למספר רב של עקבות, ומכיוון שהם לא חיכו לתגובה, הם עשו זאת שוב. כתוצאה מכך, jaeger-query החלה לאכול הרבה זיכרון ולהאט את הגמישות. עזר על ידי הפעלה מחדש של jaeger-query

דגימה, אחסון וצפייה עקבות

ישנם שלושה סוגים דגימת עקבות:

1. Const ששולח ושומר את כל העקבות.
2. הסתברותי שמסנן עקבות בהסתברות מסוימת.
3. Ratemiting המגביל את מספר העקבות לשנייה. אתה יכול להגדיר הגדרות אלה בלקוח, או ב-jaeger-agent או ב-collector. כעת אנו משתמשים ב-const 1 בערימת מעריך השווי מכיוון שאין הרבה בקשות, אבל הן לוקחות הרבה זמן. בעתיד, אם זה יפעיל עומס מיותר על המערכת, תוכל להגביל אותו.

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

כדי לראות את העקבות עליך:

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

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

רשומות

• תיעוד opentracing opentracing.io/docs/overview/what-is-tracing
• תיעוד ייגר www.jaegertracing.io/docs/1.10
• חיבור jaeger java github.com/jaegertracing/jaeger-client-java
• חיבור איתור קפיץ פתוח
  github.com/jaegertracing/jaeger-client-java
  github.com/opentracing-contrib/java-spring-cloud

מאמרים

• habr.com/ru/company/carprice/blog/340946 Jaeger Opentracing ו-Microservices בפרויקט אמיתי ב-PHP ו-Golang
• eng.uber.com/distributed-tracing מעקב מבוזר מתפתח ב-Uber Engineering
• opentracing.io/guides/java
• medium.com/jaegertracing/running-jaeger-agent-on-bare-metal-d1fc47d31fab מפעיל את Jaeger Agent על מתכת חשופה

וידאו

• www.youtube.com/watch?v=qg0ENOdP1Lo איך השתמשנו ביגר ופרומתאוס כדי לספק שאילתות משתמשים במהירות הבזק - בריאן בורהאם
• www.youtube.com/watch?v=WRntQsUajow הקדמה: ייגר - יורי שקורו, אובר ופבול לופי, רד האט
• www.youtube.com/watch?v=fsHb0qK37bc סרגיי יאקובלב, "סיפור קטן של ניצחון גדול: OpenTracing, AWS ויגר"

מקור: www.habr.com