streamalism.org

1. Oversikt

I denne artikkelen introduserer vi Spring Boot Actuator. Vi vil dekke det grunnleggende først, og deretter diskutere i detalj hva som er tilgjengelig i Spring Boot 2.x vs 1.x.

Vi lærer hvordan du bruker, konfigurerer og utvider dette overvåkingsverktøyet i Spring Boot 2.x og WebFlux, og utnytter den reaktive programmeringsmodellen. Deretter vil vi diskutere hvordan du gjør det samme ved hjelp av Boot 1.x.

Spring Boot Actuator er tilgjengelig siden april 2014, sammen med den første Spring Boot-utgivelsen.

Med utgivelsen av Spring Boot 2 har Actuator blitt redesignet, og nye spennende endepunkter ble lagt til.

Vi deler denne guiden i tre hoveddeler:

• Hva er en aktuator?
• Spring Boot 2.x Aktuator
• Spring Boot 1.x Aktuator

2. Hva er en aktuator?

I hovedsak bringer Actuator produksjonsklare funksjoner til applikasjonen vår.

Overvåking av appen vår, samle beregninger, forstå trafikk eller tilstanden til databasen vår blir triviell med denne avhengigheten.

Den største fordelen med dette biblioteket er at vi kan få produksjonsverktøy uten å måtte implementere disse funksjonene selv.

Aktuator er hovedsakelig vant til avsløre operasjonell informasjon om den kjørende applikasjonen - helse, beregninger, info, dump, env, etc. Den bruker HTTP-endepunkter eller JMX-bønner for å gjøre det mulig for oss å samhandle med det.

Når denne avhengigheten er på klassestien, er det flere endepunkter tilgjengelig for oss. Som med de fleste vårmoduler, kan vi enkelt konfigurere eller utvide den på mange måter.

2.1. Starter

For å aktivere Spring Boot Actuator, trenger vi bare å legge til fjær-boot-aktuator avhengighet til pakkelederen vår.

I Maven:

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

Merk at dette forblir gyldig uavhengig av Boot-versjonen, ettersom versjoner er spesifisert i Spring Boot Bill of Materials (BOM).

3. Spring Boot 2.x Aktuator

I 2.x beholder Actuator sin grunnleggende hensikt, men forenkler modellen, utvider funksjonene og inkluderer bedre standardinnstillinger.

For det første blir denne versjonen teknologi-agnostiker. Det forenkler også sikkerhetsmodellen ved å slå den sammen med applikasjonen.

Blant de forskjellige endringene er det viktig å huske på at noen av dem går i stykker. Dette inkluderer HTTP-forespørsler og svar samt Java APIer.

Til slutt støtter den siste versjonen nå CRUD-modellen i motsetning til den gamle lese / skrive-modellen.

3.1. Teknologisk støtte

Med sin andre store versjon er Actuator nå teknologi-agnostiker, mens den i 1.x var knyttet til MVC, derfor til Servlet API.

I 2.x definerer Actuator sin modell som pluggbar og utvidbar uten å stole på MVC for dette.

Derfor, med denne nye modellen, er vi i stand til å dra nytte av MVC så vel som WebFlux som en underliggende webteknologi.

Videre kan kommende teknologier legges til ved å implementere de riktige adapterne.

Til slutt forblir JMX støttet for å avsløre endepunkter uten ytterligere kode.

3.2. Viktige endringer

I motsetning til tidligere versjoner, Aktuator kommer med de fleste endepunktene deaktivert.

Dermed er de eneste to tilgjengelige som standard /Helse og / info.

Hvis vi vil aktivere dem alle, kan vi sette management.endpoints.web.exposure.include = *. Alternativt kan vi liste opp sluttpunkter som skal aktiveres.

Aktuator deler nå sikkerhetskonfigurasjonen med de vanlige appsikkerhetsreglene, så sikkerhetsmodellen er dramatisk forenklet.

Derfor, for å finjustere sikkerhetsregler for aktuator, kan vi bare legge til en oppføring for / aktuator / **:

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

Vi kan finne ytterligere detaljer om den splitter nye offisielle dokumentasjonen for aktuator.

