streamalism.org

1. Áttekintés

Ebben a cikkben bemutatjuk a Spring Boot Actuator-t. Először áttekintjük az alapokat, majd részletesen megvitatjuk, mi áll rendelkezésre a Spring Boot 2.x vs 1.x verzióban.

Megtanuljuk, hogyan kell használni, konfigurálni és kibővíteni ezt a megfigyelő eszközt a Spring Boot 2.x és a WebFlux programokban, kihasználva a reaktív programozási modellt. Majd megbeszéljük, hogyan tehetjük ugyanezt a Boot 1.x használatával.

A Spring Boot Actuator 2014 áprilisától kapható, az első Spring Boot kiadással együtt.

A Spring Boot 2 megjelenésével az Actuator átalakításra került, és új, izgalmas végpontok kerültek hozzá.

Ezt az útmutatót három fő részre osztottuk:

• Mi az a működtető?
• Spring Boot 2.x működtető
• Rugós csomagtartó 1.x működtető

2. Mi az a működtető?

Lényegében az Actuator gyártásra kész funkciókat hoz az alkalmazásunkba.

Alkalmazásunk figyelése, mutatók gyűjtése, a forgalom vagy az adatbázisunk állapotának megértése elenyészővé válik ezzel a függőséggel.

Ennek a könyvtárnak az a fő előnye, hogy gyártási szintű eszközöket kaphatunk anélkül, hogy ezeket a funkciókat valóban magunknak kellene megvalósítanunk.

A működtető főleg megszokta tegye ki a futó alkalmazás operatív információit - állapot, mutatók, információk, dump, env stb. HTTP végpontokat vagy JMX babokat használ, hogy lehetővé tegyük velünk a kölcsönhatásokat.

Miután ez a függőség az osztályúttól függ, több végpont is elérhető számunkra a dobozból. Csakúgy, mint a legtöbb Spring modul esetében, itt is sokféleképpen konfigurálhatjuk vagy bővíthetjük.

2.1. Elkezdeni

A Spring Boot Actuator engedélyezéséhez csak hozzá kell adnunk a rugós-csomagtartó működtető függőség a csomagkezelőnktől.

Mavenben:

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

Vegye figyelembe, hogy ez a Boot verziótól függetlenül érvényes marad, mivel a verziókat a Spring Boot Material of Materials (BOM) tartalmazza.

3. Rugós csomagtartó 2.x működtető

A 2.x verzióban az Actuator megtartja alapvető szándékát, de leegyszerűsíti modelljét, kibővíti képességeit és jobb alapértelmezéseket tartalmaz.

Először ez a verzió válik technológia-agnosztikussá. A biztonsági modellt egyszerűsíti azáltal, hogy egyesíti azt az alkalmazással.

A különféle változások között fontos szem előtt tartani, hogy néhányuk törik. Ez magában foglalja a HTTP kéréseket és válaszokat, valamint a Java API-kat.

Végül a legújabb verzió már támogatja a CRUD modellt, szemben a régi olvasási / írási modellel.

3.1. Technológiai támogatás

A második nagyobb verziójával az Actuator már technológia-agnosztikus, míg az 1.x-ben az MVC-hez, tehát a Servlet API-hoz volt kötve.

A 2.x verzióban az Actuator plug-inként és bővíthetőként definiálja modelljét, anélkül, hogy ehhez az MVC-re támaszkodna.

Ezért ezzel az új modellel képesek vagyunk kihasználni az MVC, valamint a WebFlux, mint alapul szolgáló webes technológia előnyeit.

Sőt, a megfelelő technológiák bevezetésével a megfelelő adaptereket lehetne beépíteni.

Végül a JMX továbbra is támogatott a végpontok további kód nélkül történő feltárásához.

3.2. Fontos változások

A korábbi verzióktól eltérően Az aktuátor a legtöbb végpontot le van tiltva.

Így az egyetlen alapértelmezés szerint elérhető /Egészség és / info.

Ha mindegyiket engedélyezni szeretnénk, beállíthatnánk management.endpoints.web.exposure.include = *. Alternatív megoldásként felsorolhatjuk azokat a végpontokat, amelyeket engedélyezni kell.

Az Actuator most megosztja a biztonsági konfigurációt a szokásos App biztonsági szabályokkal, így a biztonsági modell drámai módon leegyszerűsödik.

