Spring Cloud 微服务监控实战：SkyWalking + Prometheus+Grafana 全栈解决方案

在 Spring Cloud 微服务架构中，服务被拆分为多个独立部署的节点，跨服务调用、多数据源交互成为常态，随之而来的是排查难、监控难、告警难三大痛点：接口突然卡顿却找不到瓶颈、服务报错但无法定位根因、系统指标异常却不能及时感知，这些问题直接影响系统稳定性和用户体验。

一套完善的微服务监控体系，是解决上述痛点的关键。本文将聚焦两套主流监控方案，全面解析其核心用法、实操步骤和实战价值：SkyWalking 专注全链路追踪，搞定调用链可视化、接口卡顿定位、报错根因分析；Prometheus + Grafana 专注指标监控与可视化告警，实现系统指标实时采集、可视化展示、异常及时通知。两套方案相辅相成，共同构建 Spring Cloud 微服务全栈监控闭环，覆盖从开发调试到线上运维的全场景需求。

一、前置认知：微服务监控的核心需求与方案选型

1.1 微服务监控的核心痛点

随着微服务规模扩大，传统单体应用的监控方式已完全失效，核心痛点主要体现在 3 个方面：

• 链路不可见：一个请求从网关进入，经过多个微服务调用，无法直观看到完整调用路径，某个服务耗时过长、调用失败时，难以定位具体节点；

• 指标碎片化：每个微服务、服务器、数据库都有各自的运行指标（CPU、内存、接口 QPS、响应时间），指标分散，无法统一查看和分析；

• 异常无预警：系统出现异常（如接口报错、CPU 飙升）时，无法及时感知，往往等到用户反馈后才发现问题，错过最佳排查时机。

1.2 两套方案的核心定位（互补共生）

SkyWalking 与 Prometheus + Grafana 并非竞争关系，而是互补关系，各自聚焦不同监控维度，结合使用可实现全方位监控：

• SkyWalking：开源可观测性平台，核心定位是「全链路追踪」，主打调用链可视化、接口性能分析、报错根因定位，解决"请求链路不可见"的痛点，适合开发调试、线上故障排查；

• Prometheus + Grafana：Prometheus 负责指标采集与存储，Grafana 负责指标可视化与告警，核心定位是「系统指标监控」，主打服务器、微服务、数据库等指标的实时监控与异常告警，解决"指标碎片化、异常无预警"的痛点，适合运维监控、系统稳定性保障。

两者结合，可实现"链路可追踪、指标可监控、异常可预警"的微服务监控闭环，是 Spring Cloud 微服务企业级监控的首选组合。

二、SkyWalking 实战：全链路追踪，搞定卡顿与报错排查

SkyWalking 是一款开源的 APM（应用性能监控）系统，凭借无侵入设计、高性能、中文社区活跃等优势，成为 Spring Cloud 全链路追踪的首选工具。它基于 Java Agent 字节码增强技术，无需修改业务代码，就能实现全链路追踪、接口卡顿分析、报错根因定位等功能，完美适配微服务架构。

2.1 SkyWalking 核心架构与原理

SkyWalking 核心架构分为 4 个组件，各组件协同工作，实现全链路数据的采集、分析、存储与可视化，逻辑上可分为以下四部分：

1. Agent（探针）：部署在每个微服务节点上，通过 Java Agent 字节码增强技术，无侵入采集服务的调用链路、接口耗时、报错信息等数据，格式化后传递给 OAP 服务器；核心是在类加载阶段动态注入监控逻辑，无需改动业务源码。

2. OAP Server（观测分析平台）：核心协调组件，接收 Agent 采集的数据，进行聚合、分析、计算（如接口平均响应时间、错误率），并将数据存储到指定存储介质，同时提供查询接口供 UI 调用。

3. Storage（存储）：用于存储 OAP Server 处理后的数据，支持 ElasticSearch、MySQL、H2 等多种存储介质，生产环境推荐使用 ElasticSearch（支持海量数据存储和快速查询）。

