使用AOP + Prometheus + node-exporter + grafana 实现Java系统的接口监控(实操)

本笔记适用于想要搭建业务系统监控能力的工程狮。此笔记适用的架构为单机部署方式,更倾向于一个小demo,本笔记需要用到cocker。请提前准备!!

1.监控的目的以及监控哪些内容?

在平常的业务需求中,我们通常需要一下两个方面的监控来全方位了解我们的系统:

1.1 机器健康度监控

  • CPU使用率内存使用率磁盘IO网络流量
  • 系统负载(Load Average)
  • 磁盘使用情况
  • 进程存活状态
  • Docker容器状态(如果使用容器化)
  • 系统日志异常

1.2 业务监控

  • 请求QPS、TPS(吞吐量)
  • 请求响应时间(P99, P95, P50)
  • HTTP状态码统计
  • 数据库查询耗时
  • 缓存命中率
  • 异常日志(如超时、错误)

2. 我们要用到哪些软件来实现呢?

2.1 Prometheus 主要用来存储和查询监控数据。
2.2 node Exporter 这个主要是用来采集服务器的CPU、内存、磁盘、网络指标等。(值得注意的是他基本不占什么内存)
2.3 grafana 通过可视化的图标来展示服务的运行情况
2.4 Java spring boot + Micrometer 实现业务监控

3. 开始搭建Prometheus + Grafana

3.1 创建docker-compose.yml

在本地创建一个文件夹

mkdir monitoring-demo && cd monitoring-demo

3.2 创建docker-compose.yml

version: '3'
services:
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    volumes:
    - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    container_name: grafana
    ports:
      - "3000:3000"

  node-exporter:
    image: prom/node-exporter
    container_name: node-exporter
    ports:
      - "9100:9100"

在上面的文件中共创建了三个容器,并为他们开放了不同的端口分别是 9090、3000以及9100 其中node-exporter用来采集docker容器的资源。

volumes:
    - ./prometheus.yml:/etc/prometheus/prometheus.yml

这个主要是用来配置普罗米修斯的采集规则,在docker-compose.yml的平级目录中添加一个新的yml用来进行数据采集。

global:
  scrape_interval: 15s  # 全局抓取间隔

scrape_configs:
  - job_name: 'prometheus' # 监控 Prometheus 自己
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node-exporter' # 监控 Node Exporter
    static_configs:
      - targets: ['node-exporter:9100']
  - job_name: 'java-demo-app' # Java 业务系统
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['host.docker.internal:8080']

3.3 启动docker
完成上面的操作后,就可以通过下面的命令来启动容器了

docker-compose up -d # -d 不展示启动log,在后台启动

启动后:

Prometheus 访问地址:http://localhost:9090

Grafana 访问地址:http://localhost:3000(默认用户 admin/admin) Ps🗡 第一次访问会让你改默认密码

一些知识点🛩 :

  1. 在普罗米修斯中可以通过简单的sql来查询已经上报的数据。可以通过 http://localhost:9090/query 这个路径来查询。如果你想要看到一些数据可以尝试查一下 node_cpu_seconds_total 这个信息,你大概可以看到一堆数据
  2. 如果你没看到任何信息或者你想要看普罗米修斯正在从收集哪些应用的信息,可以通过 http://localhost:9090/targets 来进行查看,这里可以看到哪些应用在线或者离线

4. 在Grafana中配置Prometheus数据源

访问Grafana http://localshot:3000

Grafana 左侧菜单 → 齿轮图标(Configuration) → Data Sources

点击 Add data source

选择 Prometheus

填写 URL:http://prometheus:9090 这里为什么写prometheus:9090呢,是以为Grafana 和 Prometheus 在同一个docker网络下,所以可以直呼其名

点击 Save & Test → 显示 Data source is working,表示连接成功!

5. 导入监控面板(Dashboard)

导入现成的服务器监控 Dashboard(Node Exporter)
  1. 左侧 → Dashboard(四个方块图标) → Import
  2. 输入 Dashboard ID1860
  3. 点击 Load
  4. 选择 Prometheus 数据源
  5. 点击 Import

效果:马上看到服务器 CPU、内存、磁盘、网络图表!

✅ 到目前为止你所完成事情 每个组件的职责和意义

组件 作用 你做了什么
Docker 快速构建环境 装了 Docker,部署了容器
Prometheus 抓取指标,保存数据 配了 prometheus.yml,启动服务
Node Exporter 提供主机指标 启动了 node-exporter,暴露 9100
Grafana 数据展示和分析 配了数据源、导入 Dashboard

6. 启动Java DEMO

  1. 创建一个maven项目,pom文件如下
