streamalism.org

1. Overzicht

In dit artikel introduceren we de Spring Boot Actuator. We behandelen eerst de basisprincipes en bespreken vervolgens in detail wat er beschikbaar is in Spring Boot 2.x vs 1.x.

We zullen leren hoe we deze monitoringtool kunnen gebruiken, configureren en uitbreiden in Spring Boot 2.x en WebFlux, gebruikmakend van het reactieve programmeermodel. Vervolgens bespreken we hoe u hetzelfde kunt doen met Boot 1.x.

Spring Boot Actuator is beschikbaar sinds april 2014, samen met de eerste Spring Boot-release.

Met de release van Spring Boot 2 is Actuator opnieuw ontworpen en zijn er nieuwe opwindende eindpunten toegevoegd.

We hebben deze gids opgesplitst in drie hoofdsecties:

• Wat is een actuator?
• Veerboot 2.x Actuator
• Veerboot 1.x Actuator

2. Wat is een actuator?

In wezen brengt Actuator productieklare functies naar onze applicatie.

Het monitoren van onze app, het verzamelen van statistieken, het begrijpen van verkeer of de status van onze database wordt met deze afhankelijkheid triviaal.

Het belangrijkste voordeel van deze bibliotheek is dat we tools van productiekwaliteit kunnen krijgen zonder deze functies zelf te hoeven implementeren.

Actuator wordt voornamelijk gebruikt open operationele informatie over de actieve applicatie - gezondheid, metrische gegevens, info, dump, env, enz. Het gebruikt HTTP-eindpunten of JMX-bonen om ons in staat te stellen ermee te communiceren.

Zodra deze afhankelijkheid van het klassenpad is, zijn verschillende eindpunten uit de doos voor ons beschikbaar. Zoals met de meeste Spring-modules, kunnen we deze eenvoudig op vele manieren configureren of uitbreiden.

2.1. Beginnen

Om Spring Boot Actuator in te schakelen, hoeven we alleen de veer-boot-actuator afhankelijkheid van onze pakketbeheerder.

In Maven:

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

Merk op dat dit geldig blijft ongeacht de Boot-versie, aangezien versies worden gespecificeerd in de Spring Boot Bill of Materials (BOM).

3. Veerboot 2.x Actuator

In 2.x behoudt Actuator zijn fundamentele bedoeling, maar vereenvoudigt hij zijn model, breidt hij zijn mogelijkheden uit en neemt hij betere standaardinstellingen op.

Ten eerste wordt deze versie technologie-agnostisch. Het vereenvoudigt ook het beveiligingsmodel door het samen te voegen met het toepassingsmodel.

Van de verschillende wijzigingen is het belangrijk om in gedachten te houden dat sommige ervan kapot gaan. Dit omvat zowel HTTP-verzoeken en -antwoorden als Java-API's.

Ten slotte ondersteunt de nieuwste versie nu het CRUD-model in tegenstelling tot het oude lees / schrijf-model.

3.1. Technologie ondersteuning

Met zijn tweede hoofdversie is Actuator nu technologie-agnostisch, terwijl het in 1.x was gekoppeld aan MVC, dus aan de Servlet API.

In 2.x definieert Actuator zijn model als pluggable en uitbreidbaar zonder hiervoor op MVC te vertrouwen.

Daarom kunnen we met dit nieuwe model profiteren van zowel MVC als WebFlux als onderliggende webtechnologie.

Bovendien zouden toekomstige technologieën kunnen worden toegevoegd door de juiste adapters te implementeren.

Ten slotte blijft JMX ondersteund om eindpunten bloot te leggen zonder enige aanvullende code.

3.2. Belangrijke wijzigingen

In tegenstelling tot eerdere versies, Actuator wordt geleverd met de meeste eindpunten uitgeschakeld.

De enige twee die standaard beschikbaar zijn, zijn dus /Gezondheid en / info.

Als we ze allemaal willen inschakelen, kunnen we instellen management.endpoints.web.exposure.include = *. Als alternatief kunnen we eindpunten vermelden die moeten worden ingeschakeld.