4. UI（用户界面）：Web 可视化界面，用户可通过 UI 查看调用链、接口性能、服务拓扑、报错信息等，是 SkyWalking 的核心操作入口。

核心原理：Agent 拦截微服务的 HTTP/Dubbo 调用，生成全局唯一的 TraceId（贯穿整个请求链路）和 SpanId（单个服务的调用标识），通过 TraceId 将跨服务的调用链路串联起来，再通过 OAP Server 分析链路数据，最终在 UI 上可视化展示，同时捕捉接口卡顿、报错等异常信息，助力快速排查问题。

与其他链路追踪框架（如 Spring Cloud Sleuth + Zipkin、Pinpoint）相比，SkyWalking 具有无侵入、性能好、中文文档丰富、与国内技术栈整合度高等优势，更适合国内企业的微服务监控场景。

2.2 Spring Cloud 集成 SkyWalking 实操（核心步骤）

本次实操基于 Spring Cloud Alibaba + Nacos + SkyWalking 8.8.0 版本，采用 Docker 部署 SkyWalking（简化部署），微服务无侵入集成，步骤如下：

2.2.1 部署 SkyWalking（Docker 方式，推荐）

使用 Docker Compose 部署 SkyWalking OAP Server + UI + ElasticSearch（存储），一键完成部署，配置如下：

version: "3"
networks:
  skywalking-network:
    driver: bridge
services:
  # ElasticSearch：存储 SkyWalking 数据
  elasticsearch:
    image: elasticsearch:7.14.0
    container_name: skywalking-es
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
    ports:
      - "9200:9200"
    networks:
      - skywalking-network
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9200/_cluster/health"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

  # SkyWalking OAP Server
  oap-server:
    image: apache/skywalking-oap-server:8.8.1
    container_name: skywalking-oap
    depends_on:
      elasticsearch:
        condition: service_healthy
    environment:
      - SW_STORAGE=elasticsearch
      - SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200
      - SW_HEALTH_CHECKER=default
      - SW_TELEMETRY_ENABLED=true
    ports:
      - "11800:11800" # Agent 数据上报端口
      - "12800:12800" # UI 查询端口
    networks:
      - skywalking-network

  # SkyWalking UI
  skywalking-ui:
    image: apache/skywalking-ui:8.8.1
    container_name: skywalking-ui
    depends_on:
      - oap-server
    environment:
      - SW_OAP_ADDRESS=http://oap-server:12800
    ports:
      - "8080:8080" # UI 访问端口
    networks:
      - skywalking-network

执行 docker-compose up -d 启动所有服务，启动成功后，访问 http://服务器IP:8080，即可进入 SkyWalking UI 界面（默认无账号密码）。

2.2.2 微服务集成 SkyWalking Agent（无侵入）

微服务无需修改业务代码，只需添加 Agent 依赖和启动参数，即可实现数据采集，步骤如下：

• 下载 SkyWalking Agent 包（与 SkyWalking 版本一致，8.8.0），解压后得到 skywalking-agent 文件夹，将其放置在服务器指定目录（如 /opt/skywalking-agent）；

• 微服务添加 Maven 依赖（可选，用于增强日志关联，推荐添加）：

<!-- SkyWalking 工具包，用于日志关联 TraceId -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>8.8.0</version>
</dependency>
<!-- SkyWalking 日志采集依赖，用于将日志同步到 SkyWalking UI -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>8.8.0</version>
</dependency>

• 配置 logback-spring.xml，实现日志与 TraceId 关联，便于通过 TraceId 定位日志：

<!-- SkyWalking 日志采集配置 -->
<appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
    <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
        <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
            <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} (%tid) %level (%thread) %logger{60} (%file:%line): %msg%n</Pattern>
        </layout>
    </encoder>
</appender>
<!-- 根日志追加 SkyWalking 采集 -->
<root level="info">
    <appender-ref ref="grpc-log"/>
</root>

