streamalism.org

1. סקירה כללית

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

נלמד כיצד להשתמש, להגדיר ולהרחיב את כלי הניטור הזה ב- Spring Boot 2.x וב- WebFlux, תוך ניצול מודל התכנות תגובתי. לאחר מכן נדון כיצד לעשות זאת באמצעות Boot 1.x.

Spring Boot Actuator זמין מאז אפריל 2014, יחד עם המהדורה הראשונה של Spring Boot.

עם שחרורו של Spring Boot 2, מגן עוצב מחדש, ונקודות קצה מרגשות חדשות נוספו.

אנו מחלקים מדריך זה לשלושה חלקים עיקריים:

• מהו מפעיל?
• מגף קפיץ 2.x
• קפיץ אתחול 1.x

2. מהו מפעיל?

למעשה, Actuator מביא ליישומים שלנו תכונות מוכנות לייצור.

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

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

מפעיל רגיל בעיקר לחשוף מידע תפעולי אודות היישום הפועל - בריאות, מדדים, מידע, dump, env וכו '. היא משתמשת בנקודות קצה HTTP או שעועית JMX כדי לאפשר לנו לקיים אינטראקציה איתה.

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

2.1. מתחילים

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

במייבן:

 org.springframework.boot spring-boot-starter-actuator 

שים לב שהדבר נשאר תקף ללא קשר לגרסת האתחול, שכן גרסאות מוגדרות בכתב העת Boot Boot of Materials (BOM).

3. מגף קפיץ 2.x מפעיל

ב- 2.x, Actuator שומר על כוונתו הבסיסית אך מפשט את המודל שלו, מרחיב את יכולותיו ומשלב ברירות מחדל טובות יותר.

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

בין השינויים השונים, חשוב לזכור שחלקם נשברים. זה כולל בקשות ותגובות HTTP וכן ממשקי API של Java.

לבסוף, הגרסה האחרונה תומכת כעת במודל CRUD בניגוד למודל הקריאה / כתיבה הישן.

3.1. תמיכה טכנולוגית

עם הגרסה הגדולה השנייה שלה, Actuator הוא כיום אגנוסטי טכנולוגי ואילו ב- 1.x הוא היה קשור ל- MVC, ולכן ל- API של Servlet.

ב- 2.x, Actuator מגדיר את המודל שלו כניתוח וניתן להרחבה מבלי להסתמך על MVC על כך.

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

יתר על כן, ניתן להוסיף טכנולוגיות עתידיות על ידי הטמעת המתאמים הנכונים.

לבסוף, JMX נותרת נתמכת כדי לחשוף נקודות קצה ללא כל קוד נוסף.

3.2. שינויים חשובים

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

לפיכך, שני היחידים הזמינים כברירת מחדל הם /בְּרִיאוּת ו / מידע.

אם נרצה לאפשר את כולם, נוכל להגדיר management.endpoints.web.exposure.include = *. לחלופין, אנו יכולים לרשום נקודות קצה שאמורות להיות מופעלות.

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

