Shulou(Shulou.com)06/02 Report--

This article mainly introduces how to solve the potential OOM problems of SpringBoot Actuator. It is very detailed and has a certain reference value. Interested friends must read it!

The background of this problem arises from the burying point of a function that needs to be online recently; the main performance is that memory usage has been increasing for a period of time after the application is launched.

The following figure shows the internal usage trend that can be seen locally through jconsole after the scene is retracted.

The actual environment is limited by configuration and the memory will not expand.

Background & problem

Application a uses rest template to call application b through http. When actuator,api is enabled in the application project, micrometer; is used. When client is called, actuator generates a metrics with a name of http.client.requests, and the tag of this metric contains the uri of the point target.

The interfaces provided by application b are roughly as follows:

@ RequestMapping ("test_query_params") public String test_query_params (@ RequestParam String value) {return value;} @ RequestMapping ("test_path_params/ {value}") public String test_path_params (@ PathVariable String value) {return value;}

Http://localhost:8080/api/test/test_query_params?value=

Http://localhost:8080/api/test/test_path_params/{value}_

It is expected that two metrics should be included in the collection result of metric. The main difference is that the uri in tag is different, one is api/test/test_query_params and the other is api/test/test_path_params/ {value}. In fact, judging from the metrics data obtained, there is a great difference. Take the metric of pathvariable as an example, the data are as follows:

Tag: "uri", values: ["/ api/test/test_path_params/glmapper58", "/ api/test/test_path_params/glmapper59", "/ api/test/test_path_params/glmapper54", "/ api/test/test_path_params/glmapper55", "/ api/test/test_path_params/glmapper56", "/ api/test/test_path_params/glmapper57", "/ api/test/test_path_params/glmapper50", "/ api/test/test_path_params/glmapper51" / api/test/test_path_params/glmapper52 "," / api/test/test_path_params/glmapper53 "," / api/test/test_path_params/glmapper47 "," / api/test/test_path_params/glmapper48 "," / api/test/test_path_params/glmapper49 "," / api/test/test_path_params/glmapper43 "," / api/test/test_path_params/glmapper44 "," / api/test/test_path_params/glmapper45 " / api/test/test_path_params/glmapper46 "," / api/test/test_path_params/glmapper40 "," / api/test/test_path_params/glmapper41 "," / api/test/test_path_params/glmapper42 "," / api/test/test_path_params/glmapper36 "," / api/test/test_path_params/glmapper37 "," / api/test/test_path_params/glmapper38 "," / api/test/test_path_params/glmapper39 " "/ api/test/test_path_params/glmapper32", "/ api/test/test_path_params/glmapper33", "/ api/test/test_path_params/glmapper34", "/ api/test/test_path_params/glmapper35", "/ api/test/test_path_params/glmapper30", "/ api/test/test_path_params/glmapper31", "/ api/test/test_path_params/glmapper25", "/ api/test/test_path_params/glmapper26",....]

You can clearly see that the {value} parameter is part of the uri component and is reflected in the tag, which is not the expected api/test/test_path_params/ {value}.

The cause of the problem and its solution

Two questions: 1. How does this burial site take effect? first, we can figure out this problem before we can get a feel for it. 2. How to solve the problem.

How does the default burial point work?

Because the call access is made through resttemplate, then the embedding point must also be based on the proxy to resttemplate; according to this line of thinking, the author found the class org.springframework.boot.actuate.metrics.web.client.MetricsRestTemplateCustomizer. RestTemplateCustomizer is customized to resttemplate, and MetricsRestTemplateCustomizer can also know by name that the purpose of the phase is to add metric capabilities to resttemplate.

Turning to RestTemplateCustomizer, when you use RestTemplateBuilder to build RestTemplate, you can make more advanced customizations through RestTemplateCustomizer, and all RestTemplateCustomizer beans will be automatically added to the automatically configured RestTemplateBuilder. That is, if you want MetricsRestTemplateCustomizer to take effect, then building resttemplate must be built through RestTemplateBuilder instead of direct new.

Uri in http.client.requests

The code that plugs tag is in the org.springframework.boot.actuate.metrics.web.client.RestTemplateExchangeTags class, and the timing is in the MetricsClientHttpRequestInterceptor interceptor. When the call is executed, the request metric is recorded, and here the RestTemplateExchangeTags is used to populate the tags. Only part of the code for uri is given below

