streamalism.org

1. Oversigt

I denne artikel introducerer vi Spring Boot Actuator. Vi vil først dække det grundlæggende og derefter diskutere detaljeret, hvad der er tilgængeligt i Spring Boot 2.x vs 1.x.

Vi lærer at bruge, konfigurere og udvide dette overvågningsværktøj i Spring Boot 2.x og WebFlux ved at udnytte den reaktive programmeringsmodel. Derefter diskuterer vi, hvordan du gør det samme ved hjælp af Boot 1.x.

Spring Boot Actuator er tilgængelig siden april 2014 sammen med den første Spring Boot-udgivelse.

Med udgivelsen af ​​Spring Boot 2 er Actuator blevet redesignet, og nye spændende slutpunkter blev tilføjet.

Vi opdeler denne vejledning i tre hovedafsnit:

• Hvad er en aktuator?
• Spring Boot 2.x aktuator
• Spring Boot 1.x aktuator

2. Hvad er en aktuator?

I det væsentlige bringer Actuator produktionsklare funktioner til vores applikation.

Overvågning af vores app, indsamling af målinger, forståelse af trafik eller tilstanden i vores database bliver trivielt med denne afhængighed.

Den største fordel ved dette bibliotek er, at vi kan få produktionsværktøjer uden at skulle implementere disse funktioner selv.

Aktuator er primært vant til udsætte operationelle oplysninger om den kørende applikation - sundhed, metrics, info, dump, env osv. Det bruger HTTP-slutpunkter eller JMX bønner for at sætte os i stand til at interagere med det.

Når denne afhængighed er på klassestien, er der flere slutpunkter tilgængelige for os uden for boksen. Som med de fleste forårsmoduler kan vi nemt konfigurere eller udvide det på mange måder.

2.1. Kom godt i gang

For at aktivere Spring Boot Actuator skal vi bare tilføje fjeder-boot-aktuator afhængighed af vores pakkehåndtering.

I Maven:

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

Bemærk, at dette forbliver gyldigt uanset Boot-versionen, da versioner er specificeret i Spring Boot Bill of Materials (BOM).

3. Spring Boot 2.x aktuator

I 2.x beholder Actuator sin grundlæggende hensigt, men forenkler sin model, udvider dens muligheder og inkorporerer bedre standardindstillinger.

For det første bliver denne version teknologi-agnostiker. Det forenkler også sin sikkerhedsmodel ved at flette den med applikationen.

Blandt de forskellige ændringer er det vigtigt at huske på, at nogle af dem går i stykker. Dette inkluderer HTTP-anmodninger og svar samt Java API'er.

Endelig understøtter den nyeste version nu CRUD-modellen i modsætning til den gamle læse / skrive-model.

3.1. Teknologisk support

Med sin anden store version er Actuator nu teknologi-agnostiker, mens den i 1.x var bundet til MVC, derfor til Servlet API.

I 2.x definerer Actuator sin model som tilslutbar og udvidelig uden at stole på MVC for dette.

Derfor er vi med denne nye model i stand til at drage fordel af MVC såvel som WebFlux som en underliggende webteknologi.

Desuden kunne kommende teknologier tilføjes ved at implementere de rigtige adaptere.

Endelig forbliver JMX understøttet for at eksponere slutpunkter uden yderligere kode.

3.2. Vigtige ændringer

I modsætning til tidligere versioner, Aktuator leveres med de fleste slutpunkter deaktiveret.

Således er de eneste to tilgængelige som standard /sundhed og / info.

Hvis vi vil aktivere dem alle, kunne vi indstille management.endpoints.web.exposure.include = *. Alternativt kan vi angive slutpunkter, der skal aktiveres.

Aktuator deler nu sikkerhedskonfigurationen med de almindelige App-sikkerhedsregler, så sikkerhedsmodellen er dramatisk forenklet.

Derfor, for at finjustere Actuators sikkerhedsregler, kunne vi bare tilføje en post til / aktuator / **:

@Bean public SecurityWebFilterChain securityWebFilterChain (ServerHttpSecurity http) {return http.authorizeExchange () .pathMatchers ("/ actuator / **"). PermitAll () .anyExchange (). Authenticated () .and (). Build (); }

Vi kan finde yderligere oplysninger om de helt nye officielle dokumenter til aktuatoren.

Også, Som standard er alle aktuatorendepunkter nu placeret under / aktuator sti.

Samme som i den tidligere version, kan vi tilpasse denne sti ved hjælp af den nye egenskab management.endpoints.web.base-sti.