• 微服务启动时添加 VM 参数（关键，指定 Agent 路径和服务名称）： -javaagent:/opt/skywalking-agent/skywalking-agent.jar ``-Dskywalking.agent.service_name=order-service # 微服务名称，自定义，如订单服务、库存服务 ****-Dskywalking.collector.backend_service=服务器IP:11800 # OAP Server 地址若使用 IDEA 开发，可在启动配置中添加上述 VM 参数；若部署在服务器，可在启动脚本中添加。

启动微服务后，Agent 会自动采集调用链路、接口耗时等数据，上报到 OAP Server，此时可在 SkyWalking UI 中查看相关数据。

2.3 SkyWalking 核心功能实战（重点！解决卡顿/报错）

SkyWalking UI 的核心功能的是「全链路追踪」「接口性能分析」「报错根因定位」，这也是我们日常开发运维中最常用的功能，结合实战场景详细讲解：

2.3.1 全链路追踪：可视化查看调用链

当用户发起一个请求（如电商下单），请求会经过网关 → 订单服务 → 库存服务 → 账户服务，SkyWalking 会将整个调用链路可视化展示，步骤如下：

1. 进入 SkyWalking UI，点击左侧「追踪」→「链路追踪」，可看到所有请求的调用链路列表，包含 TraceId、服务名称、耗时、状态（成功/失败）等信息；

2. 点击任意一条链路的「TraceId」，进入链路详情页，可直观看到请求的完整调用路径（树形结构），每个节点代表一个服务的调用，包含「服务名称」「接口方法」「耗时」「状态」等信息；

3. 核心价值：快速明确请求经过哪些服务，各服务的调用顺序和耗时，比如"下单请求耗时 1.2s"，可快速看到是库存服务调用耗时 1s，定位到耗时瓶颈服务。

关键说明：链路标识采用「TraceId + SpanId + ParentSpanId」三层结构，TraceId 是全局唯一标识，贯穿整个请求链路；SpanId 是单个服务内的操作标识；ParentSpanId 记录当前 Span 的父 Span，通过这三个标识可构建完整的树形调用关系，避免链路断裂。

2.3.2 接口卡顿排查：定位慢接口与瓶颈

线上接口卡顿（响应时间过长）是常见问题，SkyWalking 可快速定位卡顿原因，步骤如下：

1. 进入 SkyWalking UI，点击左侧「服务」→「服务列表」，选择需要排查的服务（如 order-service）；

2. 进入服务详情页，查看「接口响应时间分布」图表，可看到每个接口的平均响应时间、95% 响应时间、最大响应时间，快速识别慢接口（如平均响应时间超过 500ms 的接口）；

3. 点击慢接口，进入「接口详情」，查看该接口的「调用链路列表」，筛选出耗时最长的链路，点击 TraceId 进入链路详情，定位到具体哪个服务、哪个方法耗时过长；

4. 进一步排查：若某个服务耗时过长，可查看该服务的「JVM 监控」（如 GC 耗时、堆内存使用），判断是否是 JVM 问题；若某个方法耗时过长，可结合日志（通过 TraceId 关联），查看是否是 SQL 慢查询、第三方接口调用超时等问题。

补充优化：可通过 SkyWalking 配置动态采样策略，避免全量采集导致的日志冗余------当服务 QPS<1000 时，采样率 100%；QPS 在 1000-5000 时，采样率 50%；QPS>5000 时，采样率 10%；同时对慢请求、错误请求强制采样 100%，既保证排查效率，又控制日志量。

2.3.3 报错根因定位：快速找到报错源头

当接口报错（如 500 错误、服务调用失败），SkyWalking 可快速定位报错根因，无需逐服务查看日志，步骤如下：

1. 进入 SkyWalking UI，点击左侧「追踪」→「链路追踪」，筛选「状态=失败」的链路，可看到所有报错的请求；

2. 点击报错链路的「TraceId」，进入链路详情页，报错的节点会标红，鼠标悬停可查看报错信息（如异常堆栈、错误信息）；