<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-actuator</artifactId>
		</dependency>
		<dependency>
			<groupId>io.pivotal.spring.cloud</groupId>
			<artifactId>spring-cloud-services-starter-service-registry</artifactId>
		</dependency>

		<dependency>
			<groupId>io.micrometer</groupId>
			<artifactId>micrometer-registry-prometheus</artifactId>
			<scope>runtime</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>
  1. 配置application.yml
  spring:
    application:
      name: demo
  server:
    port: 8080
  # 以下内容主要是上报jvm的健康度
  management:
    endpoints:
      web:
        exposure:
          include: health,info,prometheus
    metrics:
      tags:
        application: demo-app
  1. 启动Javademo项目,这个Java项目的jvm信息将会被上报给普罗米修斯。

  2. 想要看看 jvm GC的情况?可以在仪表盘中导入这个json模板

     {
   
       "annotations": {
   
         "list": []
       },
       "panels": [
         {
   
           "type": "stat",
           "title": "GC 次数 (1m)",
           "datasource": "prometheus-1",
           "targets": [
             {
   
               "expr": "increase(jvm_gc_pause_seconds_count{application=\"demo-app\"}[1m])"
<think>好的,我现在需要解决用户提出的关于Eureka注册中心单点重启导致TPS下降的问题。首先,我得仔细理解用户的问题。用户提到当单台Eureka服务器重启时,整个集群的TPS会下降,这显然影响了系统的稳定性和性能。用户希望优化Eureka注册中心,避免这种情况发生。 接下来,我需要回忆Eureka的基本工作原理和相关机制。根据引用[1]和引用[2],Eureka Client会每隔30秒发送心跳续约,如果Server在90秒内未收到心跳,就会将实例从注册表中删除。这说明Eureka本身有失效剔除机制,而自我保护机制则是在网络分区时保护注册信息,防止误删。 那么,单点重启导致TPS下降的原因可能是什么?当一台Eureka Server重启时,客户端可能还在向该实例发送请求,导致部分请求失败。此外,Eureka的客户端可能没有及时切换到其他可用的Server节点,导致服务发现延迟,进而影响整体TPS。 接下来,我需要考虑优化方案。首先,确保Eureka Server集群的高可用性,避免单点故障。这可以通过部署多个Eureka Server节点并让它们相互注册来实现,如引用[2]中提到的客户端内置负载均衡器,可能帮助分发请求到不同的Server。 其次,调整客户端和服务端的配置参数。例如,缩短心跳间隔和续约时间,让Server更快检测到不可用实例,但需注意过于频繁的心跳会增加负载。另外,调整自我保护机制的阈值,避免在Server重启时触发自我保护,导致注册表信息无法及时更新。 然后,客户端的重试机制和负载均衡策略也很重要。使用带有重试功能的HTTP客户端,如Ribbon或Spring Retry,可以在某个Server节点不可用时自动重试其他节点。同时,优化客户端的Server列表更新频率,确保客户端能快速感知到Server节点的状态变化。 另外,服务端的优雅关闭和启动预注册也能减少影响。在重启前,让Server进入维护模式,通知客户端停止向其发送请求。同时,启动时预先加载注册信息,避免冷启动时的空注册表问题。 最后,考虑引入辅助监控和告警系统,及时发现并处理Server节点的问题,以及可能的自动扩展机制,根据负载动态调整Server数量。 在思考过程中,需要验证每个方案的可行性和潜在影响。例如,调整心跳间隔可能增加网络流量,但能更快发现故障;自我保护机制的调整需要平衡故障恢复和误判风险。同时,客户端的重试策略需要避免雪崩效应,设置合理的重试次数和超时时间。 总结来说,优化方向包括集群部署、参数调优、客户端重试与负载均衡、优雅处理节点上下线以及监控告警。需要综合应用这些措施来提升Eureka集群的稳定性和容错能力,从而避免单点重启导致的TPS下降。</think>### 优化Eureka注册中心避免单点重启导致TPS下降的解决方案 #### 1. **高可用集群部署** - **部署多节点集群**:至少部署3个及以上Eureka Server节点,并配置`eureka.client.service-url.defaultZone`互相注册,形成高可用集群。例如: ```yaml eureka: client: service-url: defaultZone: http://eureka-node1:8761/eureka,http://eureka-node2:8761/eureka,http://eureka-node3:8761/eureka ``` - **负载均衡**:客户端通过内置轮询负载均衡器(如Ribbon)自动分发请求到不同Server节点,避免单点依赖[^2]。 #### 2. **调整客户端与服务端参数** - **缩短心跳间隔与续约时间**(需权衡网络开销): ```yaml # 客户端配置(缩短至15秒心跳,45秒失效) eureka: instance: lease-renewal-interval-in-seconds: 15 lease-expiration-duration-in-seconds: 45 ``` - **优化Server响应缓存**:减少客户端拉取注册表的间隔时间,加速状态同步: ```yaml # 客户端注册表拉取间隔(默认30秒,建议缩短至15秒) eureka: client: registry-fetch-interval-seconds: 15 ``` #### 3. **启用自我保护机制的动态调整** - **合理配置自我保护阈值**:通过调整`renewal-percent-threshold`避免因单节点重启触发保护机制: ```yaml # Server端配置(默认0.85,可适当降低) eureka: server: renewal-percent-threshold: 0.75 ``` - **监控与手动干预**:结合监控系统(如Spring Boot Admin),在Server重启时临时关闭自我保护机制,加速注册表清理[^1]。 #### 4. **客户端容错与重试机制** - **HTTP请求重试**:使用Ribbon或Spring Retry实现请求自动重试: ```java @Bean public RetryTemplate retryTemplate() { return new RetryTemplate(); } ``` - **多Server地址轮询**:客户端配置多个Server地址,避免依赖单一节点: ```yaml eureka: client: service-url: defaultZone: http://backup-server1,http://backup-server2 ``` #### 5. **优雅关闭与启动预热** - **优雅关闭Server**:通过`/actuator/shutdown`端点或发送SIGTERM信号,触发Server进入维护模式,停止接收新请求并通知客户端更新注册表。 - **启动时预加载注册表**:在Server启动时从其他节点同步注册表数据,避免冷启动空窗期。 #### 6. **监控与告警** - **实时监控Server健康状态**:集成Prometheus + Grafana监控节点存活、心跳成功率等指标。 - **自动扩容**:结合Kubernetes或云平台,在节点故障时自动扩容新实例。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值