Også, som standard er alle aktuatorendepunktene nå plassert under / aktuator sti.

Samme som i forrige versjon, kan vi tilpasse denne banen ved hjelp av den nye egenskapen management.endpoints.web.base-path.

3.3. Forhåndsdefinerte sluttpunkter

La oss ta en titt på noen tilgjengelige sluttpunkter, hvorav de fleste allerede var tilgjengelige i 1.x.

Også, noen endepunkter er lagt til, noen fjernet og noen er omstrukturert:

• / revisjonsbegivenheter viser sikkerhetsrevisjonsrelaterte hendelser som brukerinnlogging / utlogging. Vi kan også filtrere etter rektor eller type blant andre felt.
• / bønner returnerer alle tilgjengelige bønner i vår BeanFactory. I motsetning til / revisjonsbegivenheter, det støtter ikke filtrering.
• / forhold, tidligere kjent som /autokonfigurasjon, bygger en rapport om forholdene rundt autokonfigurasjon.
• / configprops lar oss hente alt @ConfigurationProperties bønner.
• / env returnerer gjeldende miljøegenskaper. I tillegg kan vi hente ut enkeltegenskaper.
• / flyvebane gir informasjon om Flyway-databasemigreringene våre.
• /Helse oppsummerer helsestatusen til søknaden vår.
• / heapdump bygger og returnerer en heap dump fra JVM som brukes av applikasjonen vår.
• / info returnerer generell informasjon. Det kan være tilpassede data, byggeinformasjon eller detaljer om den siste forpliktelsen.
• / liquibase oppfører seg som / flyvebane men for Liquibase.
• /loggfil returnerer vanlige applikasjonslogger.
• / loggere gjør oss i stand til å spørre og endre loggningsnivået til applikasjonen vår.
• / beregninger detaljer om beregningene av søknaden vår. Dette kan omfatte generiske beregninger så vel som tilpassede.
• / prometheus returnerer beregninger som den forrige, men formatert for å fungere med en Prometheus-server.
• /planlagte oppgaver gir detaljer om hver planlagte oppgave i applikasjonen vår.
• / økter viser HTTP-økter gitt vi bruker vårsesjon.
• /skru av utfører en grasiøs nedleggelse av applikasjonen.
• / tråddumping dumper trådinformasjonen til den underliggende JVM.

3.4. Hypermedia for aktuatorendepunkter

Spring Boot legger til et oppdagelsesendepunkt som returnerer lenker til alle tilgjengelige aktuatorendepunkter. Dette vil gjøre det lettere å oppdage aktuatorens endepunkter og deres tilhørende URL-er.

Som standard er dette oppdagelsesendepunktet tilgjengelig via / aktuator endepunkt.

Derfor, hvis vi sender en FÅ forespørsel til denne URL-en, vil den returnere aktuatorkoblingene for de forskjellige sluttpunktene:

{"_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} "," mal ": sann}, // avkortet}

Som vist ovenfor, / aktuator endpoint rapporterer alle tilgjengelige aktuatorendepunkter under _lenker felt.

Videre, hvis vi konfigurerer en tilpasset administrasjonsbasesti, bør vi bruke den basestien som oppdagelses-URL.

For eksempel hvis vi stiller inn management.endpoints.web.base-path til / mgmt, så skal vi sende en forespørsel til / mgmt sluttpunkt for å se listen over lenker.

Ganske interessant når ledelsesgrunnlaget er satt til /, er oppdagelsesendepunktet deaktivert for å forhindre muligheten for et sammenstøt med andre kartlegginger.

3.5. Helseindikatorer

Akkurat som i forrige versjon, kan vi enkelt legge til tilpassede indikatorer. I motsetning til andre API-er forblir abstraksjonene for å lage tilpassede helseendepunkter uendret. Derimot, et nytt grensesnitt, Reaktiv Helseindikator, er lagt til for å gjennomføre reaktive helsekontroller.

La oss ta en titt på en enkel tilpasset reaktiv helsesjekk:

@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 kan bruke WebClient til å sjekke helse reaktivt returnere Mono.just (ny Health.Builder (). opp (). build ()); }}