3.3. Foruddefinerede slutpunkter

Lad os se på nogle tilgængelige slutpunkter, hvoraf de fleste allerede var tilgængelige i 1.x.

Også, nogle slutpunkter er blevet tilføjet, nogle er fjernet, og nogle er blevet omstruktureret:

• / revisionsbegivenheder viser sikkerhedsrevisionsrelaterede begivenheder såsom brugerlogin / logout. Vi kan også filtrere efter princip eller type blandt andre felter.
• / bønner returnerer alle tilgængelige bønner i vores BeanFactory. I modsætning til / revisionsbegivenheder, det understøtter ikke filtrering.
• /betingelser, tidligere kendt som /autokonfiguration, bygger en rapport om forhold omkring autokonfiguration.
• / configprops giver os mulighed for at hente alle @ConfigurationProperties bønner.
• / env returnerer de aktuelle miljøegenskaber. Derudover kan vi hente enkelte egenskaber.
• / flyvebane giver oplysninger om vores Flyway-databasemigrationer.
• /sundhed opsummerer sundhedsstatus for vores ansøgning.
• / heapdump bygger og returnerer en heap dump fra JVM, der bruges af vores applikation.
• / info returnerer generel information. Det kan være brugerdefinerede data, byggeoplysninger eller detaljer om den seneste forpligtelse.
• / liquibase opfører sig som / flyvebane men for Liquibase.
• /logfil returnerer almindelige applikationslogfiler.
• / loggere gør det muligt for os at forespørge og ændre logningsniveauet for vores applikation.
• / metrics detaljer målinger af vores ansøgning. Dette kan omfatte såvel generiske metrics som tilpassede.
• / prometheus returnerer metrics som den forrige, men formateret til at arbejde med en Prometheus-server.
• / planlægge opgaver giver detaljer om hver planlagt opgave i vores applikation.
• / sessioner viser HTTP-sessioner givet vi bruger Spring Session.
• /lukke ned udfører en yndefuld nedlukning af applikationen.
• / threaddump dumper trådoplysningerne for den underliggende JVM.

3.4. Hypermedia til aktuatorendepunkter

Spring Boot tilføjer et opdagelsesendepunkt, der returnerer links til alle tilgængelige aktuatorendepunkter. Dette vil gøre det lettere at finde aktuatorendepunkter og deres tilsvarende URL'er.

Som standard er dette opdagelsesendepunkt tilgængeligt via / aktuator slutpunkt.

Derfor, hvis vi sender en FÅ anmodning om denne URL, vil den returnere aktuatorlinkene til de forskellige slutpunkter:

{"_links": {"self": {"href": "// localhost: 8080 / actuator", "templated": false}, "features-arg0": {"href": "// localhost: 8080 / aktuator / features / {arg0} "," templated ": true}," features ": {" href ":" // localhost: 8080 / actuator / features "," templated ": false}," beans ": {" href ":" // localhost: 8080 / actuator / beans "," templated ": false}," caches-cache ": {" href ":" // localhost: 8080 / actuator / caches / {cache} "," skabeloneret ": sandt}, // trunkeret}

Som vist ovenfor er / aktuator endpoint rapporterer alle tilgængelige aktuatorendepunkter under _links Mark.

Desuden, hvis vi konfigurerer en brugerdefineret administrationsbasesti, skal vi bruge den basesti som opdagelses-URL.

For eksempel, hvis vi indstiller management.endpoints.web.base-sti til / mgmt, så skal vi sende en anmodning til / mgmt slutpunkt for at se listen over links.

Ganske interessant, når ledelsesbasestien er indstillet til /er opdagelsesendepunktet deaktiveret for at forhindre muligheden for et sammenstød med andre tilknytninger.

3.5. Sundhedsindikatorer

Ligesom i den tidligere version kan vi nemt tilføje tilpassede indikatorer. Modsat andre API'er forbliver abstraktionerne til oprettelse af tilpassede sundhedsendepunkter uændrede. Imidlertid, en ny grænseflade, Reaktiv Sundhedsindikator, er tilføjet for at gennemføre reaktive sundhedstjek.

Lad os se på en simpel brugerdefineret reaktiv sundhedstjek:

@Komponent offentlig klasse DownstreamServiceHealthIndicator implementerer ReactiveHealthIndicator {@Override public Mono health () {return checkDownstreamServiceHealth (). OnErrorResume (ex -> Mono.just (new Health.Builder (). Down (ex) .build ())); } privat Mono checkDownstreamServiceHealth () {// vi kunne bruge WebClient til at kontrollere sundhed reaktivt returnere Mono.just (ny Health.Builder (). op (). build ()); }}

Et praktisk træk ved sundhedsindikatorer er, at vi kan samle dem som en del af et hierarki.

Så efter det foregående eksempel kunne vi gruppere alle downstream-tjenester under en nedstrøms-tjenester kategori. Denne kategori ville være sund, så længe alle indlejrede service var tilgængelig.

Se vores artikel om sundhedsindikatorer for et mere dybtgående look.

3.6. Sundhedsgrupper

Fra og med Spring Boot 2.2 kan vi organisere sundhedsindikatorer i grupper og anvende den samme konfiguration på alle gruppemedlemmerne.

For eksempel kan vi oprette en sundhedsgruppe med navnet brugerdefinerede ved at tilføje dette til vores application.properties:

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

På denne måde brugerdefinerede gruppen indeholder diskplads og ping sundhedsindikatorer.

Nu hvis vi kalder / aktuator / sundhed slutpunkt, ville det fortælle os om den nye sundhedsgruppe i JSON-svaret:

{"status": "OP", "grupper": ["tilpasset"]}

Med sundhedsgrupper kan vi se de samlede resultater af et par sundhedsindikatorer.

I dette tilfælde, hvis vi sender en anmodning til / aktuator / sundhed / brugerdefineret, derefter:

{"status": "OP"}

Vi kan konfigurere gruppen til at vise flere detaljer via application.properties:

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

Nu hvis vi sender den samme anmodning til / aktuator / sundhed / brugerdefineret, vi får vist flere detaljer:

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

Det er også muligt kun at vise disse detaljer for autoriserede brugere:

management.endpoint.health.group.custom.show-components = når_autoriseret management.endpoint.health.group.custom.show-details = når_autoriseret

Vi kan også have en brugerdefineret statuskortlægning.

For eksempel kan det i stedet for et HTTP 200 OK-svar returnere en 207-statuskode:

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

Her beder vi Spring Boot om at returnere en 207 HTTP-statuskode, hvis den brugerdefinerede gruppestatus er OP.

3.7. Metrics in Spring Boot 2

I Spring Boot 2.0 blev de interne målinger udskiftet med Micrometer-understøttelse, så vi kan forvente at bryde ændringer. Hvis vores ansøgning brugte metriske tjenester som f.eks GaugeService eller CounterService, vil de ikke længere være tilgængelige.

I stedet forventes det, at vi interagerer med mikrometer direkte. I Spring Boot 2.0 får vi en bønne af typen MeterRegistry autokonfigureret for os.

Desuden er Micrometer nu en del af aktuatorens afhængighed, så vi skal være gode til at gå så længe aktuatorafhængigheden er i klassestien.

Desuden får vi et helt nyt svar fra / metrics slutpunkt:

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

Som vi kan se, er der ingen faktiske målinger, som vi fik i 1.x.

For at få den aktuelle værdi af en bestemt metric kan vi nu navigere til den ønskede metric, f.eks. /actuator/metrics/jvm.gc.pause, og få et detaljeret svar:

{"navn": "jvm.gc.pause", "målinger": [{"statistik": "Tæller", "værdi": 3.0}, {"statistik": "TotalTime", "værdi": 7.9E7} , {"statistic": "Max", "value": 7.9E7}], "availableTags": [{"tag": "cause", "values": ["Metadata GC Threshold", "Allocation Failure"]} , {"tag": "action", "values": ["end of minor GC", "end of major GC"]}}

Nu er metrics meget mere grundige, herunder ikke kun forskellige værdier, men også nogle tilknyttede metadata.

3.8. Tilpasning af / info Slutpunkt

Det / info slutpunkt forbliver uændret. Som før kan vi tilføje git detaljer ved hjælp af den respektive Maven eller Gradle afhængighed:

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

Ligeledes, Vi kunne også inkludere buildoplysninger, herunder navn, gruppe og version ved hjælp af Maven- eller Gradle-plugin'et:

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

3.9. Oprettelse af et brugerdefineret slutpunkt

Som vi tidligere har påpeget, kan vi oprette brugerdefinerede slutpunkter. Spring Boot 2 har dog redesignet vejen for at opnå dette for at understøtte det nye teknologi-agnostiske paradigme.

Lad os oprette et aktuatorendepunkt til forespørgsel, aktivering og deaktivering af funktionsflag i vores applikation:

@Component @Endpoint (id = "features") offentlig klasse FeaturesEndpoint {private Map features = new ConcurrentHashMap (); @ReadOperation offentlige kortfunktioner () {returfunktioner; } @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); } offentlig statisk klasse Feature {privat boolsk aktiveret; // [...] getters og setters}}

For at få slutpunktet har vi brug for en bønne. I vores eksempel bruger vi @Komponent for det. Vi skal også dekorere denne bønne med @Endpoint.

Stien til vores slutpunkt bestemmes af id parameter for @Endpoint. I vores tilfælde dirigerer den anmodninger til / aktuator / funktioner.

Når vi er klar, kan vi begynde at definere operationer ved hjælp af:

• @ReadOperation: Det kortlægges til HTTP FÅ.
• @WriteOperation: Det kortlægges til HTTP STOLPE.
• @DeleteOperation: Det kortlægges til HTTP SLET.

Når vi kører applikationen med det forrige slutpunkt i vores applikation, registrerer Spring Boot det.

En hurtig måde at bekræfte dette på er at kontrollere logfiler:

[...]. WebFluxEndpointHandlerMapping: Kortlagt "{[/ actuator / features / {name}], metoder = [GET], producerer = [application / vnd.spring-boot.actuator.v2 + json || application / json] } "[...]. WebFluxEndpointHandlerMapping: Kortlagt" application / json] "[...]. WebFluxEndpointHandlerMapping: Kortlagt" {[/ actuator / features / {name}], methods = [POST], forbruger = [applikation / vnd.spring-boot.actuator.v2 + json || application / json]} "[...]. WebFluxEndpointHandlerMapping: Kortlagt" {[/ actuator / features / {name}], methods = [DELETE]} "[. ..]

I de tidligere logfiler kan vi se, hvordan WebFlux udsætter vores nye slutpunkt. Hvis vi skifter til MVC, delegerer den simpelthen den teknologi uden at skulle ændre nogen kode.

Vi har også et par vigtige overvejelser at huske på med denne nye tilgang:

• Der er ingen afhængigheder med MVC.
• Alle metadata til stede som metoder før (følsom, aktiveret ...) eksisterer ikke længere. Vi kan dog aktivere eller deaktivere slutpunktet ved hjælp af @Endpoint (id = “features”, enableByDefault = false).
• I modsætning til i 1.x er der ikke længere behov for at udvide en given grænseflade.
• I modsætning til den gamle læse / skrive model kan vi nu definere SLET operationer ved hjælp af @DeleteOperation.

3.10. Udvidelse af eksisterende slutpunkter

Lad os forestille os, at vi vil sikre os, at produktionsinstansen af ​​vores ansøgning aldrig er en SNAPSHOT version.

Vi beslutter at gøre dette ved at ændre HTTP-statuskoden for aktuatorendepunktet, der returnerer disse oplysninger, dvs. / info. Hvis vores app tilfældigvis var en SNAPSHOT, ville vi få en anden HTTP statuskode.

Vi kan let udvide adfærden for et foruddefineret slutpunkt ved hjælp af @EndpointExtension kommentarereller dens mere konkrete specialiseringer @EndpointWebExtension eller @EndpointJmxExtension:

@Component @EndpointWebExtension (endpoint = InfoEndpoint.class) offentlig klasse InfoWebEndpointExtension {privat InfoEndpoint-delegat; // standardkonstruktør @ReadOperation offentlig WebEndpointResponse info () {Map info = this.delegate.info (); Heltalsstatus = getStatus (info); returner nyt WebEndpointResponse (info, status); } privat heltal getStatus (kortinfo) {// returner 5xx, hvis dette er et øjebliksbillede returnerer 200; }}

3.11. Aktivér alle slutpunkter

For at få adgang til aktuatorendepunkterne ved hjælp af HTTP er vi nødt til både at aktivere og udsætte dem.

Som standard er alle slutpunkter undtagen /lukke ned er aktiveret. Kun den /sundhed og / info slutpunkter eksponeres som standard.

Vi skal tilføje følgende konfiguration for at eksponere alle slutpunkter:

management.endpoints.web.exposure.include = *

For eksplicit at aktivere et specifikt slutpunkt (f.eks. /lukke ned), vi bruger:

management.endpoint.shutdown.enabled = sand

At eksponere alle aktiverede slutpunkter undtagen et (f.eks. / loggere), vi bruger:

management.endpoints.web.exposure.include = * management.endpoints.web.exposure.exclude = loggere

4. Spring Boot 1.x aktuator

I 1.x følger aktuatoren en læse / skrive-model, hvilket betyder, at vi enten kan læse fra den eller skrive til den.

For eksempel kan vi hente metrics eller sundheden for vores applikation. Alternativt kan vi yndefuldt afslutte vores app eller ændre vores logningskonfiguration.

For at få det til at fungere kræver Actuator, at Spring MVC udsætter sine slutpunkter via HTTP. Ingen anden teknologi understøttes.

4.1. Slutpunkter

I 1.x bringer Actuator sin egen sikkerhedsmodel. Det udnytter Spring Security-konstruktioner, men skal konfigureres uafhængigt af resten af ​​applikationen.

De fleste slutpunkter er også følsomme - hvilket betyder at de ikke er fuldt offentligt, eller de fleste oplysninger udelades - mens en håndfuld ikke er, f.eks. / info.

Her er nogle af de mest almindelige slutpunkter, Boot giver ud af kassen:

• /sundhed viser sundhedsoplysninger om applikationen (en simpel status når der er adgang til en uautentificeret forbindelse eller fulde meddelelsesoplysninger, når godkendt); det er ikke følsomt som standard.
• / info viser vilkårlig applikationsinformation; det er ikke følsomt som standard.
• / metrics viser oplysninger om metrics til den aktuelle applikation; det er som standard følsomt.
• / spor viser sporingsoplysninger (som standard de sidste par HTTP-anmodninger).

Vi kan finde den fulde liste over eksisterende slutpunkter på de officielle dokumenter.

4.2. Konfiguration af eksisterende slutpunkter

Vi kan tilpasse hvert slutpunkt med egenskaber ved hjælp af formatet slutpunkter. [slutpunktsnavn]. [egenskab, der skal tilpasses].

Tre ejendomme er tilgængelige:

• id: hvorved dette slutpunkt vil blive adgang til via HTTP
• aktiveret: hvis det er sandt, så kan det tilgås; ellers ikke
• følsom: hvis det er sandt, skal du have tilladelse til at vise vigtige oplysninger via HTTP

For eksempel kan tilføjelse af følgende egenskaber tilpasse /bønner slutpunkt:

endpoints.beans.id = springbeans endpoints.beans.sensitive = falske endpoints.beans.enabled = true

4.3. /sundhed Slutpunkt

Det /sundhed slutpunkt bruges til at kontrollere den kørende applikations sundhed eller tilstand.

Det udøves normalt ved at overvåge software for at advare os, hvis den kørende forekomst går ned eller bliver usund af andre grunde, f.eks. Forbindelsesproblemer med vores DB, mangel på diskplads osv.

Som standard kan uautoriserede brugere kun se statusoplysninger, når de har adgang via HTTP:

{"status": "OP"} 

Disse sundhedsoplysninger indsamles fra alle bønner, der implementerer HealthIndicator interface konfigureret i vores applikationskontekst.

Nogle oplysninger returneret af HealthIndicator er følsom i naturen, men vi kan konfigurere endpoints.health.sensitive = false at eksponere mere detaljerede oplysninger som diskplads, messaging-mæglerforbindelse, brugerdefinerede kontroller og mere.

Bemærk, at dette kun fungerer for Spring Boot-versioner under 1.5.0. For 1.5.0 og nyere versioner skal vi også deaktivere sikkerhed ved at indstille management.security.enabled = falsk for uautoriseret adgang.

Vi kunne også implementere vores egen brugerdefinerede sundhedsindikator, som kan indsamle alle former for brugerdefinerede sundhedsdata, der er specifikke for applikationen, og automatisk eksponere dem via /sundhed slutpunkt:

@Component ("myHealthCheck") offentlig klasse HealthCheck implementerer HealthIndicator {@ Override public Health health () {int errorCode = check (); // udfør en specifik sundhedskontrol, hvis (errorCode! = 0) {returner Health.down () .withDetail ("Error Code", errorCode) .build (); } returner Health.up (). build (); } public int check () {// Vores logik til at kontrollere health return 0; }} 

Sådan ser output ud:

{"status": "NED", "myHealthCheck": {"status": "NED", "Fejlkode": 1}, "diskSpace": {"status": "OP", "gratis": 209047318528, " tærskel ": 10485760}}

4.4. / info Slutpunkt

Vi kan også tilpasse de data, der vises af / info slutpunkt:

info.app.name = Forårseksempel på applikation info.app.description = Dette er min første forårstarter-applikation info.app.version = 1.0.0

Og prøveoutput:

{"app": {"version": "1.0.0", "description": "Dette er min første spring boot-applikation", "name": "Spring Sample Application"}}

4.5. / metrics Slutpunkt

Metrics endpoint offentliggør oplysninger om OS og JVM samt metrics på applikationsniveau. Når det er aktiveret, får vi oplysninger som hukommelse, heap, processorer, tråde, klasser indlæst, klasser aflæst og trådpuljer sammen med nogle HTTP-metrics.

Sådan ser output fra dette slutpunkt ud af kassen:

{"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} 

For at samle brugerdefinerede metrics har vi understøttelse af målere (snapshots af enkeltværdi af data) og tællere, dvs. stigende / dekrementerende metrics.

Lad os implementere vores egne brugerdefinerede metrics i / metrics slutpunkt.

Vi tilpasser loginflowet til at registrere et vellykket og mislykket loginforsøg:

@Service offentlig klasse LoginServiceImpl {privat endelig CounterService counterService; offentlig LoginServiceImpl (CounterService counterService) {this.counterService = counterService; } offentlig boolsk login (String userName, char [] password) {boolsk succes; hvis (userName.equals ("admin") && "hemmelig" .toCharArray (). er lig med (adgangskode)) {counterService.increment ("counter.login.success"); succes = sand; } andet {counterService.increment ("counter.login.failure"); succes = falsk; } returnere succes; }}

Her er hvordan output kan se ud:

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

Bemærk, at loginforsøg og andre sikkerhedsrelaterede begivenheder er tilgængelige uden for boksen i Actuator som revisionshændelser.

4.6. Oprettelse af et nyt slutpunkt

Ud over at bruge de eksisterende slutpunkter, der leveres af Spring Boot, kan vi også oprette en helt ny.

Først skal vi have det nye slutpunkt til at implementere Slutpunkt grænseflade:

@Komponent offentlig klasse CustomEndpoint implementerer slutpunkt {@Override public String getId () {return "customEndpoint"; } @Override public boolean isEnabled () {return true; } @Override public boolean isSensitive () {return true; } @Override public List invoke () {// Custom logic to build the output List messages = new ArrayList (); messages.add ("Dette er besked 1"); messages.add ("Dette er besked 2"); returnere beskeder; }}

For at få adgang til dette nye slutpunkt er dets id bruges til at kortlægge det. Med andre ord kunne vi udøve det at ramme / customEndpoint.

Produktion:

["Dette er besked 1", "Dette er besked 2"]

4.7. Yderligere tilpasning

Af sikkerhedsmæssige årsager kan vi vælge at udsætte aktuatorendepunkterne over en ikke-standard port - management.port egenskab kan let bruges til at konfigurere det.

Som vi allerede nævnte, i 1.x. Actuator konfigurerer sin egen sikkerhedsmodel baseret på Spring Security, men uafhængig af resten af ​​applikationen.

Derfor kan vi ændre ledelse. adresse egenskab for at begrænse, hvor slutpunkterne kan tilgås fra over netværket:

#port bruges til at udsætte aktuatoradministration.port = 8081 #CIDR tilladt at ramme aktuatoradministration.address = 127.0.0.1 #Hvis sikkerhed skal aktiveres eller deaktiveres helt management.security.enabled = false

Desuden alle de indbyggede slutpunkter undtagen / info er følsomme som standard.

Hvis applikationen bruger Spring Security, kan vi sikre disse slutpunkter ved at definere standardsikkerhedsegenskaber (brugernavn, adgangskode og rolle) i application.properties fil:

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

5. Konklusion

I denne artikel talte vi om Spring Boot Actuator. Vi begyndte med at definere, hvad aktuator betyder, og hvad det gør for os.

Dernæst fokuserede vi på aktuator til den nuværende Spring Boot version 2.x, diskuterede hvordan man bruger den, tilpasser den og udvider den. Vi talte også om de vigtige sikkerhedsændringer, som vi kan finde i denne nye iteration. Vi diskuterede nogle populære slutpunkter og hvordan de også har ændret sig.

Derefter diskuterede vi aktuator i den tidligere Spring Boot 1-version.

Endelig demonstrerede vi, hvordan man tilpasser og udvider aktuatoren.

Som altid kan koden, der bruges i denne artikel, findes på GitHub til både Spring Boot 2.x og Spring Boot 1.x.