云原生应用的监控体系：从Prometheus到SkyWalking的全链路追踪实践（距离收官倒计时１５）

huahua8088

564人浏览 · 2025-10-11 05:12:27

huahua8088 · 2025-10-11 05:12:27 发布

引言

云原生应用的核心特征是分布式、微服务化、动态扩缩容，但这也将监控推向了“复杂度的巅峰”：

一个请求可能经过10+个微服务，如何追踪完整链路？
JVM内存泄漏、接口QPS突增，如何快速定位？
Kubernetes集群中，服务的动态IP如何自动监控？

本文将构建一套“指标收集+链路追踪+可视化”的云原生监控体系，整合Micrometer（指标暴露）、Prometheus（指标存储查询）、SkyWalking（链路追踪），并通过K8s集成实现自动化监控，最终解决“定位性能瓶颈”的核心问题。

一、监控体系的核心组件与分工

云原生监控的本质是“用标准化的协议，收集、存储、分析分布式系统的数据”，核心组件如下：

组件	角色	核心能力
Micrometer	指标暴露桥梁	统一收集JVM、接口、数据库等指标，暴露给Prometheus
Prometheus	指标存储与查询引擎	存储时间序列数据，支持PromQL查询
SkyWalking	分布式链路追踪系统	生成TraceID，追踪请求全链路，定位瓶颈
Grafana	可视化仪表盘	整合Prometheus/SkyWalking数据，展示实时指标与链路

二、Micrometer：统一指标暴露的标准

Micrometer是Java生态的指标收集标准库，支持将JVM、Spring Boot、数据库等指标暴露为Prometheus兼容的格式，是连接应用与Prometheus的关键桥梁。

2.1 集成Micrometer到Spring Boot

Spring Boot Actuator默认集成了Micrometer，只需添加Prometheus依赖，即可暴露/actuator/prometheus端点：

1. 添加依赖（Maven）

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

2. 配置`application.yml`

开启Actuator的Prometheus端点：

management:
  endpoints:
    web:
      exposure:
        include: prometheus,health,info # 暴露Prometheus端点
  metrics:
    tags:
      application: ${spring.application.name} # 添加应用标签，方便Prometheus区分服务

3. 验证指标暴露

启动应用后，访问http://localhost:8080/actuator/prometheus，会看到如下指标：

JVM内存：process_memory_used_bytes、process_memory_total_bytes
接口QPS：http_server_requests_seconds_count、http_server_requests_seconds_sum
线程数：process_threads_running

2.2 关键指标解析

Micrometer暴露的指标遵循Prometheus命名规范（<metric_name>_<unit>），常用指标：

指标名称	含义
`jvm_memory_used_bytes`	JVM已使用内存（字节）
`jvm_memory_total_bytes`	JVM总内存（字节）
`http_server_requests_seconds_count`	接口请求总数（按状态码、路径分组）
`http_server_requests_seconds_sum`	接口请求总耗时（秒）

三、Prometheus：指标的存储与查询

Prometheus是时间序列数据库（TSDB），专门存储Prometheus格式的指标，支持PromQL查询语言，能快速检索和分析数据。

3.1 部署Prometheus到K8s

用Prometheus Operator（通过Helm部署）简化K8s中的Prometheus管理：

1. 添加Helm仓库

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

2. 安装Prometheus Operator

helm install prometheus prometheus-community/prometheus \
  --namespace monitoring \
  --create-namespace \
  --set server.service.type=LoadBalancer # 暴露服务到集群外

3. 配置ServiceMonitor自动发现服务

Prometheus Operator通过ServiceMonitor自动发现K8s中的服务，无需手动配置scrape_configs。
创建service-monitor.yaml：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: spring-boot-app-monitor
  namespace: default
  labels:
    release: prometheus # 匹配Prometheus Operator的标签
spec:
  selector:
    matchLabels:
      app: spring-boot-app # 选择带有`app=spring-boot-app`标签的Service
  endpoints:
  - port: http # 对应Service的端口名称
    interval: 15s # 抓取间隔
    path: /actuator/prometheus # 抓取路径

4. 部署ServiceMonitor

kubectl apply -f service-monitor.yaml

此时，Prometheus会自动发现spring-boot-app服务的/actuator/prometheus端点，开始抓取指标。

3.2 PromQL常用查询示例

PromQL是Prometheus的查询语言，用于检索和分析指标。以下是云原生场景的常用查询：

1. 接口平均耗时（5分钟内）

# 计算接口的平均响应时间（秒）
rate(http_server_requests_seconds_sum[5m]) 
/ 
rate(http_server_requests_seconds_count[5m])

2. JVM内存使用率

# 计算JVM内存使用率（百分比）
(process_memory_used_bytes / process_memory_total_bytes) * 100

3. 接口错误率（5分钟内）

# 计算5xx错误的占比
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) 
/ 
sum(rate(http_server_requests_seconds_count[5m]))

4. QPS（每秒请求数）

# 计算接口的QPS
rate(http_server_requests_seconds_count[5m])

