怎么用spring-boot-admin+nacos+prometheus+grafana实现监控闭环

这篇文章主要讲解了“怎么用spring-boot-admin+nacos+prometheus+grafana实现监控闭环”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么用spring-boot-admin+nacos+prometheus+grafana实现监控闭环”吧！

起因

最近学习使用spring-cloud-alibaba，集成各个微服务常用组件

1. 阿里开源的

• dubbo sentinel rocketmq nacos seata

2. spring官方的

• gateway sleuth

3. apache的shardingsphere

• sharding-jdbc

4. 第三方开源的监控spring-boot项目

• spring-boot-admin

期间也碰到了一些问题，其中一个就是sharding-jdbc分表配合seata来在dubbo服务中完成分布式事务。最后也是参考git上面别人提出的方案解决了，虽然看起来不怎么幽雅，但是也能跑通。可能就是性能上面还是有瑕疵，就如官方说的：sharding-jdbc和seata对sql重复解析的问题。具体改动点就是在类SpringBootConfiguration中，取消它的自动配置，然后把getDataSource方法的结果包装成seata的如下

    @SuppressWarnings("unchecked")
    private DataSource getDataSource(final Environment environment, final String prefix, final String dataSourceName) throws ReflectiveOperationException, NamingException {
        Map<String, Object> 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 2019年10月31日 09:04:22
        return new DataSourceProxy(DataSourceUtil.getDataSource(dataSourceProps.get("type").toString(), dataSourceProps));
    }

以上模块整合完毕之后，加入spring-boot-admin模块，可以很方便的从nacos中拉取服务，但是那些数据在admin中看起来终究不直观，于是就考虑着加入prometheus和grafana来图表化这些数据了。

正题开始

prometheus和grafana单独静态整合不是什么大的问题，配置文件写死地址即可展示图表了，主要就是prometheus如何集成nacos的问题。

prometheus官方是有SD（service-discovery）模块配置的，有consul的，但是没有nacos的，在nacos的issues列表里面也可以看到有人提出过这个问题，本人也是在那里看到了他们提出的方案，就是参考eureka-consul-adapter这个开源项目了。

把这个代码clone下来之后照着葫芦画瓢，由于我对于eureka也不是很熟悉，所以捣鼓了挺久的才和spring-boot-admin融合起来了。主要的改动点就是在RegistrationService这个类的俩方法，如下

    public Single<ChangeItem<Map<String, String[]>>> getServiceNames(long waitMillis, Long index) {
        return returnDeferredMap(waitMillis, index, serviceChangeDetector::getLastEmitted, serviceChangeDetector::getTotalIndex,
                () -> {
                    try {
                        return registry.getServicesOfServer(1,Integer.MAX_VALUE).getData().stream()
                                .collect(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<ChangeItem<List<Instance>>> 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();
                    }
                });
    }

其中的registry对象看调用的方法应该就能猜出来是NamingService对象了

prometheus的配置文件修改点如下

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

consul_sd_configs就是我的spring-boot-admin地址，因为我这边nacos到consul的转换直接写在spring-boot-admin中了。

微服务启动之后在admin控台就可以看见类似如下图示内容

然后在prometheus的菜单：Status-Targets下面可以看见类似如下图示内容

最后在grafana里面就可以看到监控图表了（先配置prometheus数据源和id为4701的dashboard）

结束

这样整个监控闭环就靠nacos维系起来了，一旦有接入nacos的微服务上线，spring-boot-admin、prometheus、grafana都能动态加载数据了

感谢各位的阅读，以上就是“怎么用spring-boot-admin+nacos+prometheus+grafana实现监控闭环”的内容了，经过本文的学习后，相信大家对怎么用spring-boot-admin+nacos+prometheus+grafana实现监控闭环这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！