/ * * Creates a {@ code uri} {@ code Tag} for the URI of the given {@ code request}. * @ param request the request * @ return the uri tag * / public static Tag uri (HttpRequest request) {return Tag.of ("uri", ensureLeadingSlash (stripUri (request.getURI (). ToString ();} / * * Creates a {@ code uri} {@ code Tag} from the given {@ code uriTemplate}. * @ param uriTemplate the template * @ return the uri tag * / public static Tag uri (String uriTemplate) {String uri = (StringUtils.hasText (uriTemplate)? UriTemplate: "none"); return Tag.of ("uri", ensureLeadingSlash (stripUri (uri)

The rest are tag name, such as status and clientName.

Through the breakpoint, you can see that what request.getURI () gets here is the complete request link with parameters.

The assembly of these tag is finally done in DefaultRestTemplateExchangeTagsProvider and returns a list.

Private Timer.Builder getTimeBuilder (HttpRequest request, ClientHttpResponse response) {return this.autoTimer.builder (this.metricName) / / tagProvider is DefaultRestTemplateExchangeTagsProvider. Tags (this.tagProvider.getTags (urlTemplate.get (). Poll (), request, response) .description ("Timer of RestTemplate operation");} solve

Let's first take a look at the official explanation of request.getURI.

/ * * Return the URI of the request (including a query string if any, * but only if it is well-formed for a URI representation). * @ return the URI of the request (never {@ code null}) * / URI getURI ()

Returns the URI of the request, which includes any query parameters. So is it all right to get the path without parameters?

Here you try to get the expected path through request.getURI (). GetPath () (@ pathvariable gets the template).

Back to DefaultRestTemplateExchangeTagsProvider, all the tag is assembled here. This class is obviously a default implementation (basically, as long as it is Defaultxxx in Spring system, it can be extended). Check its API class RestTemplateExchangeTagsProvider as follows:

/ * * Provides {@ link Tag Tags} for an exchange performed by a {@ link RestTemplate}. * * @ author Jon Schneider * @ author Andy Wilkinson * @ since 2.0.0 * / @ FunctionalInterfacepublic interface RestTemplateExchangeTagsProvider {/ * Provides the tags to be associated with metrics that are recorded for the given * {@ code request} and {@ code response} exchange. * @ param urlTemplate the source URl template, if available * @ param request the request * @ param response the response (may be {@ code null} if the exchange failed) * @ return the tags * / Iterable getTags (String urlTemplate, HttpRequest request, ClientHttpResponse response);}

The purpose of RestTemplateExchangeTagsProvider is to provide tag for resttemplate, so here we can achieve our goal by customizing a RestTemplateExchangeTagsProvider to replace DefaultRestTemplateExchangeTagsProvider. The code is as follows:

@ Override public Iterable getTags (String urlTemplate, HttpRequest request, ClientHttpResponse response) {Tag uriTag; / / take request.getURI (). GetPath () as the value if of uri (StringUtils.hasText (request.getURI (). GetPath ()) {uriTag = Tag.of ("uri", ensureLeadingSlash (stripUri (request.getURI (). GetPath ();} else {uriTag = (StringUtils.hasText (urlTemplate)? RestTemplateExchangeTags.uri (urlTemplate): RestTemplateExchangeTags.uri (request);} return Arrays.asList (RestTemplateExchangeTags.method (request), uriTag, RestTemplateExchangeTags.status (response), RestTemplateExchangeTags.clientName (request));} whether OOM

In theory, the parameters should be different. In the case of using the default DefaultRestTemplateExchangeTagsProvider, meter will expand rapidly with different tags. In micrometer, these data are stored in map.

/ / Even though writes are guarded by meterMapLock, iterators across value space are supported// Hence, we use CHM to support that iteration without ConcurrentModificationException riskprivate final Map meterMap = new ConcurrentHashMap ()

Normally, not. This is because spring boot actuator provides its own protection mechanism. By default, there are only 100 tags under the same metric.

/ * Maximum number of unique URI tag values allowed. After the max number of* tag values is reached, metrics with additional tag values are denied by* filter.*/private int maxUriTags = 100,

If you want to make this number larger, you can configure it as follows

Management.metrics.web.client.max-uri-tags=10000

If the configuration value is too large, there is a potential oom risk.

The above is all the contents of the article "how to solve the potential OOM problems in SpringBoot Actuator". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.