四、SkyWalking：分布式链路追踪

SkyWalking是国产开源的分布式链路追踪系统，支持Java、Go、Python等多语言，通过TraceID串联请求全链路，定位性能瓶颈。

4.1 集成SkyWalking Agent到Spring Boot

SkyWalking通过Java Agent自动注入TraceID，无需修改业务代码：

1. 下载SkyWalking Agent

从SkyWalking官网下载最新版本的Agent（如apache-skywalking-java-agent-9.4.0.tgz）。

2. 配置Agent

解压Agent后，修改config/agent.config：

properties

# 设置SkyWalking OAP Server地址（K8s中需用Service名称）
agent.service_name=${SW_AGENT_NAME:spring-boot-app} # 服务名称
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:skywalking-oap-server:11800} # OAP Server地址

3. 启动应用时挂载Agent

在K8s的Deployment中挂载Agent：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-boot-app
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: app
        image: your-spring-boot-app:latest
        # 挂载SkyWalking Agent
        volumeMounts:
        - name: skywalking-agent
          mountPath: /agent
      volumes:
      - name: skywalking-agent
        hostPath:
          path: /path/to/apache-skywalking-java-agent-9.4.0
          type: Directory
        # 设置Java Agent参数
        env:
        - name: JAVA_TOOL_OPTIONS
          value: "-javaagent:/agent/skywalking-agent.jar"

4.2 TraceID传递与链路追踪

SkyWalking的Java Agent会自动：

为每个入站请求生成TraceID；
将TraceID注入HTTP请求头（sw8字段）；
下游服务接收请求后，自动提取TraceID并继续传递；
所有服务的调用信息会发送到SkyWalking OAP Server，形成完整的链路。

4.3 查看链路追踪

启动SkyWalking OAP Server和UI后，访问http://skywalking-ui:8080，输入TraceID即可查看完整链路：

链路拓扑图：展示请求经过的所有服务；
每个服务的耗时：定位最慢的服务（如数据库查询慢）；
日志与指标：关联链路中的日志和指标，快速排查问题。

五、K8s中集成监控面板（Grafana）

Grafana是可视化仪表盘工具，支持整合Prometheus和SkyWalking的数据，展示实时指标与链路。

5.1 部署Grafana到K8s

用Helm部署Grafana：

helm repo add grafana https://grafana.github.io/helm-charts
helm install grafana grafana/grafana \
  --namespace monitoring \
  --create-namespace \
  --set service.type=LoadBalancer

5.2 配置数据源

访问Grafana UI（http://grafana-ip:3000，默认账号admin/admin）；
添加Prometheus数据源：
- URL：http://prometheus-server.monitoring.svc.cluster.local:9090（K8s中的Prometheus服务地址）；
添加SkyWalking数据源：
- URL：http://skywalking-oap-server.monitoring.svc.cluster.local:12800（K8s中的OAP Server地址）；

5.3 创建监控面板

1. 接口性能面板（Prometheus数据）

图表1：接口QPS（rate(http_server_requests_seconds_count[5m])）；
图表2：接口平均耗时（rate(http_server_requests_seconds_sum[5m])/rate(http_server_requests_seconds_count[5m])）；
图表3：接口错误率（sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))/sum(rate(http_server_requests_seconds_count[5m]))）。

2. JVM监控面板（Prometheus数据）

图表1：JVM内存使用率（(process_memory_used_bytes/process_memory_total_bytes)*100）；
图表2：JVM线程数（process_threads_running）。

3. 链路追踪面板（SkyWalking数据）

导入SkyWalking的Grafana Dashboard（ID：3578），展示链路拓扑、服务耗时、日志关联。

六、实战：快速定位性能瓶颈

假设订单服务的接口/api/orders延迟突然升高（从200ms到1s），我们用监控体系定位问题：

6.1 第一步：用Prometheus看指标

查询/api/orders的QPS和延迟：

QPS：rate(http_server_requests_seconds_count{uri="/api/orders"}[5m]) → 正常（100次/秒）；
平均耗时：rate(http_server_requests_seconds_sum{uri="/api/orders"}[5m])/rate(http_server_requests_seconds_count{uri="/api/orders"}[5m]) → 升高到1s。

结论：接口延迟升高，但请求量正常，可能是服务内部处理慢。

6.2 第二步：用SkyWalking看链路

查找/api/orders的TraceID，查看链路拓扑：

订单服务 → 库存服务 → 支付服务；
库存服务的耗时：800ms（正常是100ms）；
支付服务的耗时：100ms（正常）。

结论：库存服务是瓶颈。

6.3 第三步：定位库存服务的问题

查看库存服务的指标：

JVM内存使用率：process_memory_used_bytes/process_memory_total_bytes → 90%（内存泄漏）；
接口耗时：rate(http_server_requests_seconds_sum{uri="/api/inventory"}[5m])/rate(http_server_requests_seconds_count{uri="/api/inventory"}[5m]) → 800ms。

结论：库存服务的内存泄漏导致处理变慢，触发GC，延迟升高。