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 个组件，各组件协同工作，实现全链路数据的采集、分析、存储与可视化，逻辑上可分为以下四部分：

Agent（探针）：部署在每个微服务节点上，通过 Java Agent 字节码增强技术，无侵入采集服务的调用链路、接口耗时、报错信息等数据，格式化后传递给 OAP 服务器；核心是在类加载阶段动态注入监控逻辑，无需改动业务源码。
OAP Server（观测分析平台）：核心协调组件，接收 Agent 采集的数据，进行聚合、分析、计算（如接口平均响应时间、错误率），并将数据存储到指定存储介质，同时提供查询接口供 UI 调用。
Storage（存储）：用于存储 OAP Server 处理后的数据，支持 ElasticSearch、MySQL、H2 等多种存储介质，生产环境推荐使用 ElasticSearch（支持海量数据存储和快速查询）。
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（存储），一键完成部署，配置如下：

bash 复制代码

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 依赖（可选，用于增强日志关联，推荐添加）：

XML 复制代码

<!-- 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 定位日志：

XML 复制代码

<!-- 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 会将整个调用链路可视化展示，步骤如下：

进入 SkyWalking UI，点击左侧「追踪」→「链路追踪」，可看到所有请求的调用链路列表，包含 TraceId、服务名称、耗时、状态（成功/失败）等信息；
点击任意一条链路的「TraceId」，进入链路详情页，可直观看到请求的完整调用路径（树形结构），每个节点代表一个服务的调用，包含「服务名称」「接口方法」「耗时」「状态」等信息；
核心价值：快速明确请求经过哪些服务，各服务的调用顺序和耗时，比如"下单请求耗时 1.2s"，可快速看到是库存服务调用耗时 1s，定位到耗时瓶颈服务。

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

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

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

进入 SkyWalking UI，点击左侧「服务」→「服务列表」，选择需要排查的服务（如 order-service）；
进入服务详情页，查看「接口响应时间分布」图表，可看到每个接口的平均响应时间、95% 响应时间、最大响应时间，快速识别慢接口（如平均响应时间超过 500ms 的接口）；
点击慢接口，进入「接口详情」，查看该接口的「调用链路列表」，筛选出耗时最长的链路，点击 TraceId 进入链路详情，定位到具体哪个服务、哪个方法耗时过长；
进一步排查：若某个服务耗时过长，可查看该服务的「JVM 监控」（如 GC 耗时、堆内存使用），判断是否是 JVM 问题；若某个方法耗时过长，可结合日志（通过 TraceId 关联），查看是否是 SQL 慢查询、第三方接口调用超时等问题。

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

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

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

进入 SkyWalking UI，点击左侧「追踪」→「链路追踪」，筛选「状态=失败」的链路，可看到所有报错的请求；
点击报错链路的「TraceId」，进入链路详情页，报错的节点会标红，鼠标悬停可查看报错信息（如异常堆栈、错误信息）；
结合日志：通过链路的 TraceId，可快速关联到该请求的所有日志（需配置 logback 关联 TraceId），查看详细的报错堆栈，定位到具体的代码行；
常见报错场景：服务调用超时（网络问题、目标服务不可用）、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，各组件协同工作，流程如下：

Exporter（指标采集器）：部署在需要监控的节点上（如微服务、服务器、数据库），负责采集节点的运行指标（如 CPU 使用率、接口 QPS、数据库连接数），并提供 HTTP 接口供 Prometheus 抓取；
Prometheus Server（核心）：负责从 Exporter 抓取指标数据，存储为时序数据（按时间戳存储），提供 PromQL 查询语言，支持多维度指标查询；
Grafana：连接 Prometheus 数据源，通过丰富的仪表盘（Dashboard）将指标数据可视化展示（如折线图、柱状图、仪表盘），支持自定义仪表盘；
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 依赖：

XML 复制代码

  <!-- 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，暴露指标接口：

bash 复制代码

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（监控服务器指标），配置如下：

bash 复制代码

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 的指标，内容如下：

bash 复制代码

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 本身不自带仪表盘，可导入官方模板，快速实现微服务和服务器指标的可视化，步骤如下：

访问 http://服务器IP:3000，使用初始用户名（admin）和密码（123456）登录 Grafana；
添加 Prometheus 数据源：点击左侧「Configuration」→「Data Sources」→「Add data source」，选择「Prometheus」，填写 Prometheus 地址（http://prometheus:9090），点击「Save & Test」，提示"Data source is working"即配置成功；
导入仪表盘模板：导入步骤：点击左侧「Dashboards」→「Import」，输入模板 ID，选择已配置的 Prometheus 数据源，点击「Import」，即可生成可视化仪表盘。
1. 微服务监控模板：官方模板 ID「12856」（Spring Boot 微服务指标模板），可展示接口 QPS、响应时间、JVM 指标等；
2. 服务器监控模板：官方模板 ID「1860」（Node Exporter 服务器指标模板），可展示 CPU、内存、磁盘、网络等指标；
自定义仪表盘（可选）：若官方模板不符合需求，可点击「Create」→「Dashboard」，添加面板（如折线图、仪表盘），通过 PromQL 查询指标，自定义展示方式。

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

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

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

bash 复制代码

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 整合逻辑

分工协作：SkyWalking 负责全链路追踪、接口卡顿/报错排查；Prometheus + Grafana 负责指标监控、异常告警；
数据关联：通过服务名称、TraceId 关联两套系统的数据，例如：Grafana 发现某微服务接口响应时间过长，可通过服务名称在 SkyWalking 中查看该服务的调用链路，定位卡顿原因；SkyWalking 发现某链路报错，可通过 TraceId 关联 Prometheus 指标，查看该时间段的系统资源状态（如 CPU、内存）；
告警联动：将 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 微服务开发者和运维人员而言，掌握这两套工具的使用，能够大幅提升系统稳定性和运维效率，是微服务架构落地过程中不可或缺的技能。

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