3. 结合日志：通过链路的 TraceId，可快速关联到该请求的所有日志（需配置 logback 关联 TraceId），查看详细的报错堆栈，定位到具体的代码行；

4. 常见报错场景：服务调用超时（网络问题、目标服务不可用）、SQL 报错（语法错误、数据库连接异常）、代码异常（空指针、参数错误），通过 SkyWalking 可快速定位到具体服务、具体方法，大幅提升排查效率。

2.4 SkyWalking 其他实用功能

• 服务拓扑图：点击左侧「拓扑图」，可查看所有微服务的调用关系，直观看到服务之间的依赖关系，便于梳理服务架构，识别核心依赖服务；

• JVM 监控：点击左侧「服务」→「JVM 监控」，可查看服务的 JVM 堆内存、非堆内存、GC 次数、GC 耗时等指标，及时发现 JVM 内存泄漏、GC 频繁等问题；

• 告警配置：可配置接口响应时间过长、报错率过高、服务不可用等告警规则，支持邮件、钉钉等告警方式，及时通知运维人员。

2.5 SkyWalking 优缺点总结

优点

• 无侵入性：基于 Java Agent 字节码增强，无需修改业务代码，接入成本低；

• 链路可视化：清晰展示请求的完整调用链路，卡顿、报错定位效率极高；

• 功能全面：支持链路追踪、JVM 监控、服务拓扑、告警等，覆盖开发运维全场景；

• 性能优异：采用 gRPC 进行数据传输，效率高、延迟低，对微服务性能影响小；

• 生态友好：完美支持 Spring Cloud、Spring Boot 等主流微服务框架，中文社区活跃，文档丰富。

缺点

• 部署复杂度较高：需要部署 OAP Server、UI、存储（如 ElasticSearch），运维成本略高；

• 对存储要求高：海量链路数据需要高性能存储（如 ElasticSearch），占用一定的服务器资源；

• 异步调用支持需额外配置：对于线程池、MQ 等异步调用场景，需额外配置上下文传递，否则会出现 TraceId 丢失问题。

三、Prometheus + Grafana 实战：指标监控与可视化告警

如果说 SkyWalking 解决的是"链路和报错排查"，那么 Prometheus + Grafana 解决的就是"指标监控和异常预警"。Prometheus 是一款开源的时序数据库，专注于指标采集、存储与查询；Grafana 是一款开源的数据可视化工具，专注于指标可视化展示与告警配置，两者结合，可实现 Spring Cloud 微服务全维度指标监控，让系统运行状态"一目了然"。

3.1 核心组件与协作流程

Prometheus + Grafana 的核心组件包括 Prometheus Server、Exporter、Grafana、Alertmanager，各组件协同工作，流程如下：

1. Exporter（指标采集器）：部署在需要监控的节点上（如微服务、服务器、数据库），负责采集节点的运行指标（如 CPU 使用率、接口 QPS、数据库连接数），并提供 HTTP 接口供 Prometheus 抓取；

2. Prometheus Server（核心）：负责从 Exporter 抓取指标数据，存储为时序数据（按时间戳存储），提供 PromQL 查询语言，支持多维度指标查询；

3. Grafana：连接 Prometheus 数据源，通过丰富的仪表盘（Dashboard）将指标数据可视化展示（如折线图、柱状图、仪表盘），支持自定义仪表盘；

4. Alertmanager（告警组件）：接收 Prometheus Server 发送的告警信息，进行分组、去重、静默处理，然后通过邮件、钉钉、短信等方式通知相关人员。

核心协作逻辑：Exporter 采集指标 → Prometheus 抓取并存储指标 → Grafana 可视化展示指标 → Prometheus 触发告警 → Alertmanager 发送告警通知，形成完整的监控告警闭环。

3.2 核心组件详解（重点）

3.2.1 Exporter：指标采集的"数据源"