לכן, כדי לשנות את כללי האבטחה של Actuator, נוכל פשוט להוסיף ערך עבור /מַפעִיל/**:

@Bean SecurityWebFilterChain ציבורי securityWebFilterChain (ServerHttpSecurity http) {להחזיר http.authorizeExchange () .pathMatchers ("/ actuator / **"). PermAll () .anyExchange (). מאומת () .and (). Build (); }

אנו יכולים למצוא פרטים נוספים על המסמכים הרשמיים החדשים של Actuator.

גַם, כברירת מחדל, כל נקודות הקצה של המפעיל ממוקמות כעת תחת ה- /מַפעִיל נָתִיב.

כמו בגירסה הקודמת, אנו יכולים לשנות את הנתיב הזה באמצעות המאפיין החדש management.endpoints.web.base-path.

3.3. נקודות קצה מוגדרות מראש

בואו נסתכל על כמה נקודות קצה זמינות, שרובן כבר היו זמינות ב- 1.x.

גַם, חלק מנקודות הקצה נוספו, חלקן הוסרו וחלקן הותאמו מחדש:

• / אירועי ביקורת מפרט אירועים הקשורים לביקורת אבטחה כגון כניסה / כניסה למשתמש. כמו כן, אנו יכולים לסנן לפי עיקרון או סוג בין שדות אחרים.
• /שעועית מחזירה את כל השעועית הזמינה אצלנו BeanFactory. בניגוד / אירועי ביקורת, זה לא תומך בסינון.
• / תנאים, בעבר נקרא /תצורה אוטומטית, בונה דוח של תנאים סביב תצורה אוטומטית.
• / configprops מאפשר לנו להביא הכל @ConfigurationProperties שעועית.
• / env מחזירה את מאפייני הסביבה הנוכחיים. בנוסף, אנו יכולים לאחזר מאפיינים בודדים.
• /דרך טיסה מספק פרטים על העברות מסד הנתונים Flyway שלנו.
• /בְּרִיאוּת מסכם את המצב הבריאותי של היישום שלנו.
• / heapdump בונה ומחזיר מזבלה ערימה מה- JVM המשמשת את היישום שלנו.
• / מידע מחזיר מידע כללי. זה יכול להיות נתונים מותאמים אישית, מידע על בנייה או פרטים על ההתחייבות האחרונה.
• / liquibase מתנהג כמו /דרך טיסה אבל עבור Liquibase.
• /קובץ לוג מחזיר יומני יישומים רגילים.
• / כורתים מאפשר לנו לשאול ולשנות את רמת הרישום של היישום שלנו.
• / מדדים פירוט מדדי היישום שלנו. זה עשוי לכלול מדדים גנריים וגם מדפים מותאמים אישית.
• / פרומתיאוס מחזירה מדדים כמו הקודם, אך מעוצבת לעבודה עם שרת פרומתאוס.
• /משימות מתוזמנות מספק פרטים על כל משימה מתוזמנת ביישום שלנו.
• / מפגשים מפרט הפעלות HTTP בהתחשב בשימוש באביב מושב.
• /לכבות מבצע כיבוי חינני של היישום.
• / אשכול זורק את מידע השרשור של ה- JVM הבסיסי.

3.4. היפר מדיה לנקודות קצה של מפעיל

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

כברירת מחדל, נקודת סיום גילוי זו נגישה דרך ה- /מַפעִיל נקודת סיום.

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

{"_links": {"self": {"href": "// localhost: 8080 / actuator", "templated": false}, "features-arg0": {"href": "// localhost: 8080 / מפעיל / תכונות / {arg0} "," templated ": true}," features ": {" href ":" // localhost: 8080 / actuator / features "," templated ": false}," שעועית ": {" href ":" // localhost: 8080 / actuator / beans "," templated ": false}," caches-cache ": {" href ":" // localhost: 8080 / actuator / caches / {cache} "," תבנית ": true}, // truncated}

כפי שמוצג לעיל, /מַפעִיל נקודת הקצה מדווחת על כל נקודות הקצה הזמינות של המפעיל תחת ה- _ קישורים שדה.

יתר על כן, אם אנו מגדירים נתיב בסיס מותאם אישית לניהול, עלינו להשתמש בנתיב בסיס זה ככתובת ה- URL לגילוי.

למשל, אם הגדרנו את management.endpoints.web.base-path ל / מ"גאז עלינו לשלוח בקשה ל / מ"ג נקודת קצה כדי לראות את רשימת הקישורים.

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

3.5. מדדי בריאות

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

בואו נסתכל על בדיקת בריאות תגובתית פשוטה בהתאמה אישית:

@Component class class DownstreamServiceHealthIndicator מיישם את ReactiveHealthIndicator {@Override public Mono health () {return checkDownstreamServiceHealth (). OnErrorResume (ex -> Mono.just (Health.Builder new (). Down (ex) .build ())); } פרטי מונו checkDownstreamServiceHealth () {// נוכל להשתמש ב- WebClient לבדיקת תקינות להחזיר את ה- Mono.just (חדש Health.Builder (). up (). build ()); }}

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

לכן, בעקבות הדוגמה הקודמת, נוכל לקבץ את כל השירותים במורד הזרם תחת a בְּמוֹרַד הַזֶרֶם-שירותים קטגוריה. קטגוריה זו תהיה בריאה כל עוד כל מקונן שֵׁרוּת היה נגיש.

עיין במאמר שלנו על מדדי בריאות לקבלת מבט מעמיק יותר.

3.6. קבוצות בריאות

החל באביב אתחול 2.2, אנו יכולים לארגן מחווני בריאות בקבוצות ולהחיל את אותה תצורה על כל חברי הקבוצה.

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

management.endpoint.health.group.custom.include = diskSpace, פינג

בדרך זו, ה המותאם אישית הקבוצה מכילה את diskSpace ו פינג מדדי בריאות.

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

{"status": "UP", "groups": ["custom"]}

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

במקרה זה, אם אנו שולחים בקשה אל / מפעיל / בריאות / מנהג, לאחר מכן:

{"status": "UP"}

אנו יכולים להגדיר את הקבוצה כך שתציג פרטים נוספים באמצעות application.properties:

management.endpoint.health.group.custom.show-components = תמיד management.endpoint.health.group.custom.show-details = תמיד

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

{"status": "UP", "components": {"diskSpace": {"status": "UP", "details": {"total": 499963170816, "free": 91300069376, "threshold": 10485760} }, "ping": {"status": "UP"}}}

ניתן גם להציג פרטים אלה רק למשתמשים מורשים:

management.endpoint.health.group.custom.show-components = מתי_מורשה management.endpoint.health.group.custom.show-details = כאשר_מורשים

אנו יכולים גם לבצע מיפוי סטטוסים מותאם אישית.

לדוגמה, במקום תגובת HTTP 200 בסדר, היא יכולה להחזיר קוד מצב 207:

management.endpoint.health.group.custom.status.http-mapping.up = 207

הנה, אנו אומרים ל- Spring Boot להחזיר קוד מצב 207 HTTP אם ה- המותאם אישית סטטוס הקבוצה הוא לְמַעלָה.

3.7. מדדים באביב אתחול 2

ב- Spring Boot 2.0, המדדים הפנימיים הוחלפו בתמיכה במיקרומטרכך שנוכל לצפות לשינויים שבורים. אם היישום שלנו השתמש בשירותי מדדים כגון שירות GaugeService אוֹ שירות דלפק, הם כבר לא יהיו זמינים.

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

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

יתר על כן, נקבל תגובה חדשה לחלוטין מה- / מדדים נקודת סיום:

{"names": ["jvm.gc.pause", "jvm.buffer.memory.used", "jvm.memory.used", "jvm.buffer.count", // ...]}

כפי שאנו רואים, אין מדדים ממשיים כפי שקיבלנו ב- 1.x.

כדי לקבל את הערך האמיתי של מדד ספציפי, נוכל כעת לנווט לערך הרצוי, למשל, /actuator/metrics/jvm.gc.pauseוקבלו תגובה מפורטת:

{"name": "jvm.gc.pause", "מידות": [{"statististic": "Count", "value": 3.0}, {"statistic": "TotalTime", "value": 7.9E7} , {"statistic": "Max", "value": 7.9E7}], "availableTags": [{"tag": "cause", "values": ["סף GC מטא-נתונים", "Failure Failure"]} , {"tag": "action", "values": ["end of GC minor", "end of GC GC"]}}}

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

3.8. התאמה אישית של / מידע נקודת קצה

ה / מידע נקודת הקצה נותרה ללא שינוי. כמו בעבר, אנו יכולים להוסיף פרטי git באמצעות התלות בהתאמה Maven או Gradle:

 pl.project13.maven git-commit-id-plugin 

כְּמוֹ כֵן, נוכל לכלול גם מידע לבנות כולל שם, קבוצה וגרסה באמצעות התוסף Maven או Gradle:

 org.springframework.boot spring-boot-maven-plugin build-info 

3.9. יצירת נקודת קצה מותאמת אישית

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

בואו ניצור נקודת קצה של מפעיל לשאילתה, הפעלה או השבתה של דגלי תכונות ביישום שלנו:

@Component @Endpoint (id = "features") מחלקה ציבורית FeaturesEndpoint {private features features = new ConcurrentHashMap (); @ReadOperation תכונות מפה ציבוריות () {תכונות החזרה; } @ReadOperation תכונה ציבורית תכונה (@ מחרוזת שם מחרוזת) {להחזיר features.get (שם); } @WriteOperation חלל ציבורי configureFeature (@ מחרוזת שם מחרוזת, תכונה תכונה) {features.put (שם, תכונה); } @DeleteOperation בטל פומבי deleteFeature (@ מחרוזת שם שם) {features.remove (שם); } מחלקה סטטית ציבורית תכונה {מופעלת בוליאנית פרטית; // [...] גטרים וקובעים}}

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

הדרך של נקודת הסיום שלנו נקבעת על ידי תְעוּדַת זֶהוּת פרמטר של @Endpoint. במקרה שלנו, זה ינתב בקשות אל / מפעיל / תכונות.

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

• @ReadOperation: זה ימפה ל- HTTP לקבל.
• @WriteOperation: זה ימפה ל- HTTP הודעה.
• @DeleteOperation: זה ימפה ל- HTTP לִמְחוֹק.

כאשר אנו מריצים את היישום עם נקודת הסיום הקודמת ביישום שלנו, Spring Boot ירשום אותו.

דרך מהירה לאמת זאת היא לבדוק את היומנים:

[...]. WebFluxEndpointHandlerMapping: ממופה "{[/ actuator / features / {name}], שיטות = [GET], מייצר = [application / vnd.spring-boot.actuator.v2 + json || application / json] } "[...]. WebFluxEndpointHandlerMapping: ממופה" יישום / json] "[...]. WebFluxEndpointHandlerMapping: ממופה" {[/ actuator / features / {name}], שיטות = [POST], צורכת = [יישום / vnd.spring-boot.actuator.v2 + json || application / json]} "[...]. WebFluxEndpointHandlerMapping: ממופה" {[/ actuator / features / {name}], שיטות = [DELETE]} "[. ..]

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

כמו כן, יש לנו כמה שיקולים חשובים שיש לזכור עם גישה חדשה זו:

• אין תלות ב- MVC.
• כל המטא נתונים שנמצאו כשיטות לפני כן (רגיש, מופעל ...) לא קיים יותר. אנו יכולים, עם זאת, להפעיל או להשבית את נקודת הקצה באמצעות @Endpoint (id = "features", enableByDefault = false).
• שלא כמו ב- 1.x, כבר אין צורך להרחיב ממשק נתון.
• בניגוד למודל הישן של קריאה / כתיבה, כעת אנו יכולים להגדיר לִמְחוֹק פעולות באמצעות @DeleteOperation.

3.10. הרחבת נקודות הקצה הקיימות

בואו נדמיין שאנחנו רוצים לוודא שמופע הייצור של היישום שלנו לעולם אינו סנאפצ'וט גִרְסָה.

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

אנו יכולים בקלות להרחיב את ההתנהגות של נקודת קצה מוגדרת מראש באמצעות ה- @EndpointExtension ביאורים, או ההתמחויות הקונקרטיות יותר שלה @EndpointWebExtension אוֹ @EndpointJmxExtension:

@Component @EndpointWebExtension (נקודת קצה = InfoEndpoint.class) מחלקה ציבורית InfoWebEndpointExtension {נציג InfoEndpoint פרטי; // קונסטרוקטור סטנדרטי @ReadOperation מידע WebEndpointResponse ציבורי () {Map info = this.delegate.info (); מצב שלם = getStatus (מידע); להחזיר WebEndpointResponse חדש (מידע, סטטוס); } שלם פרטי getStatus (מידע על מפה) {// להחזיר 5xx אם זו תמונת מצב להחזיר 200; }}

3.11. הפעל את כל נקודות הקצה

על מנת לגשת לנקודות הקצה של המפעיל באמצעות HTTP, עלינו לאפשר וגם לחשוף אותם.

כברירת מחדל, כל נקודות הקצה אך /לכבות מופעלים. רק ה /בְּרִיאוּת ו / מידע נקודות קצה נחשפות כברירת מחדל.

עלינו להוסיף את התצורה הבאה כדי לחשוף את כל נקודות הקצה:

management.endpoints.web.exposure.include = *

כדי לאפשר במפורש נקודת סיום ספציפית (למשל, /לכבות), אנו משתמשים:

management.endpoint.shutdown.enabled = נכון

כדי לחשוף את כל נקודות הקצה המופעלות למעט אחת (למשל, / כורתים), אנו משתמשים:

management.endpoints.web.exposure.include = * management.endpoints.web.exposure.exclude = חוטבי עצים

4. מגף קפיץ 1.x מפעיל

ב- 1.x, Actuator עוקב אחר מודל קריאה / כתיבה, כלומר אנו יכולים לקרוא ממנו או לכתוב אליו.

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

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

4.1. נקודות קצה

ב- 1.x, מפעיל מביא מודל אבטחה משלו. הוא מנצל את קונסטרוקציות Spring Security אך צריך להיות מוגדר באופן עצמאי משאר היישומים.

כמו כן, מרבית נקודות הקצה רגישות - כלומר אינן ציבוריות לחלוטין, או שרוב המידע יושמט - בעוד שקומץ אינן, למשל, / מידע.

להלן כמה מנקודות הקצה הנפוצות ביותר ש- Boot מספק מחוץ לקופסה:

• /בְּרִיאוּת מציג מידע על בריאות היישומים (פשוט סטָטוּס כאשר ניגשים אליו דרך חיבור לא מאומת או פרטי הודעות מלאים בעת אימות); זה כבר לא ברגישות כברירת מחדל.
• / מידע מציג מידע יישום שרירותי; זה כבר לא ברגישות כברירת מחדל.
• / מדדים מציג מידע על מדדים עבור היישום הנוכחי; זה רגיש כברירת מחדל.
• /זֵכֶר מציג מידע מעקב (כברירת מחדל בקשות ה- HTTP האחרונות).

אנו יכולים למצוא את הרשימה המלאה של נקודות הקצה הקיימות במסמכים הרשמיים.

4.2. קביעת תצורה של נקודות קצה קיימות

אנו יכולים להתאים אישית כל נקודת קצה עם מאפיינים באמצעות הפורמט נקודות קצה. [שם נקודת קצה]. [מאפיין להתאמה אישית].

שלושה נכסים זמינים:

• תְעוּדַת זֶהוּת: באמצעותו ניתן לגשת לנקודת קצה זו באמצעות HTTP
• מופעלת: אם נכון, ניתן לגשת אליו; אחרת לא
• רָגִישׁ: אם נכון, צריך את ההרשאה כדי להציג מידע חיוני באמצעות HTTP

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

endpoints.beans.id = שעועית קצה endpoints.beans.sensitive = נקודות קצה שגויות. שעועית. מופעלת = נכון

4.3. /בְּרִיאוּת נקודת קצה

ה /בְּרִיאוּת נקודת קצה משמשת לבדיקת תקינותה או מצבה של היישום הרץ.

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

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

{"status": "UP"} 

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

מידע שהוחזר על ידי אינדיקטור בריאות הוא רגיש באופיו, אך אנו יכולים להגדיר endpoints.health.sensitive = false לחשוף מידע מפורט יותר כמו שטח דיסק, קישוריות מתווך להעברת הודעות, בדיקות מותאמות אישית ועוד.

שים לב שהדבר עובד רק בגרסאות Spring Boot מתחת ל 1.5.0. עבור גרסאות 1.5.0 ואילך, עלינו להשבית את האבטחה על ידי הגדרה management.security.enabled = שקר לגישה לא מורשית.

יכולנו גם ליישם את מחוון הבריאות המותאם אישית שלנו, שיכולים לאסוף כל סוג של נתוני בריאות מותאמים אישית הספציפיים ליישום ולחשוף אותם באופן אוטומטי באמצעות /בְּרִיאוּת נקודת סיום:

@Component ("myHealthCheck") מחלקה ציבורית HealthCheck מיישמת את HealthIndicator {@Override health health health () {int errorCode = check (); // לבצע בדיקת בריאות ספציפית אם (errorCode! = 0) {return Health.down () .withDetail ("קוד שגיאה", errorcode) .build (); } להחזיר את Health.up (). build (); } בדיקת ציבורי ציבורי () {// ההיגיון שלנו לבדיקת החזר בריאות 0; }} 

כך ייראה הפלט:

{"status": "DOWN", "myHealthCheck": {"status": "DOWN", "Code Error": 1}, "diskSpace": {"status": "UP", "free": 209047318528, " סף ": 10485760}}

4.4. / מידע נקודת קצה

אנו יכולים גם להתאים אישית את הנתונים המוצגים על ידי / מידע נקודת סיום:

info.app.name = יישום לדוגמא באביב info.app.description = זהו יישום אתחול האביב הראשון שלי info.app.version = 1.0.0

ופלט המדגם:

{"app": {"version": "1.0.0", "description": "זהו יישום האתחול הראשון שלי באביב", "name": "יישום לדוגמא באביב"}}

4.5. / מדדים נקודת קצה

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

כך נראית הפלט של נקודת קצה זו מחוץ לקופסה:

{"mem": 193024, "mem.free": 87693, "processors": 4, "instance.uptime": 305027, "uptime": 307077, "systemload.average": 0.11, "heap.committed": 193024 , "heap.init": 124928, "heap.used": 105330, "heap": 1764352, "threads.peak": 22, "threads.daemon": 19, "threads": 22, "classes": 5819 , "classes.loaded": 5819, "classes.unloaded": 0, "gc.ps_scavenge.count": 7, "gc.ps_scavenge.time": 54, "gc.ps_marksweep.count": 1, "gc. ps_marksweep.time ": 44," httpsessions.max ": -1," httpsessions.active ": 0," counter.status.200.root ": 1," gauge.response.root ": 37.0} 

על מנת לאסוף מדדים מותאמים אישית, יש לנו תמיכה במדידים (תמונות תמונה חד-ערכיות של נתונים) ובמונים, כלומר מדדי הגדלה / צמצום.

בואו נשתמש בערכים המותאמים אישית שלנו / מדדים נקודת סיום.

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

@Service בכיתה ציבורית LoginServiceImpl {CounterService פרטית סופית; LoginServiceImpl ציבורי (CounterService counterService) {this.counterService = counterService; } כניסה בוליאנית ציבורית (מחרוזת userName, char [] סיסמא) {הצלחה בוליאנית; אם (userName.equals ("admin") && "סוד" .toCharArray (). שווה (סיסמה)) {counterService.increment ("counter.login.success"); הצלחה = אמיתית; } אחר {counterService.increment ("counter.login.failure"); הצלחה = שקר; } להחזיר הצלחה; }}

כך עשויה להיראות הפלט:

{... "counter.login.success": 105, "counter.login.failure": 12, ...} 

שים לב שניסיונות התחברות ואירועים אחרים הקשורים לאבטחה זמינים מהקופסה ב- Actuator כאירועי ביקורת.

4.6. יצירת נקודת קצה חדשה

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

ראשית, עלינו לקבל את נקודת הקצה החדשה ליישם את ה- נקודת קצה מִמְשָׁק:

המחלקה הציבורית @Component CustomEndpoint מיישמת את נקודת הקצה {@ עקוף מחרוזת ציבורית getId () {להחזיר "customEndpoint"; } @Override בוליאני ציבורי isEnabled () {return true; } @Override בוליאני ציבורי isSensitive () {return true; } @Override Public List להפעיל () {// לוגיקה מותאמת אישית לבניית הודעות רשימת הפלט = ArrayList חדש (); messages.add ("זו הודעה 1"); messages.add ("זו הודעה 2"); להחזיר הודעות; }}

על מנת לגשת לנקודת הקצה החדשה הזו, שלה תְעוּדַת זֶהוּת משמש למיפוי זה. במילים אחרות נוכל לממש את זה להכות / customEndpoint.

תְפוּקָה:

["זו הודעה 1", "זו הודעה 2"]

4.7. התאמה אישית נוספת

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

כמו כן, כפי שכבר הזכרנו, ב- 1.x. Actuator מגדיר את מודל האבטחה שלו בהתבסס על Spring Security אך ללא תלות בשאר היישומים.

לפיכך, אנו יכולים לשנות את ניהול.כתובת מאפיין להגבלת המקומות אליהם ניתן לגשת לנקודות הקצה דרך הרשת:

#port המשמש לחשיפת ניהול מפעיל. port = 8081 #CIDR מותר לפגוע בניהול מפעיל. כתובת = 127.0.0.1 # האם יש להפעיל או להשבית אבטחה לחלוטין. management.security.enabled = false

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

אם היישום משתמש באבטחת אביב, אנו יכולים לאבטח נקודות קצה אלה על ידי הגדרת מאפייני האבטחה המוגדרים כברירת מחדל (שם משתמש, סיסמה ותפקיד) application.properties קוֹבֶץ:

security.user.name = מנהל security.user.password = management secret.security.role = SUPERUSER

5. מסקנה

במאמר זה דיברנו על מפעיל אתחול האביב. התחלנו בהגדרת המשמעות של Actuator ומה זה עושה עבורנו.

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

ואז דנו במפעיל בגרסת Spring Boot 1 הקודמת.

לבסוף, הדגמנו כיצד להתאים ולהפעיל את המפעיל.

כמו תמיד, ניתן למצוא את הקוד המשמש במאמר זה ב- GitHub הן עבור Spring Boot 2.x והן עבור Spring Boot 1.x.