En hendig funksjon av helseindikatorer er at vi kan samle dem som en del av et hierarki.

Så, i følge det forrige eksemplet, kunne vi gruppere alle nedstrøms tjenester under a nedstrøms-tjenester kategori. Denne kategorien vil være sunn så lenge alle nestede service var tilgjengelig.

Sjekk ut vår artikkel om helseindikatorer for et mer inngående utseende.

3.6. Helsegrupper

Fra og med Spring Boot 2.2 kan vi organisere helseindikatorer i grupper og bruke samme konfigurasjon på alle gruppemedlemmene.

For eksempel kan vi opprette en helsegruppe som heter tilpasset ved å legge dette til vårt application.properties:

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

På denne måten, tilpasset gruppen inneholder diskplass og ping helseindikatorer.

Nå hvis vi kaller / aktuator / helse endepunkt, ville det fortelle oss om den nye helsegruppen i JSON-svaret:

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

Med helsegrupper kan vi se de samlede resultatene av noen få helseindikatorer.

I dette tilfellet, hvis vi sender en forespørsel til / aktuator / helse / skikk, deretter:

{"status": "UP"}

Vi kan konfigurere gruppen til å vise mer informasjon via application.properties:

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

Nå hvis vi sender den samme forespørselen til / aktuator / helse / tilpasset, vi får se flere detaljer:

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

Det er også mulig å vise disse detaljene bare for autoriserte brukere:

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

Vi kan også ha en tilpasset statuskartlegging.

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

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

Her ber vi Spring Boot om å returnere en 207 HTTP-statuskode hvis tilpasset gruppestatus er OPP.

3.7. Målinger i vårstøvel 2

I Spring Boot 2.0 ble de interne beregningene erstattet med mikrometerstøtte, slik at vi kan forvente brudd på endringene. Hvis søknaden vår brukte metriske tjenester som GaugeService eller CounterService, vil de ikke lenger være tilgjengelige.

I stedet forventes det at vi kommuniserer direkte med Micrometer. I Spring Boot 2.0 får vi en bønne av typen MeterRegistry autokonfigurert for oss.

Videre er Micrometer nå en del av Actuators avhengighet, så vi burde være gode å gå så lenge Actuatoravhengigheten er i klassestien.

Videre får vi et helt nytt svar fra / beregninger sluttpunkt:

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

Som vi kan se, er det ingen faktiske beregninger slik vi fikk i 1.x.

For å få den faktiske verdien av en bestemt beregning, kan vi nå navigere til ønsket beregning, f.eks. /actuator/metrics/jvm.gc.pause, og få et detaljert svar:

{"navn": "jvm.gc.pause", "målinger": [{"statistikk": "Antall", "verdi": 3.0}, {"statistikk": "TotalTime", "verdi": 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"]}}}

Nå er beregninger mye grundigere, inkludert ikke bare forskjellige verdier, men også noen tilknyttede metadata.

3.8. Tilpasse / info Endepunkt

De / info endepunkt forblir uendret. Som før kan vi legge til gitdetaljer ved hjelp av den respektive Maven- eller Gradle-avhengigheten:

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

Like måte, Vi kan også inkludere byggeinformasjon inkludert navn, gruppe og versjon ved hjelp av Maven eller Gradle plugin:

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

3.9. Opprette et egendefinert sluttpunkt

Som vi påpekte tidligere, kan vi opprette egendefinerte endepunkter. Spring Boot 2 har imidlertid redesignet måten å oppnå dette for å støtte det nye teknologi-agnostiske paradigmet.

La oss lage et aktuatorendepunkt for å spørre, aktivere og deaktivere funksjonsflagg i applikasjonen vår:

@Component @Endpoint (id = "features") offentlig klasse FeaturesEndpoint {private Map features = new ConcurrentHashMap (); @ReadOperation offentlige kartfunksjoner () {returfunksjoner; } @ReadOperation public Feature feature (@Selector Streng name) {return features.get (name); } @WriteOperation public void configureFeature (@Selector String name, Feature feature) {features.put (name, feature); } @DeleteOperation public void deleteFeature (@Selector Streng name) {features.remove (name); } offentlig statisk klasse Feature {private Boolean enabled; // [...] getters og setters}}

For å få sluttpunktet trenger vi en bønne. I vårt eksempel bruker vi @Komponent for dette. Vi må også dekorere denne bønnen med @Endpoint.

Stien til vårt endepunkt bestemmes av id parameter for @Endpoint. I vårt tilfelle vil den rute forespørsler til / aktuator / funksjoner.

Når vi er klare, kan vi begynne å definere operasjoner ved å bruke:

• @ReadOperation: Det vil tilordnes til HTTP FÅ.
• @WriteOperation: Det vil tilordnes til HTTP POST.
• @DeleteOperation: Det vil tilordnes til HTTP SLETT.

Når vi kjører applikasjonen med forrige sluttpunkt i applikasjonen vår, registrerer Spring Boot det.

En rask måte å bekrefte dette på er å sjekke loggene:

[...]. WebFluxEndpointHandlerMapping: Kartlagt "{[/ actuator / features / {name}], methods = [GET], produserer = [application / vnd.spring-boot.actuator.v2 + json || application / json] } "[...]. WebFluxEndpointHandlerMapping: Kartlagt" applikasjon / json] "[...]. WebFluxEndpointHandlerMapping: Kartlagt" {[/ actuator / features / {name}], methods = [POST], forbruker = [applikasjon / vnd.spring-boot.actuator.v2 + json || application / json]} "[...]. WebFluxEndpointHandlerMapping: Kartlagt" {[/ actuator / features / {name}], methods = [DELETE]} "[. ..]

I de forrige loggene kan vi se hvordan WebFlux eksponerer vårt nye endepunkt. Hvis vi bytter til MVC, vil det bare delegere den teknologien uten å måtte endre noen kode.

Vi har også noen viktige hensyn å huske på med denne nye tilnærmingen:

• Det er ingen avhengigheter med MVC.
• Alle metadataene er til stede som metoder før (sensitiv, aktivert ...) eksisterer ikke lenger. Vi kan imidlertid aktivere eller deaktivere sluttpunktet ved hjelp av @Endpoint (id = “features”, enableByDefault = false).
• I motsetning til i 1.x er det ikke lenger behov for å utvide et gitt grensesnitt.
• I motsetning til den gamle lese / skrive-modellen kan vi nå definere SLETT operasjoner ved hjelp av @DeleteOperation.

3.10. Utvide eksisterende endepunkter

La oss forestille oss at vi vil sørge for at produksjonsinstansen av applikasjonen vår aldri er en STILLBILDE versjon.

Vi bestemmer oss for å gjøre dette ved å endre HTTP-statuskoden til Actuator-endepunktet som returnerer denne informasjonen, dvs. / info. Hvis appen vår tilfeldigvis var en STILLBILDE, ville vi få en annen HTTP statuskode.

Vi kan enkelt utvide oppførselen til et forhåndsdefinert endepunkt ved å bruke @EndpointExtension kommentarer, eller dens mer konkrete spesialiseringer @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 (); Heltallstatus = getStatus (info); returner nye WebEndpointResponse (info, status); } private Integer getStatus (Map info) {// return 5xx hvis dette er et øyeblikksbilde returnerer 200; }}

3.11. Aktiver alle sluttpunkter

For å få tilgang til aktuatorendepunktene ved hjelp av HTTP, må vi både aktivere og eksponere dem.

Som standard er alle sluttpunkter men /skru av er aktivert. Bare den /Helse og / info endepunkter er eksponert som standard.

Vi må legge til følgende konfigurasjon for å eksponere alle sluttpunkter:

management.endpoints.web.exposure.include = *

For å eksplisitt aktivere et bestemt sluttpunkt (f.eks. /skru av), vi bruker:

management.endpoint.shutdown.enabled = sant

Å avsløre alle aktiverte sluttpunkter unntatt ett (f.eks. / loggere), vi bruker:

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

4. Spring Boot 1.x Aktuator

I 1.x følger aktuatoren en lese / skrive-modell, noe som betyr at vi enten kan lese fra den eller skrive til den.

For eksempel kan vi hente beregninger eller helsen til søknaden vår. Alternativt kan vi elegant avslutte appen vår eller endre loggkonfigurasjonen.

For å få det til å fungere krever Actuator at Spring MVC eksponerer endepunktene sine via HTTP. Ingen annen teknologi støttes.

4.1. Endepunkter

I 1.x bringer Actuator sin egen sikkerhetsmodell. Det utnytter Spring Security-konstruksjoner, men må konfigureres uavhengig av resten av applikasjonen.

Også de fleste endepunkter er følsomme - noe som betyr at de ikke er fullstendig offentlige, ellers blir mest informasjon utelatt - mens en håndfull ikke er, f.eks. / info.

Her er noen av de vanligste sluttpunktene Boot gir ut av boksen:

• /Helse viser helseinformasjon om applikasjonen (en enkel status når du får tilgang til en uautentisert tilkobling eller fullstendige meldingsdetaljer når autentisert); det er ikke følsomt som standard.
• / info viser vilkårlig applikasjonsinformasjon; det er ikke følsomt som standard.
• / beregninger viser beregningsinformasjon for gjeldende applikasjon; det er følsomt som standard.
• / spor viser sporingsinformasjon (som standard de siste HTTP-forespørslene).

Vi finner den fullstendige listen over eksisterende endepunkter på de offisielle dokumentene.

4.2. Konfigurere eksisterende sluttpunkter

Vi kan tilpasse hvert sluttpunkt med egenskaper ved hjelp av formatet endepunkter. [endepunktnavn]. [egenskap å tilpasse].

Tre eiendommer er tilgjengelige:

• id: hvor dette endepunktet vil bli tilgjengelig via HTTP
• aktivert: hvis det er sant, kan det nås; ellers ikke
• følsom: hvis det er sant, trenger du autorisasjon for å vise viktig informasjon over HTTP

Hvis du for eksempel legger til følgende egenskaper, vil du tilpasse /bønner endepunkt:

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

4.3. /Helse Endepunkt

De /Helse endepunkt brukes til å kontrollere helsen eller tilstanden til det kjørende programmet.

Det utøves vanligvis ved å overvåke programvare for å varsle oss om den kjørende forekomsten går ned eller blir usunn av andre grunner, for eksempel tilkoblingsproblemer med DB, mangel på diskplass osv.

Som standard kan uautoriserte brukere bare se statusinformasjon når de får tilgang via HTTP:

{"status": "UP"} 

Denne helseinformasjonen er samlet inn fra alle bønnene som implementerer HealthIndicator grensesnitt konfigurert i vår applikasjonssammenheng.

Noe informasjon returnert av HealthIndicator er følsom i naturen, men vi kan konfigurere endpoints.health.sensitive = false for å avsløre mer detaljert informasjon som diskplass, tilkobling til meldingsmegler, tilpassede sjekker og mer.

Merk at dette bare fungerer for Spring Boot-versjoner under 1.5.0. For 1.5.0 og nyere versjoner, bør vi også deaktivere sikkerhet ved å angi management.security.enabled = false for uautorisert tilgang.

Vi kunne også implementere vår egen tilpassede helseindikator, som kan samle alle typer tilpassede helsedata som er spesifikke for applikasjonen og automatisk eksponere dem gjennom /Helse sluttpunkt:

@Component ("myHealthCheck") offentlig klasse HealthCheck implementerer HealthIndicator {@Override public Health health () {int errorCode = check (); // utføre en spesifikk helsesjekk hvis (errorCode! = 0) {return Health.down () .withDetail ("Error Code", errorCode) .build (); } returner Health.up (). build (); } public int check () {// Vår logikk for å sjekke helse retur 0; }} 

Slik ser utgangen ut:

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

4.4. / info Endepunkt

Vi kan også tilpasse dataene som vises av / info sluttpunkt:

info.app.name = Våreksempel på applikasjon info.app.description = Dette er min første vårstartprogram applikasjon info.app.version = 1.0.0

Og prøveutgangen:

{"app": {"version": "1.0.0", "description": "Dette er min første vårstartprogram", "name": "Spring Sample Application"}}

4.5. / beregninger Endepunkt

Metrikkeendepunktet publiserer informasjon om OS og JVM samt beregningsnivåer på applikasjonsnivå. Når den er aktivert, får vi informasjon som minne, heap, prosessorer, tråder, klasser lastet, klasser ulastet og trådpooler sammen med noen HTTP-beregninger også.

Slik ser utgangen fra dette endepunktet ut av esken:

{"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 å samle egendefinerte beregninger har vi støtte for målere (enkeltverdige øyeblikksbilder av data) og tellere, dvs. økende / dekrementerende beregninger.

La oss implementere våre egne tilpassede beregninger i / beregninger endepunkt.

Vi tilpasser påloggingsflyten for å registrere et vellykket og mislykket påloggingsforsøk:

@Service offentlig klasse LoginServiceImpl {privat slutt CounterService counterService; offentlig LoginServiceImpl (CounterService counterService) {this.counterService = counterService; } offentlig boolsk pålogging (String userName, char [] password) {boolsk suksess; hvis (userName.equals ("admin") && "secret" .toCharArray (). er lik (passord)) {counterService.increment ("counter.login.success"); suksess = sant; } annet {counterService.increment ("counter.login.failure"); suksess = falsk; } returnere suksess; }}

Slik ser utgangen ut:

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

Merk at påloggingsforsøk og andre sikkerhetsrelaterte hendelser er tilgjengelige utenom boksen i Aktuator som revisjonshendelser.

4.6. Opprette et nytt endepunkt

I tillegg til å bruke de eksisterende endepunktene som tilbys av Spring Boot, kan vi også lage en helt ny.

Først må vi få det nye endepunktet til å implementere Endepunkt grensesnitt:

@Komponent offentlig klasse CustomEndpoint implementerer sluttpunkt {@Override public String getId () {return "customEndpoint"; } @Override public boolean isEnabled () {return true; } @Override public boolean isSensitive () {return true; } @Override public List påkalle () {// Tilpasset logikk for å bygge utdata Listmeldinger = ny ArrayList (); messages.add ("Dette er melding 1"); messages.add ("Dette er melding 2"); returnere meldinger; }}

For å få tilgang til dette nye endepunktet, er det id brukes til å kartlegge den. Med andre ord kan vi utøve det å slå / customEndpoint.

Produksjon:

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

4.7. Videre tilpasning

Av sikkerhetshensyn kan vi velge å eksponere aktuatorens endepunkter over en ikke-standard port - management.port egenskapen kan enkelt brukes til å konfigurere det.

Som vi allerede nevnte, i 1.x. Actuator konfigurerer sin egen sikkerhetsmodell basert på Spring Security, men uavhengig av resten av applikasjonen.

Derfor kan vi endre ledelse. adresse egenskap for å begrense hvor endepunktene kan nås fra over nettverket:

#port brukes til å avsløre aktuatoradministrasjon.port = 8081 #CIDR tillatt å treffe aktuatoradministrasjon. adresse = 127.0.0.1 # Om sikkerhet skal aktiveres eller deaktiveres helt management.security.enabled = false

Dessuten alle de innebygde endepunktene unntatt / info er følsomme som standard.

Hvis applikasjonen bruker Spring Security, kan vi sikre disse endepunktene ved å definere standard sikkerhetsegenskaper (brukernavn, passord og rolle) i application.properties fil:

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

5. Konklusjon

I denne artikkelen snakket vi om Spring Boot Actuator. Vi begynte med å definere hva aktuator betyr og hva det gjør for oss.

Deretter fokuserte vi på aktuator for den nåværende Spring Boot versjonen 2.x, og diskuterte hvordan du bruker den, tilpasser den og utvider den. Vi snakket også om viktige sikkerhetsendringer som vi kan finne i denne nye iterasjonen. Vi diskuterte noen populære endepunkter og hvordan de også har endret seg.

Så diskuterte vi Actuator i den tidligere Spring Boot 1-versjonen.

Til slutt demonstrerte vi hvordan du kan tilpasse og utvide aktuatoren.

Som alltid kan koden som brukes i denne artikkelen finnes på GitHub for både Spring Boot 2.x og Spring Boot 1.x.