Exporter 是指标采集的核心，不同的监控对象（微服务、服务器、数据库）对应不同的 Exporter，常用 Exporter 如下：

• Spring Boot Actuator + Micrometer：用于采集 Spring Cloud 微服务的指标（如接口 QPS、响应时间、错误率、JVM 指标），是微服务监控的核心 Exporter；

• Node Exporter：用于采集服务器的基础指标（CPU 使用率、内存使用率、磁盘使用率、网络带宽）；

• MySQL Exporter：用于采集 MySQL 数据库的指标（连接数、查询数、慢查询数、表空间使用率）；

• Redis Exporter：用于采集 Redis 缓存的指标（内存使用率、连接数、命中率）；

• Blackbox Exporter：通过 HTTP/HTTPS、TCP、ICMP 探测服务可用性，监控网站、端口存活状态。

3.2.2 Prometheus Server：指标存储与查询

Prometheus Server 的核心功能是「指标抓取」「时序存储」「PromQL 查询」：

• 指标抓取：通过配置文件指定 Exporter 的地址和抓取间隔（如每 10 秒抓取一次微服务指标），主动从 Exporter 抓取指标数据；

• 时序存储：将抓取到的指标数据存储为时序数据，支持本地存储（适合小规模监控）和分布式存储（如 Thanos，适合大规模监控）；

• PromQL 查询：提供强大的查询语言，支持多维度指标查询（如查询某个微服务的接口 QPS、某个服务器的 CPU 使用率），可用于自定义仪表盘和告警规则。

3.2.3 Grafana：可视化展示的"门面"

Grafana 本身不采集、不存储指标，而是通过连接 Prometheus 等数据源，将指标数据以可视化的方式展示，核心优势是「仪表盘自定义」「多数据源支持」「美观易用」：

• 仪表盘模板：提供大量官方模板（如 Spring Boot 微服务模板、服务器监控模板），无需手动配置，导入即可使用；

• 自定义仪表盘：可根据业务需求，自定义指标展示方式（如折线图展示接口 QPS 变化、仪表盘展示 CPU 使用率）；

• 多数据源支持：除了 Prometheus，还支持 ElasticSearch、InfluxDB 等多种数据源，可整合多套监控数据。

3.2.4 Alertmanager：告警通知的"信使"

Alertmanager 负责处理 Prometheus 触发的告警，核心功能包括：

• 告警分组：将相同类型的告警分组（如所有微服务的接口报错告警分为一组），避免告警风暴；

• 告警去重：同一告警多次触发时，只发送一次通知，避免重复打扰；

• 静默处理：可配置静默规则，在指定时间内（如夜间运维休息时间）不发送告警；

• 多渠道通知：支持邮件、钉钉、短信、Webhook 等多种通知方式，可根据告警级别（如警告、严重）发送给不同的人员。

3.3 Spring Cloud 集成 Prometheus + Grafana 实操

本次实操基于 Spring Cloud Alibaba + Prometheus 2.45.0 + Grafana 10.2.0，分为「微服务集成指标采集」「部署 Prometheus + Grafana」「配置可视化仪表盘」「配置告警」四个步骤：

3.3.1 第一步：微服务集成指标采集（Spring Boot Actuator + Micrometer）

Spring Cloud 微服务通过 Actuator 暴露指标，Micrometer 将指标转换为 Prometheus 支持的格式，步骤如下：

• 微服务添加 Maven 依赖：

  <!-- Spring Boot Actuator：暴露指标接口 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Micrometer：将指标转换为 Prometheus 格式 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

• 配置 application.yml，暴露指标接口：

spring:
  application:
    name: order-service # 微服务名称，用于 Prometheus 分组

# Actuator 配置：暴露所有指标接口
management:
  endpoints:
    web:
      exposure:
        include: "*" # 暴露所有接口，生产环境可按需暴露（如 prometheus, health）
  endpoint:
    health:
      show-details: always # 显示健康详情
  metrics:
    tags:
      application: ${spring.application.name} # 给指标添加应用标签，便于分组查询
    export:
      prometheus:
        enabled: true # 启用 Prometheus 指标导出

