Nacos+Prometheus+Grafana监控Spring Cloud微服务
Nacos+Prometheus+Grafana监控Spring Cloud微服务前言踩坑Spring Boot Admin使用Prometheus官方SD配置伪装为Consul新Nacos Consul Adapter快速开始总结前言本问要讲的不是使用Prometheus+Grafana监控Nacos服务本身,而是监控注册在Nacos中的服务。Prometheus和Grafana的整合网上有很多
目前最新的版本为0.0.5.M,访问nacos-consul-adapter获取最新的版本信息。
前言
本问要讲的不是使用Prometheus+Grafana监控Nacos服务本身,而是监控注册在Nacos中的服务。Prometheus和Grafana的整合网上有很多教程也就不在详细介绍了,本篇的主要内容是注册在Nacos中的服务如何被Prometheus自动监控,不需要在Prometheus中为每个微服务单独的进行配置。
踩坑Spring Boot Admin
在进行Prometheus整合Nacos之前也尝试过使用Spring Boot Admin对Spring Cloud中的服务进行监控,也确实可以做到。只是Spring Admin没有对数据进行持久化,图表也没有Grafana丰富。当时的想法是:可不可以将Spring Boot Admin从各个服务获取的数据持久化使用Prometheus持久化然后使用Grafana进行监控。按照这个思路在网上搜罗了一圈,这个方案的实现没有发现,倒是发现了一个新大陆–使用Prometheus的官方SD(Service Discovery)配置模块。
使用Prometheus官方SD配置
是不是以为我们在Prometheus中配置一下注册中心的地址就可以监控到Nacos中的服务了,现实是只有Consul才这么方便。Prometheus官方只提供了Consul的配置,当然可能是只有Consul提供了对外的服务接口的原因才只支持Consul。看到这里的同学可能有些疑问,既然Prometheus只支持Consul为注册中心的服务发现配置,这篇博客是关于Nacos的,Nacos不能使用Prometheus的配置弄了半天是不是又踩坑了?确实是又踩坑了。聪明的同学可能发现了一点端倪,Prometheus是通过Consul对外提供的接口获取注册在Consul中服务的信息,那我们是不是也可以在服务中以相同的接口给Prometheus返回服务信息,将自己伪装成一个Consul服务器节点。这样就可以使用Prometheus配置Consul那样配置我们的假Consul服务器节点。
伪装为Consul
在设计模式中的Adapter也是类似的思想。Prometheus只支持Consul的接口,但是Nacos未提供这些接口,但是Nacos是可以取到这些信息。所以需要一个中间层将Nacos的数据转换为Prometheus可以识别的。在GitHub上有大佬开源了Eureka的实现方式,也有大佬提供了Nacos的方式。Nacos我去使用的时候发现Nacos的过时了,Consul在某个版本修改了接口,所以之前开源的使用会报错了。最后笔者参考Eureka的实现方式重写了Nacos的实现方式并进行了开源。
新Nacos Consul Adapter
笔者新开源的Nacos Consul Adapter的实现提供的功能和Eureka的基本一致,在Eureka的基础上添加了一些细小的优化功能。
- 提供长轮询和直接查询两种方式
直接查询: Prometheus调用本项目,本项目直接请求Nacos服务端获取内容。
长轮询: 本项目使用Reactor3来实现长轮询,在指定的等待时间内如果注册信息发生变化会立即返回否则会一直等待直到指定时间流逝。在这种模式下不会直接调用Nacos服务器,而是请求的本地Nacos客户端的内容。 - 使用Reactor实现
与Spring Cloud Gateway底层技术一致,可以直接引入Spring Cloud Gateway使用。 - Maven引入Jar包直接使用
笔者已经将该项目打入到Maven仓库,简单配置就可直接使用了。
快速开始
可以在Spring Cloud Gateway中引入下面的jar包(可以是服务中任意的节点,在Spring Cloud Gateway中原因是,它基于Reactor。如果不是使用Spring WebFlux则还需要引入额外的包),然后在Prometheus中配置Spring Cloud Gateway的一个实例的ip地址就可以了。
项目的开源地址为:https://github.com/chen-gliu/nacos-consul-adapter。对本项目有任何问题和优化建议都可以提issue。
<dependency>
<groupId>io.github.chen-gliu</groupId>
<artifactId>nacos-consul-adapter</artifactId>
<version>0.0.5.M</version>
</dependency>
如果拉取不到项目,可以在setting文件中添加如下配置:
<mirror>
<id>mvnrepository</id>
<mirrorOf>*</mirrorOf>
<name>仓库</name>
<url>https://repo1.maven.org/maven2</url>
</mirror>
在Prometheus中添加如下配置:
- job_name: 'consul-prometheus-test'
metrics_path: '/actuator/prometheus'
consul_sd_configs:
- server: 引入nacos-consul-adapter实例的ip+端口
services: []
在每个Spring Cloud实例中引入Prometheus监控包:
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
@Bean
MeterRegistryCustomizer<MeterRegistry> configurer(
@Value("${spring.application.name}") String applicationName) {
return (registry) -> registry.config().commonTags("application", applicationName);
}
这样简单的配置后,启动服务就可以在Prometheus中看到注册在Nacos中的服务了。
总结
虽然说笔者开源的Nacos Consul Adapter的实现只有小小的三四个接口,但是在实现的过程中还是学习成长了很多。
1.学习了Nacos客户端的源码实现
2.使用Reactor3做一些实际项目
响应式编程在19年的时候就有接触过,最开始是学习RxJava,到后面的Reactor 3再到Spring WebFlux。技术学习了不用确实很容易忘记,这个小项目也练了练手。
3.实现长轮询的查询方式
之前都有了解过长轮询和长链接的通信方式的优缺点。之前接触使用长链接的比较多,对于长链接的实现这是第一次做。不管哪种方式都有它使用的场景。
4.将代码打包传到Maven仓库
在这个过程中确实踩了比较多的坑,后面有时间可以做一篇相关的总结。
项目开源地址:
https://github.com/chen-gliu/nacos-consul-adapter
参考资料
https://my.oschina.net/u/1439438/blog/3125324
nacos-consul-adapter
Eureka-consul-adapter
旧nacos-consul-adapter.
更多推荐
所有评论(0)