Prometheus 使用 Consul 自动发现 Spring Boot 服务并拉取数据

本文主要是介绍Prometheus 使用 Consul 自动发现 Spring Boot 服务并拉取数据,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Prometheus 使用 Consul 自动发现 Spring Boot 服务并拉取数据

使用 Prometheus监控 SpringBoot 应用,当应用很多,且上下线频繁时,需要不断的更改 Prometheus 的配置文件,不能灵活的使用,可以通过为 Prometheus配置注册中心,从注册中心拉取应用数据获取监控数据

启动 Prometheus

  • 添加配置文件 prometheus.yaml
mkdir -p ~/docker/prometheus/config
vi ~/docker/prometheus/config/prometheus.yml
global:scrape_interval: 15sscrape_timeout: 10sevaluation_interval: 15s
alerting:alertmanagers:- static_configs:- targets: []scheme: httptimeout: 10sapi_version: v1
scrape_configs:
- job_name: prometheushonor_timestamps: truescrape_interval: 15sscrape_timeout: 10smetrics_path: /metricsscheme: httpstatic_configs:- targets:- localhost:9090
  • 启动容器
docker run \-d \--name prometheus \-p 9090:9090 \-v ~/docker/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml \prom/prometheus    

启动 Consul

docker run \-d \--name consul \-p 8500:8500 \consul

启动 Spring Boot 应用

添加监控

  • 添加依赖 build.gradle
    compile 'org.springframework.cloud:spring-cloud-starter-consul-discovery'compile 'org.springframework.boot:spring-boot-starter-actuator'compile 'io.micrometer:micrometer-core:1.5.1'compile 'io.micrometer:micrometer-registry-prometheus:1.5.1' 
  • 修改应用配置 applicaiton.properties
spring.cloud.consul.host=localhost
spring.cloud.consul.port=8500
spring.cloud.consul.discovery.service-name=${spring.application.name}
spring.cloud.consul.discovery.prefer-ip-address=true
spring.cloud.consul.discovery.health-check-url=http://host.docker.internal:${server.port}/actuator/health
spring.cloud.consul.discovery.tags=metrics=truemanagement.endpoints.web.exposure.include=*
# prometheus
management.metrics.tags.application=${spring.application.name}

上面配置中指定健康检查是为了 Consul 从容器访问宿主机的应用,指定tag是为了Prometheus 从Consul列表中拉取需要监控的指定应用

使用 Consul 发现服务

修改 Prometheus 配置

  • prometheus.yaml
global:scrape_interval: 15sscrape_timeout: 10sevaluation_interval: 15s
alerting:alertmanagers:- static_configs:- targets: []scheme: httptimeout: 10sapi_version: v1
scrape_configs:- job_name: "prometheus"static_configs:- targets: ["localhost:9090"]- job_name: "consul"consul_sd_configs:- server: "host.docker.internal:8500"relabel_configs:- source_labels: ["__meta_consul_dc"]target_label: "dc"- source_labels: [__meta_consul_service]separator: ;regex: (.*)target_label: applicationreplacement: $1action: replace- source_labels: [__address__]separator: ":"regex: (127.0.0.1):(.*)target_label: __address__replacement: host.docker.internal:${2}action: replace- source_labels: [__metrics_path__]separator: ;regex: /metricstarget_label: __metrics_path__replacement: /actuator/prometheusaction: replace- source_labels: ['__meta_consul_tags']regex: '^.*,metrics=true,.*$'action: keep

其中 :

  • consul_sd_configs指定 Consul 的地址
  • relabel_configs 指定配置标签覆盖规则
  • __meta_consul_service
      - source_labels: [__meta_consul_service]separator: ;regex: (.*)target_label: applicationreplacement: $1action: replace

这个配置是将 __meta_consul_service 重新映射为 application字段,方便 Prometheus 查询

  • __address__
      - source_labels: [__address__]separator: ":"regex: (127.0.0.1):(.*)target_label: __address__replacement: host.docker.internal:${2}action: replace

这个配置是为了将 127.0.0.1的地址改为host.docker.internal,方便 Prometheus 从容器中访问宿主机的应用

  • __metrics_path__
      - source_labels: [__metrics_path__]separator: ;regex: /metricstarget_label: __metrics_path__replacement: /actuator/prometheusaction: replace

这个配置是为了将 Prometheus 默认的拉取数据 /metrics改成 /actuator/prometheus,方便从 Spring拉取,如果有多种不同的应用,数据路径不一样,建议设置多个job,以使用不同的规则

  • __meta_consul_tags
      - source_labels: ['__meta_consul_tags']regex: '^.*,metrics=true,.*$'action: keep

这个配置是为了筛选指定tag的应用,只有有这个tag的应用才会拉取监控数据,这里是 metrics=true,是在 Spring Boot的配置文件中配置的,这样就可以避免拉取不相关的数据的应用(如 Consul自己的数据,替换路径为/actuator/prometheus后无法获取到监控数据)

配置完成后重启 Prometheus

获取应用

  • Consul 中注册的应用

prometheus-consul-consul-service-list.png

  • Prometheus 的 Service Discovery

可以看到,consul这个服务下发现了三个服务,但是只有一个在拉取数据,另外两个被丢弃了,这是因为限制了只拉取 tag 为 metrics=true

prometheus-consul-prometheus-discovery-list.png

  • Prometheus 的 Target

可以看到 Target 也只拉取了这一个应用

prometheus-consul-prometheus-target-list.png

  • 查询监控数据

在 Prometheus 的 Graph中查询应用信息,也只能看到一个

process_uptime_seconds

prometheus-consul-prometheus-query-result1.png

  • 修改另一个 Spring Boot 应用,添加监控tag

再次查询 Prometheus 数据,可以看到另一个应用也开始拉取数据

prometheus-consul-prometheus-query-result2.png


  • 相关项目可以参考 grpc

这篇关于Prometheus 使用 Consul 自动发现 Spring Boot 服务并拉取数据的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1138620

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定