• 启动微服务，访问 http://服务IP:端口/actuator/prometheus，可看到微服务的所有指标（如接口 QPS、JVM 内存、错误率），说明指标采集配置成功。

3.3.2 第二步：部署 Prometheus + Grafana（Docker 方式）

使用 Docker Compose 部署 Prometheus、Grafana、Node Exporter（监控服务器指标），配置如下：

version: "3"
networks:
  monitor-network:
    driver: bridge
services:
  # Node Exporter：监控服务器指标
  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host|etc)($$|/)"
    networks:
      - monitor-network

  # Prometheus Server
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml # 挂载配置文件
      - prometheus-data:/prometheus # 挂载数据卷，持久化存储指标
    networks:
      - monitor-network
    depends_on:
      - node-exporter

  # Grafana
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana # 挂载数据卷，持久化配置
    environment:
      - GF_SECURITY_ADMIN_USER=admin # 初始用户名
      - GF_SECURITY_ADMIN_PASSWORD=123456 # 初始密码，生产环境需修改
    networks:
      - monitor-network
    depends_on:
      - prometheus

volumes:
  prometheus-data:
  grafana-data:

3.3.3 第三步：配置 Prometheus（抓取微服务指标）

创建 Prometheus 配置文件 prometheus.yml，配置抓取微服务和 Node Exporter 的指标，内容如下：

global:
  scrape_interval: 10s # 全局抓取间隔，每 10 秒抓取一次指标
  evaluation_interval: 10s # 告警规则评估间隔，每 10 秒评估一次

# 告警规则配置（关联 Alertmanager）
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"] # Alertmanager 地址，若部署可添加

# 抓取配置
scrape_configs:
  # 1. 抓取 Node Exporter 指标（服务器监控）
  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"] # Node Exporter 地址

  # 2. 抓取 Spring Cloud 微服务指标（多个微服务可添加多个 target）
  - job_name: "spring-cloud-microservice"
    metrics_path: "/actuator/prometheus" # 微服务指标接口路径
    static_configs:
      - targets: [
          "order-service:8081", # 订单服务地址（容器内地址，若外部部署需写服务器IP:端口）
          "inventory-service:8082", # 库存服务地址
          "account-service:8083" # 账户服务地址
        ]
    # 标签配置：给微服务指标添加服务名称标签
    relabel_configs:
      - source_labels: [__address__]
        regex: "([^:]+):\\d+"
        target_label: "service"
        replacement: "$1"

将配置文件挂载到 Prometheus 容器，重启容器后，访问 http://服务器IP:9090，进入 Prometheus UI，点击「Status」→「Targets」，可看到所有抓取目标的状态（UP 表示抓取成功）。

3.3.4 第四步：Grafana 可视化配置（导入模板，快速上手）

Grafana 本身不自带仪表盘，可导入官方模板，快速实现微服务和服务器指标的可视化，步骤如下：

1. 访问 http://服务器IP:3000，使用初始用户名（admin）和密码（123456）登录 Grafana；

2. 添加 Prometheus 数据源：点击左侧「Configuration」→「Data Sources」→「Add data source」，选择「Prometheus」，填写 Prometheus 地址（http://prometheus:9090），点击「Save & Test」，提示"Data source is working"即配置成功；

3. 导入仪表盘模板： 导入步骤：点击左侧「Dashboards」→「Import」，输入模板 ID，选择已配置的 Prometheus 数据源，点击「Import」，即可生成可视化仪表盘。

   1. 微服务监控模板：官方模板 ID「12856」（Spring Boot 微服务指标模板），可展示接口 QPS、响应时间、JVM 指标等；

   2. 服务器监控模板：官方模板 ID「1860」（Node Exporter 服务器指标模板），可展示 CPU、内存、磁盘、网络等指标；