Actuator deelt nu de beveiligingsconfiguratie met de reguliere app-beveiligingsregels, dus het beveiligingsmodel is drastisch vereenvoudigd.

Om de beveiligingsregels van Actuator aan te passen, kunnen we daarom gewoon een vermelding toevoegen voor / aandrijving / **:

@Bean public SecurityWebFilterChain securityWebFilterChain (ServerHttpSecurity http) {return http.authorizeExchange () .pathMatchers ("/ actuator / **"). AllowAll () .anyExchange (). Geverifieerd (). En (). Build (); }

We kunnen meer details vinden in de gloednieuwe officiële documenten van Actuator.

Ook, standaard worden alle Actuator-eindpunten nu onder de / aandrijving pad.

Hetzelfde als in de vorige versie, we kunnen dit pad aanpassen met de nieuwe eigenschap management.endpoints.web.base-path.

3.3. Vooraf gedefinieerde eindpunten

Laten we eens kijken naar enkele beschikbare eindpunten, waarvan de meeste al in 1.x beschikbaar waren.

Ook, sommige eindpunten zijn toegevoegd, sommige verwijderd en sommige zijn geherstructureerd:

• / auditevents geeft een overzicht van gebeurtenissen met betrekking tot beveiligingsaudits, zoals het inloggen / uitloggen van gebruikers. We kunnen ook filteren op principal of type onder andere velden.
• /bonen retourneert alle beschikbare bonen in ons BeanFactory. in tegenstelling tot / auditevents, het ondersteunt geen filtering.
• /voorwaarden, voorheen bekend als /autoconfig, bouwt een rapport van voorwaarden rond autoconfiguratie.
• / configprops stelt ons in staat om alles te halen @ConfigurationProperties bonen.
• / env geeft de huidige omgevingseigenschappen terug. Bovendien kunnen we enkele eigenschappen ophalen.
• / flyway geeft details over onze Flyway-databasemigraties.
• /Gezondheid vat de gezondheidsstatus van onze applicatie samen.
• / heapdump bouwt en retourneert een heap-dump van de JVM die door onze applicatie wordt gebruikt.
• / info geeft algemene informatie terug. Het kunnen aangepaste gegevens zijn, build-informatie of details over de laatste commit.
• / liquibase gedraagt ​​zich als / flyway maar voor Liquibase.
• / logbestand geeft gewone toepassingslogboeken terug.
• / loggers stelt ons in staat om het registratieniveau van onze applicatie op te vragen en te wijzigen.
• / metrics gedetailleerde statistieken van onze applicatie. Dit kunnen zowel algemene als aangepaste statistieken zijn.
• /Prometheus retourneert metrische gegevens zoals de vorige, maar geformatteerd om te werken met een Prometheus-server.
• /geplande taken geeft details over elke geplande taak binnen onze applicatie.
• / sessies geeft een lijst van HTTP-sessies, aangezien we Spring Session gebruiken.
• /afsluiten voert een elegante afsluiting van de applicatie uit.
• / threaddump dumpt de thread-informatie van de onderliggende JVM.

3.4. Hypermedia voor actuator-eindpunten

Spring Boot voegt een discovery-eindpunt toe dat koppelingen naar alle beschikbare actuator-eindpunten retourneert. Dit zal het ontdekken van actuator-eindpunten en hun bijbehorende URL's vergemakkelijken.

Dit detectie-eindpunt is standaard toegankelijk via het / aandrijving eindpunt.

Daarom, als we een KRIJGEN verzoek naar deze URL, retourneert het de actuatorlinks voor de verschillende eindpunten:

{"_links": {"self": {"href": "// localhost: 8080 / actuator", "templated": false}, "features-arg0": {"href": "// localhost: 8080 / actuator / 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} "," sjabloon ": true}, // afgekapt}

Zoals hierboven getoond, is de / aandrijving endpoint rapporteert alle beschikbare actuator-eindpunten onder de _links veld.

Als we bovendien een aangepast beheerbasispad configureren, moeten we dat basispad gebruiken als de detectie-URL.

Als we bijvoorbeeld de management.endpoints.web.base-path naar / mgmt, dan moeten we een verzoek sturen naar de / mgmt eindpunt om de lijst met links te zien.

Interessant is dat wanneer het beheerbasispad is ingesteld op /is het detectie-eindpunt uitgeschakeld om de mogelijkheid van een botsing met andere toewijzingen te voorkomen.

3.5. Gezondheidsindicatoren

Net als in de vorige versie kunnen we eenvoudig aangepaste indicatoren toevoegen. In tegenstelling tot andere API's blijven de abstracties voor het maken van aangepaste gezondheidseindpunten ongewijzigd. Echter, een nieuwe interface, ReactiveHealthIndicator, is toegevoegd om reactieve gezondheidscontroles uit te voeren.

Laten we eens kijken naar een eenvoudige aangepaste reactieve gezondheidscontrole:

@Component public class DownstreamServiceHealthIndicator implementeert ReactiveHealthIndicator {@Override public Mono health () {return checkDownstreamServiceHealth (). OnErrorResume (ex -> Mono.just (new Health.Builder (). Down (ex) .build ())); } private Mono checkDownstreamServiceHealth () {// we zouden WebClient kunnen gebruiken om de gezondheid reactief te controleren Mono.just (nieuwe Health.Builder (). up (). build ()); }}

Een handig kenmerk van gezondheidsindicatoren is dat we ze kunnen aggregeren als onderdeel van een hiërarchie.

Dus, volgens het vorige voorbeeld, zouden we alle downstream-services kunnen groeperen onder een stroomafwaarts-Diensten categorie. Deze categorie zou gezond zijn zolang elke geneste onderhoud was bereikbaar.

Bekijk ons ​​artikel over gezondheidsindicatoren voor een meer diepgaande blik.

3.6. Gezondheidsgroepen

Vanaf Spring Boot 2.2 kunnen we gezondheidsindicatoren in groepen indelen en dezelfde configuratie toepassen op alle groepsleden.

We kunnen bijvoorbeeld een gezondheidsgroep maken met de naam Op maat door dit toe te voegen aan onze application.properties:

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

Op deze manier kan de Op maat groep bevat de diskSpace en ping gezondheidsindicatoren.

Als we nu de / actuator / gezondheid eindpunt, zou het ons vertellen over de nieuwe gezondheidsgroep in het JSON-antwoord:

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

Bij gezondheidsgroepen kunnen we de geaggregeerde resultaten van enkele gezondheidsindicatoren zien.

Als we in dit geval een verzoek sturen naar / actuator / health / custom, dan:

{"status": "UP"}

We kunnen de groep configureren om meer details te tonen via application.properties:

management.endpoint.health.group.custom.show-componenten = altijd management.endpoint.health.group.custom.show-details = altijd

Als we nu hetzelfde verzoek sturen naar / actuator / health / custom, we zullen meer details zien:

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

Het is ook mogelijk om deze gegevens alleen voor geautoriseerde gebruikers weer te geven:

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

We kunnen ook een aangepaste statustoewijzing hebben.

In plaats van een HTTP 200 OK-antwoord kan het bijvoorbeeld een 207-statuscode retourneren:

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

Hier vertellen we Spring Boot om een ​​207 HTTP-statuscode te retourneren als het Op maat groepsstatus is UP.

3.7. Statistieken in Spring Boot 2

In Spring Boot 2.0 werden de interne statistieken vervangen door Micrometer-ondersteuning, dus we kunnen ingrijpende veranderingen verwachten. Als onze applicatie metrische services gebruikte, zoals GaugeService of CounterService, zullen ze niet langer beschikbaar zijn.

In plaats daarvan wordt van ons verwacht dat we rechtstreeks met Micrometer communiceren. In Spring Boot 2.0 krijgen we een soort boon MeterRegistry automatisch voor ons geconfigureerd.

Bovendien maakt Micrometer nu deel uit van Actuator's afhankelijkheden, dus we zouden goed moeten zijn zolang de Actuator-afhankelijkheid zich in het klassenpad bevindt.

Bovendien krijgen we een geheel nieuwe reactie van het / metrics eindpunt:

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

Zoals we kunnen zien, zijn er geen daadwerkelijke statistieken zoals we in 1.x hebben gekregen.

Om de werkelijke waarde van een specifieke metriek te krijgen, kunnen we nu naar de gewenste metriek navigeren, bijvoorbeeld /actuator/metrics/jvm.gc.pause, en ontvang een gedetailleerd antwoord:

{"naam": "jvm.gc.pause", "metingen": [{"statistic": "Count", "value": 3.0}, {"statistic": "TotalTime", "value": 7.9E7} , {"statistic": "Max", "value": 7.9E7}], "availableTags": [{"tag": "cause", "values": ["Metadata GC Threshold", "Allocation Failure"]} , {"tag": "action", "values": ["einde van kleine GC", "einde van grote GC"]}]}

Nu zijn de statistieken veel grondiger, inclusief niet alleen verschillende waarden, maar ook enkele bijbehorende metadata.

3.8. Het / info Eindpunt

De / info eindpunt blijft ongewijzigd. Zoals eerder kunnen we git-details toevoegen met behulp van de respectieve Maven- of Gradle-afhankelijkheid:

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

Hetzelfde, we kunnen ook build-informatie opnemen, inclusief naam, groep en versie, met behulp van de Maven- of Gradle-plug-in:

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

3.9. Een aangepast eindpunt maken

Zoals we eerder hebben aangegeven, kunnen we aangepaste eindpunten maken. Spring Boot 2 heeft de manier om dit te bereiken echter opnieuw ontworpen om het nieuwe technologie-agnostische paradigma te ondersteunen.

Laten we een Actuator-eindpunt maken om functievlaggen in onze applicatie op te vragen, in te schakelen en uit te schakelen:

@Component @Endpoint (id = "features") openbare klasse FeaturesEndpoint {private Map features = new ConcurrentHashMap (); @ReadOperation openbare kaartfuncties () {retourneer functies; } @ReadOperation public Feature feature (@Selector String naam) {return features.get (name); } @WriteOperation public void configureFeature (@Selector String naam, Feature feature) {features.put (naam, feature); } @DeleteOperation openbare ongeldige deleteFeature (@Selector String naam) {features.remove (naam); } openbare statische klasse Feature {private Boolean ingeschakeld; // [...] getters en setters}}

Om het eindpunt te krijgen, hebben we een boon nodig. In ons voorbeeld gebruiken we @Component voor deze. We moeten deze boon ook versieren @Eindpunt.

Het pad van ons eindpunt wordt bepaald door de ID kaart parameter van @Eindpunt. In ons geval worden verzoeken doorgestuurd naar / actuator / features.

Als we klaar zijn, kunnen we beginnen met het definiëren van bewerkingen met behulp van:

• @ReadOperation: Het wordt toegewezen aan HTTP KRIJGEN.
• @WriteOperation: Het wordt toegewezen aan HTTP POST.
• @DeleteOperation: Het wordt toegewezen aan HTTP VERWIJDEREN.

Wanneer we de applicatie uitvoeren met het vorige eindpunt in onze applicatie, registreert Spring Boot deze.

Een snelle manier om dit te verifiëren, is door de logboeken te controleren:

[...]. WebFluxEndpointHandlerMapping: Mapped "{[/ actuator / features / {name}], methodes = [GET], produceert = [application / vnd.spring-boot.actuator.v2 + json || application / json] } "[...]. WebFluxEndpointHandlerMapping: Mapped" application / json] "[...]. WebFluxEndpointHandlerMapping: Mapped" {[/ actuator / features / {name}], methodes = [POST], verbruikt = [applicatie / vnd.spring-boot.actuator.v2 + json || application / json]} "[...]. WebFluxEndpointHandlerMapping: Mapped" {[/ actuator / features / {naam}], methodes = [DELETE]} "[. ..]

In de vorige logboeken kunnen we zien hoe WebFlux ons nieuwe eindpunt blootlegt. Als we overschakelen naar MVC, delegeert het eenvoudigweg aan die technologie zonder enige code te hoeven wijzigen.

We hebben ook een paar belangrijke overwegingen om in gedachten te houden bij deze nieuwe aanpak:

• Er zijn geen afhankelijkheden met MVC.
• Alle metadata aanwezig als methoden vóór (gevoelig, ingeschakeld ...) bestaat niet meer. We kunnen het eindpunt echter in- of uitschakelen met @Endpoint (id = "features", enableByDefault = false).
• In tegenstelling tot 1.x is het niet meer nodig om een ​​bepaalde interface uit te breiden.
• In tegenstelling tot het oude lees / schrijf-model kunnen we nu definiëren VERWIJDEREN operaties met @DeleteOperation.

3.10. Bestaande eindpunten uitbreiden

Laten we ons voorstellen dat we zeker willen weten dat de productie-instantie van onze applicatie nooit een MOMENTOPNAME versie.

We besluiten dit te doen door de HTTP-statuscode te wijzigen van het Actuator-eindpunt dat deze informatie retourneert, d.w.z. / info. Als onze app toevallig een MOMENTOPNAME, zouden we een andere krijgen HTTP status code.

We kunnen het gedrag van een vooraf gedefinieerd eindpunt eenvoudig uitbreiden met de @EndpointExtension annotaties, of zijn meer concrete specialisaties @EndpointWebExtension of @EndpointJmxExtension:

@Component @EndpointWebExtension (endpoint = InfoEndpoint.class) openbare klasse InfoWebEndpointExtension {privé InfoEndpoint-gemachtigde; // standaard constructor @ReadOperation openbare WebEndpointResponse info () {Map info = this.delegate.info (); Geheel getal status = getStatus (info); retourneer nieuwe WebEndpointResponse (info, status); } private Integer getStatus (Map info) {// return 5xx als dit een snapshot is, retourneer 200; }}

3.11. Schakel alle eindpunten in

Om toegang te krijgen tot de actuator-eindpunten met behulp van HTTP, moeten we ze zowel inschakelen als vrijgeven.

Standaard zijn alle eindpunten maar /afsluiten zijn ingeschakeld. Alleen de /Gezondheid en / info eindpunten worden standaard weergegeven.

We moeten de volgende configuratie toevoegen om alle eindpunten zichtbaar te maken:

management.endpoints.web.exposure.include = *

Om expliciet een specifiek eindpunt in te schakelen (bijv. /afsluiten), we gebruiken:

management.endpoint.shutdown.enabled = true

Om alle ingeschakelde eindpunten weer te geven behalve één (bijv. / loggers), we gebruiken:

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

4. Veerboot 1.x Actuator

In 1.x volgt Actuator een lees- / schrijfmodel, wat betekent dat we ervan kunnen lezen of ernaar kunnen schrijven.

We kunnen bijvoorbeeld metrics of de gezondheid van onze applicatie opvragen. Als alternatief kunnen we onze app netjes beëindigen of onze logboekconfiguratie wijzigen.

Om het te laten werken, vereist Actuator Spring MVC om zijn eindpunten via HTTP bloot te stellen. Geen enkele andere technologie wordt ondersteund.

4.1. Eindpunten

In 1.x brengt Actuator zijn eigen beveiligingsmodel. Het maakt gebruik van Spring Security-constructies, maar moet onafhankelijk van de rest van de applicatie worden geconfigureerd.

Bovendien zijn de meeste eindpunten gevoelig - wat betekent dat ze niet volledig openbaar zijn, of de meeste informatie zal worden weggelaten - terwijl een handvol dat niet is, bijv. / info.

Hier zijn enkele van de meest voorkomende endpoints die Boot uit de doos biedt:

• /Gezondheid toont informatie over de status van de applicatie (een simpele toestand bij toegang via een niet-geverifieerde verbinding of volledige berichtdetails wanneer geauthenticeerd); het is standaard niet gevoelig.
• / info geeft willekeurige applicatie-info weer; het is standaard niet gevoelig.
• / metrics toont metrische informatie voor de huidige applicatie; het is standaard gevoelig.
• /spoor geeft traceerinformatie weer (standaard de laatste paar HTTP-verzoeken).

We kunnen de volledige lijst met bestaande eindpunten vinden in de officiële documenten.

4.2. Bestaande eindpunten configureren

We kunnen elk eindpunt aanpassen met eigenschappen met behulp van het formaat eindpunten. [naam eindpunt]. [aan te passen eigenschap].

Er zijn drie eigenschappen beschikbaar:

• ID kaart: waarmee dit eindpunt wordt benaderd via HTTP
• ingeschakeld: indien waar, dan is het toegankelijk; anders niet
• gevoelig: indien waar, dan heb je de autorisatie nodig om cruciale informatie via HTTP weer te geven

Als u bijvoorbeeld de volgende eigenschappen toevoegt, wordt de /bonen eindpunt:

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

4.3. /Gezondheid Eindpunt

De /Gezondheid endpoint wordt gebruikt om de gezondheid of status van de actieve applicatie te controleren.

Het wordt meestal uitgeoefend door software te bewaken om ons te waarschuwen als de actieve instantie uitvalt of om andere redenen ongezond wordt, bijvoorbeeld verbindingsproblemen met onze database, gebrek aan schijfruimte, enz.

Standaard kunnen onbevoegde gebruikers alleen statusinformatie zien wanneer ze toegang hebben via HTTP:

{"status": "UP"} 

Deze gezondheidsinformatie wordt verzameld van alle bonen die het Gezondheidsindicator interface geconfigureerd in onze applicatiecontext.

Sommige informatie is geretourneerd door Gezondheidsindicator is gevoelig van aard, maar we kunnen configureren endpoints.health.sensitive = false om meer gedetailleerde informatie te onthullen, zoals schijfruimte, connectiviteit van messaging broker, aangepaste controles en meer.

Merk op dat dit alleen werkt voor Spring Boot-versies lager dan 1.5.0. Voor 1.5.0 en latere versies moeten we de beveiliging ook uitschakelen door in te stellen management.security.enabled = false voor ongeautoriseerde toegang.

We zouden ook kunnen implementeren van onze eigen aangepaste gezondheidsindicator, die elk type aangepaste gezondheidsgegevens kan verzamelen die specifiek zijn voor de toepassing en deze automatisch beschikbaar stellen via het /Gezondheid eindpunt:

@Component ("myHealthCheck") openbare klasse HealthCheck implementeert HealthIndicator {@Override public Health health () {int errorCode = check (); // voer een specifieke gezondheidscontrole uit als (errorCode! = 0) {return Health.down () .withDetail ("Error Code", errorCode) .build (); } Return Health.up (). build (); } public int check () {// Onze logica om health return 0 te controleren; }} 

Dit is hoe de uitvoer eruit zou zien:

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

4.4. / info Eindpunt

We kunnen ook de gegevens aanpassen die worden weergegeven door de / info eindpunt:

info.app.name = Spring-voorbeeldtoepassing info.app.description = Dit is mijn eerste lente-opstarttoepassing info.app.version = 1.0.0

En de voorbeelduitvoer:

{"app": {"version": "1.0.0", "description": "Dit is mijn eerste lente-opstarttoepassing", "name": "Spring-voorbeeldtoepassing"}}

4.5. / metrics Eindpunt

Het metrics-endpoint publiceert informatie over OS en JVM, evenals metrics op applicatieniveau. Eenmaal ingeschakeld, krijgen we informatie zoals geheugen, heap, processors, threads, geladen klassen, geloste klassen en threadpools, samen met enkele HTTP-statistieken.

Dit is hoe de uitvoer van dit eindpunt er uit de doos uitziet:

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

Om aangepaste metrische gegevens te verzamelen, hebben we ondersteuning voor meters (momentopnamen van gegevens met één waarde) en tellers, d.w.z. metrische gegevens verhogen / verlagen.

Laten we onze eigen aangepaste statistieken implementeren in het / metrics eindpunt.

We zullen de inlogstroom aanpassen om een ​​geslaagde en mislukte inlogpoging vast te leggen:

@Service openbare klasse LoginServiceImpl {privé definitief CounterService counterService; openbare LoginServiceImpl (CounterService counterService) {this.counterService = counterService; } openbare booleaanse login (String gebruikersnaam, char [] wachtwoord) {booleaans succes; if (userName.equals ("admin") && "secret" .toCharArray (). equals (wachtwoord)) {counterService.increment ("counter.login.success"); succes = waar; } else {counterService.increment ("counter.login.failure"); success = false; } succes teruggeven; }}

Hier is hoe de uitvoer eruit zou kunnen zien:

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

Merk op dat inlogpogingen en andere beveiligingsgerelateerde gebeurtenissen standaard beschikbaar zijn in Actuator als auditgebeurtenissen.

4.6. Een nieuw eindpunt maken

Naast het gebruik van de bestaande endpoints van Spring Boot, kunnen we ook een geheel nieuwe maken.

Ten eerste moeten we het nieuwe eindpunt het Eindpunt koppel:

@Component openbare klasse CustomEndpoint implementeert Endpoint {@Override public String getId () {return "customEndpoint"; } @Override public boolean isEnabled () {return true; } @Override public boolean isSensitive () {return true; } @Override public List invoke () {// Aangepaste logica om de output List messages op te bouwen = new ArrayList (); messages.add ("Dit is bericht 1"); messages.add ("Dit is bericht 2"); berichten terugsturen; }}

Om toegang te krijgen tot dit nieuwe eindpunt, zijn ID kaart wordt gebruikt om het in kaart te brengen. Met andere woorden, we zouden het kunnen oefenen om te slaan / customEndpoint.

Uitgang:

["Dit is bericht 1", "Dit is bericht 2"]

4.7. Verdere aanpassing

Om veiligheidsredenen kunnen we ervoor kiezen om de actuator-eindpunten bloot te stellen via een niet-standaard poort - de management.port property kan eenvoudig worden gebruikt om dat te configureren.

Zoals we al zeiden, in 1.x. Actuator configureert zijn eigen beveiligingsmodel op basis van Spring Security, maar onafhankelijk van de rest van de applicatie.

Daarom kunnen we de management.adres eigenschap om te beperken waar de eindpunten toegankelijk zijn via het netwerk:

#poort gebruikt om actuatorbeheer bloot te leggen. poort = 8081 #CIDR toegestaan ​​om actuatorbeheer te raken.address = 127.0.0.1 #Of beveiliging moet worden in- of uitgeschakeld management.security.enabled = false

Trouwens, alle ingebouwde eindpunten behalve / info zijn standaard gevoelig.

Als de applicatie Spring Security gebruikt, kunnen we deze endpoints beveiligen door de standaard beveiligingseigenschappen (gebruikersnaam, wachtwoord en rol) te definiëren in de application.properties het dossier:

security.user.name = beheerder security.user.password = geheim beheer.security.role = SUPERUSER

5. Conclusie

In dit artikel hebben we het gehad over Spring Boot Actuator. We zijn begonnen met te definiëren wat Actuator betekent en wat het voor ons doet.

Vervolgens hebben we ons gericht op Actuator voor de huidige Spring Boot-versie 2.x, waarbij we bespraken hoe we deze konden gebruiken, aanpassen en uitbreiden. We hebben ook gesproken over de belangrijke beveiligingsveranderingen die we in deze nieuwe iteratie kunnen vinden. We hebben enkele populaire eindpunten besproken en hoe deze ook zijn veranderd.

Toen bespraken we Actuator in de eerdere Spring Boot 1-versie.

Ten slotte hebben we laten zien hoe u Actuator kunt aanpassen en uitbreiden.

Zoals altijd is de code die in dit artikel wordt gebruikt, te vinden op GitHub voor zowel Spring Boot 2.x als Spring Boot 1.x.