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

This article mainly explains "how to use spring-boot-admin+nacos+prometheus+grafana to achieve monitoring closed loop", the content of the article is simple and clear, easy to learn and understand, now please follow the editor's ideas slowly in depth, together to study and learn "how to use spring-boot-admin+nacos+prometheus+grafana to achieve monitoring closed loop"!

cause

Recently learned to use spring-cloud-alibaba to integrate common components of various microservices

Ali open source

Dubbo sentinel rocketmq nacos seata

Spring official

Gateway sleuth

Shardingsphere of apache

Sharding-jdbc

Third-party open source monitoring spring-boot project

Spring-boot-admin

There are also some problems encountered during this period, one of which is that sharding-jdbc sub-table cooperates with seata to complete distributed transactions in dubbo services. Finally, it is solved by referring to the solution put forward by others above git, although it does not look very elegant, but it can also run well. It may be that there are still flaws in the performance, as the official said: sharding-jdbc and seata repeatedly parse sql. The specific change point is that in the class SpringBootConfiguration, cancel its automatic configuration, and then package the result of the getDataSource method as follows: seata

@ SuppressWarnings ("unchecked") private DataSource getDataSource (final Environment environment, final String prefix, final String dataSourceName) throws ReflectiveOperationException, NamingException {Map dataSourceProps = PropertyUtil.handle (environment, prefix + dataSourceName.trim (), Map.class); Preconditions.checkState (! dataSourceProps.isEmpty (), "Wrong datasource properties!"); if (dataSourceProps.containsKey (jndiName)) {return getJndiDataSource (dataSourceProps.get (jndiName). ToString ()) } / / add seata wrapper update at 09:04:22 on October 31, 2019 return new DataSourceProxy (DataSourceUtil.getDataSource ("type"). ToString (), dataSourceProps);}

After the above modules are integrated, you can easily pull services from nacos by adding spring-boot-admin module, but those data don't look intuitive in admin after all, so we consider adding prometheus and grafana to graph these data.

Let's get to the point.

The static integration of prometheus and grafana alone is not a big problem, and the configuration file can show the chart by writing a dead address, which is mainly the problem of how prometheus integrates nacos.

Prometheus officially has SD (service-discovery) module configuration, consul, but no nacos. In nacos's issues list, you can also see that someone has raised this issue. I also saw their proposal there, that is, I refer to the open source project eureka-consul-adapter.

Put this code clone down to follow the gourd painting, because I am not very familiar with eureka, so it took a long time to integrate with spring-boot-admin. The main changes are the two methods of the RegistrationService class, as follows

Public Single getServiceNames (long waitMillis, Long index) {return returnDeferredMap (waitMillis, index, serviceChangeDetector::getLastEmitted, serviceChangeDetector::getTotalIndex, ()-> {try {return registry.getServicesOfServer). GetData (). Stream () .duration (Collectors.toMap (Function.identity (), a-> NO_SERVICE_TAGS) MERGE_FUNCTION, TreeMap::new)) } catch (NacosException e) {log.error (e.getErrMsg (), e); return Collections.emptyMap ();}} } public Single getService (String appName, long waitMillis, Long index) {return returnDeferredList (waitMillis, index, ()-> serviceChangeDetector.getLastEmittedOfApp (appName), waitMillisInternal-> serviceChangeDetector.getIndexOfApp (appName, waitMillisInternal), ()-> {try {return registry.selectInstances (appName, true) } catch (NacosException e) {return Collections.emptyList ();}});}

The registry object should be able to guess that it is the NamingService object by looking at the method called.

The configuration file modification points for prometheus are as follows

Scrape_configs:-job_name: 'nacos-consul-adapter' scrape_interval: 20s static_configs: consul_sd_configs:-server:' 127.0.0.1 static_configs 8888 'relabel_configs:-source_labels: [' _ _ metrics_path__'] regex:'/ metrics' target_label: _ _ metrics_path__ replacement:'/ actuator/prometheus'

Consul_sd_configs is my spring-boot-admin address, because my nacos-to-consul translation is written directly in spring-boot-admin.

After the microservice is started, you can see something similar to the following on the admin console

Then under the prometheus menu: Status-Targets, you can see something similar to the following

Finally, you can see the monitoring chart in grafana (first configure prometheus data source and dashboard with an id of 4701)

End

In this way, the whole monitoring closed loop is maintained by nacos. Once the microservice connected to nacos is online, spring-boot-admin, prometheus and grafana can load data dynamically.

Thank you for reading, the above is the content of "how to use spring-boot-admin+nacos+prometheus+grafana to achieve monitoring closed-loop". After the study of this article, I believe you have a deeper understanding of how to use spring-boot-admin+nacos+prometheus+grafana to achieve monitoring closed-loop, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.