4. 自定义仪表盘（可选）：若官方模板不符合需求，可点击「Create」→「Dashboard」，添加面板（如折线图、仪表盘），通过 PromQL 查询指标，自定义展示方式。

3.3.5 第五步：配置告警规则（异常及时通知）

配置 Prometheus 告警规则，当指标异常时（如 CPU 使用率超过 85%、接口错误率超过 5%），触发告警并通过 Grafana 发送通知，步骤如下：

• 在 Prometheus 配置文件 prometheus.yml 中添加告警规则（或单独创建告警规则文件）：

rule_files:
  - "alert_rules.yml" # 告警规则文件，需挂载到容器

# 告警规则示例（alert_rules.yml）
groups:
  - name: 服务器告警规则
    rules:
      - alert: 服务器CPU使用率过高
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m # 持续 5 分钟超过阈值，触发告警
        labels:
          severity: critical # 告警级别（critical：严重，warning：警告）
        annotations:
          summary: "服务器 {{ $labels.instance }} CPU 使用率过高"
          description: "服务器 {{ $labels.instance }} CPU 使用率已超过 85%，当前使用率：{{ $value | round(2) }}%"

  - name: 微服务告警规则
    rules:
      - alert: 微服务接口错误率过高
        expr: sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) / sum(rate(http_server_requests_seconds_count[5m])) > 0.05
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "微服务 {{ $labels.application }} 接口错误率过高"
          description: "微服务 {{ $labels.application }} 接口错误率已超过 5%，当前错误率：{{ $value | round(4) * 100 }}%"

      - alert: 微服务接口响应时间过长
        expr: avg(rate(http_server_requests_seconds_sum[5m])) / avg(rate(http_server_requests_seconds_count[5m])) > 0.5
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "微服务 {{ $labels.application }} 接口响应时间过长"
          description: "微服务 {{ $labels.application }} 接口平均响应时间已超过 500ms，当前响应时间：{{ $value | round(3) * 1000 }}ms"

• Grafana 配置告警通知：点击左侧「Alerting」→「Notification channels」→「Add channel」，选择通知方式（如钉钉、邮件），填写相关配置（如钉钉机器人 Webhook 地址），点击「Save」；

• 测试告警：手动触发异常（如模拟微服务接口报错），等待告警规则触发，查看是否收到通知，确保告警正常工作。

3.4 核心实战场景：指标监控与异常排查

3.4.1 微服务指标监控

通过 Grafana 仪表盘，可实时监控微服务的核心指标，包括：

• 接口指标：QPS（每秒请求数）、响应时间（平均/最大/95% 响应时间）、错误率（5xx/4xx 错误占比）；

• JVM 指标：堆内存使用率、非堆内存使用率、GC 次数、GC 耗时、线程数；

• 服务健康状态：服务是否可用、接口调用成功率。

实战价值：实时掌握微服务运行状态，提前发现接口 QPS 突增、响应时间过长、JVM 内存泄漏等问题，避免影响用户体验。

3.4.2 服务器指标监控

通过 Node Exporter + Grafana 模板，可实时监控服务器的核心指标，包括：

• CPU 指标：CPU 使用率、各核心使用率、负载 average；

• 内存指标：内存使用率、已用内存、空闲内存、缓存内存；

• 磁盘指标：磁盘使用率、磁盘读写速度、磁盘 IO 等待时间；

• 网络指标：网络带宽使用率、发送/接收字节数、网络连接数。

实战价值：及时发现服务器资源瓶颈（如 CPU 飙升、内存不足、磁盘满），提前扩容或清理，避免服务器宕机。

3.4.3 异常告警实战

结合告警规则，可实现以下常见异常的及时通知：

• 服务器 CPU 使用率超过 85%，持续 5 分钟，发送严重告警；

• 微服务接口错误率超过 5%，持续 3 分钟，发送警告告警；

• 微服务接口平均响应时间超过 500ms，持续 3 分钟，发送警告告警；