Ezért az Actuator biztonsági szabályainak módosítása érdekében csak hozzáadhatunk egy bejegyzést a következőhöz: / működtető / **:

@Bean public SecurityWebFilterChain securityWebFilterChain (ServerHttpSecurity http) {return http.authorizeExchange () .pathMatchers ("/ actuator / **"). AllowAll () .anyExchange (). Hitelesített () .és (). Build (); }

További részletek a vadonatúj Actuator hivatalos dokumentumokról találhatók.

Is, alapértelmezés szerint az összes Actuator végpont most a / működtető pálya.

Az előző verzióhoz hasonlóan ezt az utat is módosíthatjuk az új tulajdonság használatával management.endpoints.web.base-path.

3.3. Előre definiált végpontok

Vessünk egy pillantást néhány elérhető végpontra, amelyek többsége már az 1.x-ben is elérhető volt.

Is, néhány végpontot felvettek, néhányat eltávolítottak, és néhányat átalakítottak:

• / auditevents felsorolja a biztonsági ellenőrzéssel kapcsolatos eseményeket, például a felhasználói bejelentkezést / kijelentkezést. Ezenkívül szűrhetünk tőke vagy típus szerint más mezők között.
• / bab az összes rendelkezésre álló babot visszaadja BeanFactory. nem úgy mint / auditevents, nem támogatja a szűrést.
• /körülmények, korábban /autoconfig, jelentést készít az autokonfiguráció körüli állapotokról.
• / configprops lehetővé teszi számunkra, hogy mindent megszerezzünk @ConfigurationProperties bab.
• / env visszaadja az aktuális környezeti tulajdonságokat. Ezenkívül lekérhetünk egyetlen tulajdonságot.
• / repülõút részleteket tartalmaz a Flyway adatbázis-migrációinkról.
• /Egészség összefoglalja alkalmazásunk egészségi állapotát.
• / kupac felhalmozást hoz létre és visszaad az alkalmazásunk által használt JVM-ből.
• / info általános információkat ad vissza. Lehet, hogy egyéni adatok, összeállítási információk vagy a legújabb elkötelezettség részletei.
• / liquibase úgy viselkedik / repülõút hanem a Liquibase számára.
• /log fájl visszatér a szokásos alkalmazásnaplókba.
• / fakitermelők lehetővé teszi számunkra, hogy lekérdezzük és módosítsuk alkalmazásunk naplózási szintjét.
• / metrikák részletesen metrikák az alkalmazás. Ez tartalmazhat általános és egyedi mutatókat is.
• /Prométheusz olyan metrikákat ad vissza, mint az előző, de a Prometheus szerverrel való együttműködésre formázva.
• /ütemezett feladatok részleteket nyújt alkalmazásunk minden ütemezett feladatáról.
• / munkamenetek felsorolja a HTTP munkameneteket, mivel a tavaszi munkamenetet használjuk.
• /Leállitás kecses leállítást hajt végre az alkalmazásban.
• / threaddump kiírja az alapul szolgáló JVM szálinformációit.

3.4. Hipermédia az aktuátor végpontjaihoz

A Spring Boot hozzáad egy felfedezési végpontot, amely visszaküldi az összes elérhető működtető végpont linkjét. Ez megkönnyíti a működtető végpontok és a hozzájuk tartozó URL-ek felfedezését.

Alapértelmezés szerint ez a felfedezési végpont a / működtető végpont.

Ezért, ha a KAP kérelmet erre az URL-re, akkor a működtető linkjeit adja vissza a különböző végpontokhoz:

{"_links": {"self": {"href": "// localhost: 8080 / actuator", "templated": false}, "features-arg0": {"href": "// localhost: 8080 / aktor / features / {arg0} "," templated ": true}," features ": {" href ":" // localhost: 8080 / actuator / features "," templated ": false}," bab ": {" href ":" // localhost: 8080 / actuator / beans "," templated ": false}," cache-cache ": {" href ":" // localhost: 8080 / actuator / cache / {cache} "," sablon ": true}, // csonka}

Amint fentebb látható, a / működtető végpont jelenti az összes rendelkezésre álló működtető végpontot a _linkek terület.

Sőt, ha konfigurálunk egy egyéni felügyeleti alapútvonalat, akkor ezt az alapútvonalat kell használnunk a felfedezés URL-jeként.

Például, ha beállítjuk a management.endpoints.web.base-path nak nek / mgmt, akkor kérelmet kell küldenünk a / mgmt végpont a hivatkozások listájának megtekintéséhez.

Nagyon érdekes, amikor a menedzsment bázis útvonala a /, a felfedezési végpont le van tiltva, hogy megakadályozza az ütközést más leképezésekkel.

3.5. Egészségügyi mutatók

Az előző verzióhoz hasonlóan könnyen hozzáadhatunk egyedi mutatókat is. Szemben más API-kkal, az egyedi egészségügyi végpontok létrehozásának absztrakciói változatlanok maradnak. Azonban, egy új felület, ReactiveHealthIndicator, hozzáadva a reaktív állapotfelmérések végrehajtásához.

Vessünk egy pillantást egy egyszerű, egyedi reaktív állapotfelmérésre:

@Component public class DownstreamServiceHealthIndicator implementálja a ReactiveHealthIndicator {@Orride public Mono health () {return checkDownstreamServiceHealth (). OnErrorResume (ex -> Mono.just (new Health.Builder (). Down (ex) .build ())); } privát Mono checkDownstreamServiceHealth () {// a WebClient segítségével ellenőrizhetjük az állapotot reaktív módon visszaadva a Mono.just (új Health.Builder (). up (). build ()); }}

Az egészségügyi mutatók praktikus jellemzője, hogy összesíthetjük őket a hierarchia részeként.

Tehát az előző példát követve az összes downstream szolgáltatást a lefelé-szolgáltatások kategória. Ez a kategória egészséges lenne, amíg minden fészkel szolgáltatás elérhető volt.

Tekintse meg cikkünket az egészségügyi mutatókról a mélyebb áttekintés érdekében.

3.6. Egészségügyi csoportok

A Spring Boot 2.2-től kezdve csoportokba rendezhetjük az állapotjelzőket, és ugyanazt a konfigurációt alkalmazhatjuk a csoport összes tagjára.

Például létrehozhatunk egy nevű egészségügyi csoportot egyedi hozzáadva ezt a mi alkalmazás.tulajdonságok:

management.endpoint.health.group.custom.include = diskSpace, ping

Így a egyedi csoport tartalmazza a lemez terület és ping egészségügyi mutatók.

Most ha hívjuk a / működtető / egészség végpont, ez elmondaná nekünk az új egészségügyi csoportot a JSON válaszában:

{"status": "FEL", "csoportok": ["egyedi"]}

Egészségügyi csoportokkal néhány egészségügyi mutató összesített eredményeit láthatjuk.

Ebben az esetben, ha kérést küldünk a címre / működtető / egészség / szokás, azután:

{"status": "FEL"}

Konfigurálhatjuk a csoportot úgy, hogy a részleteken keresztül jelenítsen meg alkalmazás.tulajdonságok:

management.endpoint.health.group.custom.show-components = mindig management.endpoint.health.group.custom.show-details = always

Most, ha ugyanazt a kérést küldjük a címre / működtető / egészség / szokás, további részleteket látunk:

{"status": "UP", "components": {"diskSpace": {"status": "UP", "részletek": {"total": 499963170816, "free": 91300069376, "küszöb ": 10485760} }, "ping": {"status": "FEL"}}}

Ezeket a részleteket csak az engedélyezett felhasználók számára lehet megjeleníteni:

management.endpoint.health.group.custom.show-components = when_authorized management.endpoint.health.group.custom.show-details = when_authorized

Rendelkezhetünk egyedi állapot-feltérképezéssel is.

Például a HTTP 200 OK válasz helyett 207 állapotkódot adhat vissza:

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

Itt azt mondjuk a Spring Boot-nak, hogy adja vissza a 207 HTTP állapotkódot, ha a egyedi a csoport állapota FEL.

3.7. Mutatók a tavaszi csomagtartóban 2

A Spring Boot 2.0-ban a házon belüli mutatókat lecserélték Mikrométer támogatásra, így törő változásokra számíthatunk. Ha alkalmazásunk olyan metrikus szolgáltatásokat használt, mint pl GaugeService vagy CounterService, már nem lesznek elérhetők.

Ehelyett várhatóan közvetlenül a Mikrométerrel lépünk kapcsolatba. A Spring Boot 2.0-ban kapunk egy típusú babot MeterRegistry nekünk konfigurálva.

Ezenkívül a mikrométer mostantól része az aktuátor függőségeinek, ezért jónak kell lennünk, ha mindaddig megyünk, amíg az aktuátor függőség az osztályúton van.

Sőt, egy teljesen új választ kapunk a / metrikák végpont:

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

Mint láthatjuk, nincsenek tényleges mutatók, mivel az 1.x-be kerültünk.

Egy adott mutató tényleges értékének megszerzéséhez most navigálhatunk a kívánt mutatóra, pl. /actuator/metrics/jvm.gc.pause, és kapjon részletes választ:

{"név": "jvm.gc.pause", "mérések": [{"statistic": "Count", "value": 3.0}, {"statistic": "TotalTime", "value": 7.9E7} , {"statistic": "Max", "value": 7.9E7}], "availableTags": [{"tag": "oka", "értékek": ["Metadata GC Threshold", "Allocation Failure"]} , {"tag": "action", "values": ["kisebb GC vége", "fő GC vége"]}]}

Most a mutatók sokkal alaposabbak, nemcsak a különböző értékeket, hanem néhány kapcsolódó metaadatot is tartalmaznak.

3.8. A. Testreszabása / info Végpont

A / info végpont változatlan marad. A korábbiakhoz hasonlóan hozzáadhatjuk a git részleteit a megfelelő Maven vagy Gradle függőség használatával:

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

Hasonlóképpen, A Maven vagy a Gradle plugin segítségével beépíthetjük a build nevét is, beleértve a nevet, a csoportot és a verziót:

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

3.9. Egyéni végpont létrehozása

Amint arra korábban rámutattunk, egyedi végpontokat hozhatunk létre. A Spring Boot 2 azonban átalakította ennek elérésének módját, hogy támogassa az új technológiai-agnosztikai paradigmát.

Hozzunk létre egy Actuator végpontot a szolgáltatásjelzők lekérdezéséhez, engedélyezéséhez és letiltásához az alkalmazásunkban:

@Component @Endpoint (id = "features") public class FeaturesEndpoint {private Map features = new ConcurrentHashMap (); @ReadOperation public Map features () {return features; } @ReadOperation public Feature feature (@Selector String name) {return features.get (name); } @WriteOperation public void configureFeature (@Selector String name, Feature feature) {features.put (name, feature); } @DeleteOperation public void deleteFeature (@Selector String name) {features.remove (name); } public static class Feature {private Boolean engedélyezve; // [...] getterek és beállítók}}

A végpont megszerzéséhez babra van szükségünk. Példánkban használjuk @Összetevő ezért. Díszítenünk kell ezt a babot is @Endpoint.

Végpontunk útját a id paramétere @Endpoint. Esetünkben továbbítja a kérelmeket ide / működtető / jellemzők.

Miután elkészült, elkezdhetjük meghatározni a műveleteket a következők használatával:

• @ReadOperation: HTTP-re fog térképezni KAP.
• @WriteOperation: HTTP-re fog térképezni POST.
• @DeleteOperation: HTTP-re fog térképezni TÖRÖL.

Amikor az alkalmazást az előző végponttal futtatjuk, a Spring Boot regisztrálja.

Ennek gyors ellenőrzésével ellenőrizheti a naplókat:

[...]. WebFluxEndpointHandlerMapping: leképezve "{[/ actuator / features / {name}], Methods = [GET], = = application / vnd.spring-boot.actuator.v2 + json || application / json] } "[...]. WebFluxEndpointHandlerMapping: leképezve" application / json] "[...]. WebFluxEndpointHandlerMapping: leképezve" {[/ actuator / features / {name}], method = [POST], fogyaszt = [alkalmazás / vnd.spring-boot.actuator.v2 + json || application / json]} "[...]. WebFluxEndpointHandlerMapping: leképezve" {[/ actuator / features / {name}], method = [DELETE]} ". ..]

Az előző naplókban láthatjuk, hogy a WebFlux miként teszi ki az új végpontunkat. Ha áttérünk az MVC-re, akkor egyszerűen átruházza ezt a technológiát anélkül, hogy bármilyen kódot meg kellene változtatnia.

Néhány új szempontot is szem előtt kell tartanunk ezzel az új megközelítéssel:

• Az MVC-től nincsenek függőségek.
• Az összes metaadat, amely módszerként szerepel korábban (érzékeny, engedélyezett…) már nem létezik. Engedélyezhetjük vagy letilthatjuk a végpontot a használatával @Endpoint (id = “features”, enableByDefault = false).
• Az 1.x-től eltérően már nincs szükség egy adott felület kiterjesztésére.
• A régi olvasási / írási modellel ellentétben most már meghatározhatjuk TÖRÖL műveletek segítségével @DeleteOperation.

3.10. Meglévő végpontok kiterjesztése

Képzeljük el, hogy meg akarunk győződni arról, hogy alkalmazásunk gyártási példánya soha nem a PILLANATKÉP változat.

Úgy döntünk, hogy ezt az információt visszaadó Actuator végpont HTTP-állapotkódjának megváltoztatásával, azaz / info. Ha az alkalmazásunk véletlenül a PILLANATKÉP, mást kapnánk HTTP állapotkód.

Könnyen kiterjeszthetjük egy előre definiált végpont viselkedését a @EndpointExtension annotációk, vagy konkrétabb szakterületei @EndpointWebExtension vagy @EndpointJmxExtension:

@Component @EndpointWebExtension (endpoint = InfoEndpoint.class) public class InfoWebEndpointExtension {private InfoEndpoint delegate; // standard konstruktor @ReadOperation public WebEndpointResponse info () {Térképinformáció = this.delegate.info (); Egész állapot = getStatus (info); return new WebEndpointResponse (info, status); } private Integer getStatus (Map info) {// return 5xx, ha ez egy pillanatfelvétel 200; }}

3.11. Engedélyezze az összes végpontot

Ahhoz, hogy a működtető végpontjaihoz HTTP-n keresztül férjünk hozzá, engedélyeznünk és exponálnunk kell őket.

Alapértelmezés szerint az összes végpont, kivéve /Leállitás engedélyezve vannak. Csak a /Egészség és / info a végpontok alapértelmezés szerint ki vannak téve.

A következő konfigurációt hozzá kell adnunk az összes végpont leleplezéséhez:

management.endpoints.web.exposure.include = *

Egy adott végpont kifejezett engedélyezése (pl. /Leállitás), használunk:

management.endpoint.shutdown.enabled = true

Az összes engedélyezett végpont leleplezése egy kivételével (pl. / fakitermelők), használunk:

management.endpoints.web.exposure.include = * management.endpoints.web.exposure.exclude = naplók

4. Rugós csomagtartó 1.x működtető

Az 1.x-ben az Actuator olvasási / írási modellt követ, ami azt jelenti, hogy akár olvashatunk belőle, akár írhatunk hozzá.

Például lekérhetjük a mutatókat vagy az alkalmazás állapotát. Alternatív megoldásként kecsesen leállíthatjuk az alkalmazásunkat, vagy megváltoztathatjuk a naplózási konfigurációt.

A működéshez az Actuator megköveteli a Spring MVC-től, hogy HTTP-n keresztül tegye ki végpontjait. Más technológia nem támogatott.

4.1. Végpontok

Az 1.x-ben az Actuator hozza a saját biztonsági modelljét. Kihasználja a Spring Security konstrukcióit, de az alkalmazás többi részétől függetlenül kell konfigurálni.

Ezenkívül a legtöbb végpont érzékeny - vagyis nem teljesen nyilvános, vagy a legtöbb információt kihagyják -, míg egy maroknyi nem, pl. / info.

Íme néhány a Boot által a dobozon kívül biztosított leggyakoribb végpont:

• /Egészség mutatja az alkalmazás egészségügyi adatait (egy egyszerű állapot ha nem hitelesített kapcsolaton keresztül érik el, vagy hitelesítéskor az üzenet teljes adatai); alapértelmezés szerint nem érzékeny.
• / info tetszőleges alkalmazásinformációkat jelenít meg; alapértelmezés szerint nem érzékeny.
• / metrikák megmutatja az aktuális alkalmazás metrikájának adatait; alapértelmezés szerint érzékeny.
• /nyom megjeleníti a nyomkövetési információkat (alapértelmezés szerint az utolsó néhány HTTP kérés).

A meglévő végpontok teljes listáját megtalálhatjuk a hivatalos dokumentumokon.

4.2. Meglévő végpontok konfigurálása

Minden végpontot testreszabhatunk tulajdonságokkal a formátum használatával végpontok. [végpont neve]. [testreszabható tulajdonság].

Három tulajdonság áll rendelkezésre:

• id: amellyel ez a végpont HTTP-n keresztül érhető el
• engedélyezve: ha igaz, akkor hozzáférhető; különben nem
• érzékeny: ha igaz, akkor engedélyre van szükség a döntő információk HTTP-n keresztüli megjelenítéséhez

Például a következő tulajdonságok hozzáadásával testre szabhatja a /bab végpont:

endpoints.beans.id = springbeans endpoints.beans.sensitive = hamis végpontok.beans.enabled = true

4.3. /Egészség Végpont

A /Egészség végpont a futó alkalmazás állapotának vagy állapotának ellenőrzésére szolgál.

Általában figyelő szoftver gyakorolja, hogy figyelmeztessen minket, ha a futó példány más okok miatt leromlik vagy egészségtelenné válik, például a DB-vel való kapcsolódási problémák, a lemezterület hiánya stb.

Alapértelmezés szerint az illetéktelen felhasználók csak akkor láthatják az állapotadatokat, ha HTTP-n keresztül férnek hozzá:

{"status": "FEL"} 

Ezeket az egészségügyi információkat az összes, a HealthIndicator az alkalmazás kontextusában konfigurált felület.

Néhány információt visszaadott HealthIndicator érzékeny természetű, de konfigurálhatjuk végpontok.egészség.érzékeny = hamis részletesebb információk, például a lemezterület, az üzenetküldő közvetítői kapcsolat, az egyéni ellenőrzések és egyebek bemutatása.

Vegye figyelembe, hogy ez csak a Spring Boot 1.5.0 alatti verzióinál működik. 1.5.0 és újabb verzióknál a beállítást is ki kell kapcsolnunk a biztonságról management.security.enabled = hamis illetéktelen hozzáférésért.

Mi is tehetnénk hajtsa végre saját egyedi egészségügyi mutatónkat, amely bármilyen típusú egyedi, az alkalmazásra jellemző egyedi egészségügyi adatot képes összegyűjteni, és az /Egészség végpont:

@Component ("myHealthCheck") public HealthCheck osztály valósítja meg HealthIndicator {@Orride public health health () {int errorCode = check (); // végezzen bizonyos speciális állapotfelmérést, ha (errorCode! = 0) {return Health.down () .withDetail ("Hibakód", errorCode) .build (); } return Health.up (). build (); } public int check () {// Logikánk az állapot ellenőrzésére 0; }} 

A kimenet így nézne ki:

{"status": "DOWN", "myHealthCheck": {"status": "DOWN", "Hibakód": 1}, "diskSpace": {"status": "UP", "free": 209047318528, " küszöb ": 10485760}}

4.4. / info Végpont

Testreszabhatjuk a / info végpont:

info.app.name = Tavaszi minta alkalmazás info.app.description = Ez az első tavaszi indító alkalmazásom info.app.version = 1.0.0

És a minta kimenete:

{"app": {"version": "1.0.0", "description": "Ez az első tavaszi indító alkalmazásom", "name": "Spring Sample Application"}}

4.5. / metrikák Végpont

A metrikák végpontja információkat közöl az operációs rendszerről és a JVM-ről, valamint alkalmazásszintű mutatókat. Miután engedélyezte, olyan információkat kapunk, mint a memória, a halom, a processzorok, a szálak, a betöltött osztályok, az osztályok és a szálkészletek, valamint néhány HTTP-mutatót is.

Így néz ki a végpont kimenete a dobozból:

{"mem": 193024, "mem.free": 87693, "processzorok": 4, "instance.uptime": 305027, "uptime": 307077, "systemload.avigation": 0.11, "heap.committed": 193024 , "heap.init": 124928, "heap.used": 105330, "halom": 1764352, "threads.peak": 22, "threads.daemon": 19, "threads": 22, "class": 5819 , "class.loaded": 5819, "class.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} 

Az egyéni mutatók összegyűjtése érdekében támogatást nyújtunk a mérőkhöz (az adatok egyértékű pillanatképei) és a számlálókhoz, vagyis a növekvő / csökkentő mutatókhoz.

Vezessük be saját egyéni mutatóinkat a / metrikák végpont.

A bejelentkezési folyamatot testre szabjuk egy sikeres és sikertelen bejelentkezési kísérlet rögzítésére:

@Service public class LoginServiceImpl {private final CounterService counterService; public LoginServiceImpl (CounterService counterService) {this.counterService = ellenszolgáltatás; } nyilvános logikai bejelentkezés (String felhasználónév, char [] jelszó) {logikai siker; if (felhasználónév.egyenlő ("admin") && "titkos" .toCharArray (). egyenlő (jelszó)) {counterService.increment ("counter.login.success"); siker = igaz; } else {counterService.increment ("counter.login.failure"); siker = hamis; } visszatérési siker; }}

Így nézhet ki a kimenet:

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

Felhívjuk figyelmét, hogy a bejelentkezési kísérletek és más, a biztonsággal kapcsolatos események az Actuator dobozában, audit eseményként elérhetők.

4.6. Új végpont létrehozása

A Spring Boot által biztosított meglévő végpontok használata mellett létrehozhatunk egy teljesen újat is.

Először az új végpontnak kell megvalósítanunk a Végpont felület:

@ Component public class CustomEndpoint implementálja az Endpoint-ot {@Orride public String getId () {return "customEndpoint"; } @Orride public boolean isEnabled () {return true; } @Orride public boolean isSensitive () {return true; } @Orride public List invoke () {// Egyéni logika a kimeneti List üzenetek felépítéséhez = new ArrayList (); messages.add ("Ez az 1. üzenet"); messages.add ("Ez a 2. üzenet"); üzenetküldés; }}

Az új végpont elérése érdekében annak id feltérképezésére használják. Más szavakkal, ütéssel gyakorolhatjuk / customEndpoint.

Kimenet:

["Ez az 1. üzenet", "Ez a 2. üzenet"]

4.7. További testreszabás

Biztonsági okokból dönthetünk úgy, hogy az aktuátor végpontjait egy nem szabványos porton - a menedzsment.port tulajdonság könnyen használható annak konfigurálásához.

Továbbá, mint már említettük, az 1.x-ben. Az Actuator a saját biztonsági modelljét a Spring Security alapján konfigurálja, de független az alkalmazás többi részétől.

Ezért megváltoztathatjuk a vezetés.cím tulajdonság annak korlátozására, hogy a végpontok miként érhetők el a hálózaton keresztül:

#port a működtető menedzsmentjének feltárására szolgál. port = 8081 # # A CIDR megengedte a működtető menedzsmentjének elérését.

Ezenkívül az összes beépített végpont kivételével / info alapértelmezés szerint érzékenyek.

Ha az alkalmazás a Spring Security programot használja, akkor ezeket a végpontokat az alapértelmezett biztonsági tulajdonságok (felhasználónév, jelszó és szerepkör) meghatározásával biztosíthatjuk. alkalmazás.tulajdonságok fájl:

security.user.name = admin security.user.password = titkos management.security.role = SUPERUSER

5. Következtetés

Ebben a cikkben a Spring Boot Actuatorról beszéltünk. Azzal kezdtük, hogy meghatároztuk, hogy az Actuator mit jelent és mit jelent értünk.

Ezután az aktuális Spring Boot 2.x verzió Actuatorjára összpontosítottunk, és megvitattuk, hogyan kell használni, módosítani és kibővíteni. Beszéltünk azokról a fontos biztonsági változásokról is, amelyeket ebben az új iterációban tapasztalhatunk. Megbeszéltünk néhány népszerű végpontot, és azt is, hogyan változtak.

Ezután megvitattuk az Actuator-t a korábbi Spring Boot 1 verzióban.

Végül bemutattuk az Actuator testreszabásának és kiterjesztésének módját.

Mint mindig, az ebben a cikkben használt kód megtalálható a GitHubon a Spring Boot 2.x és a Spring Boot 1.x egyaránt.