• 服务器磁盘使用率超过 90%，发送严重告警；

• 微服务不可用（指标抓取失败），发送严重告警。

3.5 Prometheus + Grafana 优缺点总结

优点

• 指标监控全面：支持微服务、服务器、数据库等全维度指标采集与监控；

• 可视化效果好：Grafana 仪表盘美观、灵活，支持自定义，可直观展示指标变化；

• 告警功能强大：支持多渠道告警、告警分组、静默处理，可及时发现异常；

• 轻量级、易部署：采用 Docker 部署简单，资源占用低，适合中小规模微服务集群；

• 生态完善：支持多种 Exporter，可适配不同的监控对象，扩展性强。

缺点

• 不支持全链路追踪：无法查看请求的调用链路，只能监控指标，需与 SkyWalking 配合使用；

• 时序数据存储有限：本地存储适合小规模监控，大规模监控需部署分布式存储（如 Thanos），运维成本增加；

• PromQL 学习成本：需要掌握 PromQL 查询语言，才能自定义指标查询和告警规则。

四、两套方案整合：Spring Cloud 微服务全栈监控闭环

SkyWalking 与 Prometheus + Grafana 各自聚焦不同的监控维度，单独使用无法覆盖所有监控需求，两者整合后，可实现"链路可追踪、指标可监控、异常可预警、根因可定位"的全栈监控闭环，整合方案如下：

4.1 整合逻辑

1. 分工协作：SkyWalking 负责全链路追踪、接口卡顿/报错排查；Prometheus + Grafana 负责指标监控、异常告警；

2. 数据关联：通过服务名称、TraceId 关联两套系统的数据，例如：Grafana 发现某微服务接口响应时间过长，可通过服务名称在 SkyWalking 中查看该服务的调用链路，定位卡顿原因；SkyWalking 发现某链路报错，可通过 TraceId 关联 Prometheus 指标，查看该时间段的系统资源状态（如 CPU、内存）；

3. 告警联动：将 SkyWalking 的告警（如接口报错率过高）与 Grafana 的告警整合，统一通过 Alertmanager 发送通知，确保异常无遗漏。

4.2 生产环境最佳实践

• 部署架构：采用 Docker/K8s 部署所有组件（SkyWalking、Prometheus、Grafana、Alertmanager），实现高可用（如 Prometheus 集群、SkyWalking OAP 集群）；

• 存储优化：SkyWalking 采用 ElasticSearch 存储链路数据，Prometheus 采用 Thanos 实现分布式存储，避免数据丢失和查询性能瓶颈；

• 告警分级：根据异常严重程度，将告警分为"严重""警告""信息"三级，严重告警（如服务宕机、CPU 飙升）立即通知运维人员，警告告警（如接口响应时间过长）定时汇总通知；

• 定期维护：定期清理过期的链路数据和指标数据，优化 PromQL 查询语句，调整告警规则，确保监控系统稳定运行。

五、总结

在 Spring Cloud 微服务架构中，监控系统是保障系统稳定性的核心支撑，而 SkyWalking 与 Prometheus + Grafana 的组合，是目前企业级微服务监控的最优解之一。

SkyWalking 以无侵入的方式，解决了"请求链路不可见、卡顿报错难排查"的痛点，让开发运维人员能够快速定位问题根源，提升排查效率；Prometheus + Grafana 则实现了"指标可监控、异常可预警"，让系统运行状态一目了然，提前发现潜在风险，避免故障扩大。

两套方案相辅相成，整合后可构建完整的微服务监控闭环，覆盖从开发调试、线上故障排查到运维监控的全场景需求。对于 Spring Cloud 微服务开发者和运维人员而言，掌握这两套工具的使用，能够大幅提升系统稳定性和运维效率，是微服务架构落地过程中不可或缺的技能。

实际应用中，可根据微服务规模和业务需求，灵活调整配置（如采样率、告警规则、存储方式），让监控系统真正适配业务，为微服务的稳定运行保驾护航。