Spring AI 1.x 系列【51】可观测性技术选型

文章目录

[1. 可观测性技术选型](#1. 可观测性技术选型)
- [1.1 方案一：Prometheus + Loki + Jaeger](#1.1 方案一：Prometheus + Loki + Jaeger)
- [1.2 方案二：Apache SkyWalking](#1.2 方案二：Apache SkyWalking)
- [1.3 选型建议](#1.3 选型建议)
[2. SkyWalking](#2. SkyWalking)
- [2.1 核心功能](#2.1 核心功能)
- [2.2 核心组件](#2.2 核心组件)
- - [2.2.1 OAP](#2.2.1 OAP)
  - [2.2.2 数据存储引擎](#2.2.2 数据存储引擎)
  - [2.2.3 Booster UI](#2.2.3 Booster UI)
- [2.3 Docker 部署](#2.3 Docker 部署)
- - [2.3.1 一键部署](#2.3.1 一键部署)
  - [2.3.2 Docker Compose 部署](#2.3.2 Docker Compose 部署)

1. 可观测性技术选型

Spring AI 微服务项目的可观测性技术选型，核心围绕两套主流方案展开：

方案	架构风格	核心组件
方案一：云原生三件套	分离式（Best-of-Breed）	`Prometheus` + `Loki` + `Jaeger`，`Grafana` 统一展示，`OpenTelemetry` 统一埋点
方案二：一体化 APM	整合式（All-in-One）	`Apache SkyWalking`（指标、日志、链路、拓扑、告警全内置）

两套方案均可通过 OpenTelemetry（OTel）统一采集遥测数据。Spring AI 基于 Micrometer Observation 的 Tracing、Metrics、Logging 机制，天然对接 OTel 协议，无需关注后端实际选用哪套存储方案------埋点一次，后端可切换。

1.1 方案一：Prometheus + Loki + Jaeger

架构组成

复制代码

┌──────────────┐  ┌──────────┐  ┌───────────┐
│ Prometheus   │  │  Loki    │  │  Jaeger   │
│  (指标)      │  │ (日志)   │  │ (链路追踪) │
└──────┬───────┘  └────┬─────┘  └─────┬─────┘
       │               │              │
       └───────────────┼──────────────┘
                       │
               ┌───────▼───────┐
               │    Grafana    │
               │  (统一可视化)  │
               └───────────────┘

各组件职责分明，各自聚焦单一领域，通过 Grafana 统一展示。

各组件定位

组件	职责	特点
`Prometheus`	指标采集与告警	云原生事实标准，`PromQL` 查询能力极强
`Loki`	日志聚合	轻量级，与 `Prometheus` 标签体系一致，低成本索引
`Jaeger`	分布式链路追踪	`Uber` 开源，行业标准，兼容 `OpenTelemetry`，存储支持 `Cassandra`/`ES`
`Grafana`	统一可视化	支持多数据源，大盘高度自定义
`OpenTelemetry`	统一埋点 SDK	一次埋点，导出到任意后端

优势与劣势

维度	评价
灵活性	★★★★★ --- 每个模块均可替换
云原生支持	★★★★★ --- `CNCF` 生态核心项目
多语言 / 异构系统	★★★★★ --- `Python`、`Go`、`Node.js` 等均有一等支持
AI 服务监控	★★★★★ --- 向量库、中间件、模型 API 全覆盖
部署组件数	6~8 个（采集器 + 存储 + 查询 + 展示）
部署成本	高 --- 需要分别部署和维护多个组件
运维成本	高 --- 需要手动打通 `TraceId` + 日志 + 指标的关联跳转

1.2 方案二：Apache SkyWalking

架构组成

复制代码

┌──────────────────────────────────────┐
│           SkyWalking OAP             │
│  (指标 + 日志 + 链路 + 拓扑 + 告警)    │
└──────────────┬───────────────────────┘
               │
       ┌───────▼───────┐
       │ SkyWalking UI │
       │  (统一可视化)  │
       └───────────────┘

仅 2 个核心组件 （OAP + UI），所有可观测数据集中在 OAP 服务中处理。

内置能力

能力	说明
指标采集	内置 `JVM` 监控、`Slow SQL` 检测、服务指标
日志关联	自动关联 `TraceId`
链路追踪	自研追踪引擎，无侵入、低损耗
服务拓扑	自动发现服务依赖，生成调用地图
告警	内置告警规则引擎

存储后端可选：Elasticsearch、MySQL、H2。

优势与劣势

维度	评价
部署复杂度	★★★★★ --- 极低，`Docker Compose` 两条命令启动
开箱即用	★★★★★ --- 无需手动打通数据关联
`Java` / `Spring` 支持	★★★★★ --- 国内大厂生产环境大量使用
数据互通的自动关联	★★★★★ --- 指标 → 调用链 → 日志，全程一个页面
多语言 / 异构系统	★★★☆☆ --- 对 `Java` 最优，其他语言支持较弱
灵活性	★★★☆☆ --- 组件不可替换，须用整套

1.3 选型建议

选择方案一

追求云原生、国际标准技术栈
团队存在或未来可能使用多语言（Python、Go、Node.js）
需要监控 AI 服务、向量库、各类中间件
需要高度自定义仪表盘
团队具备一定运维能力，能接受多组件管理

这是最强大、最通用、未来主流的方案。

选择方案二

纯 Java / Spring 技术体系
追求最快部署、最少维护
不想管理多个独立组件
团队规模不大，运维能力有限
需要开箱即用的服务拓扑和自动关联

这是最简单、最稳定、国内企业最常用的方案。

总结

定位	方案一	方案二
一句话	最强灵活组合（云原生标准）	最简单一体化 `APM`（`Java` 首选）
适合团队	有运维能力的平台团队	追求效率的业务开发团队
与 `Spring AI` 的兼容	通过 `OTel` 协议对接	`Java Agent` 零侵入接入

两套方案都可通过 OpenTelemetry 实现统一埋点，Spring AI 应用层代码不需要任何改动------切换方案只需更换 OTel Exporter 的指向地址。

2. SkyWalking

SkyWalking 是一款开源可观测平台，用于采集、分析、聚合并可视化服务与云原生基础设施数据，具备分布式链路追踪、服务网格遥测数据分析、指标聚合、告警及可视化能力。

2.1 核心功能

Tracing｜分布式链路追踪：

功能项	说明
Trace Sampling	链路采样配置，控制上报数据量，避免海量链路压垮存储
Detect Slow Database Statement	慢SQL抓取与分析，定位数据库慢查询
Detect Slow Cache Command	慢缓存指令监控，排查Redis等缓存耗时异常
Message Queue Performance	消息队列收发性能监控（RocketMQ/Kafka/RabbitMQ）
Uninstrumented Gateways	发现未接入探针的网关服务
Zipkin Trace	兼容Zipkin协议链路数据接入
OpenTelemetry Trace	接收OpenTelemetry规范上报的链路数据

Metrics｜指标监控分析：

功能项	说明
OAL Scripts	OAL指标计算脚本，自定义聚合业务指标（AI调用、Token等）
OpenTelemetry Metrics	接入OpenTelemetry采集的各类指标
AWS CloudWatch Metrics	对接AWS云监控指标
Zabbix Metrics	兼容Zabbix监控指标接入
Meter Analysis	Micrometer Meter指标解析分析
Telegraf Metrics	接入Telegraf采集服务器、中间件指标
Apdex Threshold	配置Apdex性能满意度阈值
Spring MicroMeter Observations Analysis	适配SpringBoot/Micrometer埋点指标分析
Alerting	配置指标阈值告警，支持钉钉/企微/邮件/`WebHook 推送异常通知（耗时过高、错误率突增、AI 调用异常）

Logging｜日志集成：

功能项	说明
Persistent Logging	应用日志持久化存储与检索
On Demand Pod Logs	按需实时查看K8s容器Pod原始日志

2.2 核心组件

2.2.1 OAP

作用：全链路数据接收、计算、聚合、规则解析 ，整个 SkyWalking 的大脑。

核心特性：

内置 OTLP/Zipkin/SkyAgent 多协议接收器
通过MAL规则 解析 OTel 原始指标，转成 SkyWalking 规范指标（istio/mysql/k8s各类规则都由 OAP 加载）
拓扑自动计算、服务健康统计、数据落盘到存储(ES/BanyanDB)

端口分工：

11800(gRPC)：接收 JavaAgent、OpenTelemetry OTLP上报的链路Trace、指标Metrics、日志Logs
12800(HTTP)：给 Booster UI 提供查询接口、对外 API 查询监控数据

2.2.2 数据存储引擎

作用：用来落地保存 Trace 链路明细、Metrics 时序指标、日志、元数据。

存储	简介&适用场景
ElasticSearch(ES)	通用搜索引擎，生产传统选型，分布式分片，海量链路存储，生态成熟；端口9200，OAP配置`storage:elasticsearch`对接
BanyanDB	Apache SkyWalking自研原生时序数据库（v10主推），专门为 APM 链路/指标优化，轻量化、自动建表、无ES分片繁琐配置，新项目首选；端口17912，OAP官方主推存储

2.2.3 Booster UI

SkyWalking 新版 Web 可视化控制台，V9+ 默认UI，替代旧 RocketBot 。

访问地址：默认http://localhost:8080，前端 Vue 项目，只做数据查询展示，不存数据

核心特性：

服务拓扑图、调用链路详情、慢查询/异常追踪
系统指标大盘(Linux/K8s``/MySQL/Redis/AI指标)、日志检索
对应前文otel-rules配置的所有中间件监控面板（Istio、Mysql、Kafka 自动生成图表）

2.3 Docker 部署

2.3.1 一键部署

提示：推荐使用 2.3.2 中的部署方式，因为要添加一些自定义配置项

作为快速入门，可以使用一键脚本 启动 ElasticSearch 或 BanyanDB 作为存储、OAP 服务端以及 Booster UI。

下载脚本：

shell 复制代码

wget https://skywalking.apache.org/quickstart-docker.sh

修改 docker-compose 文件存储目录：

执行安装脚本：

执行启动脚本，会提示你选择存储类型，随后自动启动包含所选存储的后端集群：

安装成功：

访问 UI：

如需销毁并关闭整个集群，执行以下命令：

shell 复制代码

docker compose --project-name=skywalking-quickstart down

2.3.2 Docker Compose 部署

自定义 docker-compose 文件部署，主要是开启 OTLP 相关支持：

yml 复制代码

version: '3.8'

services:
  banyandb:
    image: apache/skywalking-banyandb:0.10.2
    container_name: banyandb
    networks:
      - demo
    ports:
      - 17913:17913
    command: standalone --stream-root-path /tmp/stream-data --measure-root-path /tmp/measure-data
    healthcheck:
      test: [ "CMD", "sh", "-c", "nc -nz 127.0.0.1 17912" ]
      interval: 5s
      timeout: 60s
      retries: 120

  oap:
    image: apache/skywalking-oap-server:10.4.0
    container_name: oap
    ports:
      - "11800:11800"
      - "12800:12800"
      - "17128:17128" # 补齐Admin管理端口
      - "4319:4317"
    networks:
      - demo
    depends_on:
      banyandb:
        condition: service_healthy
    healthcheck:
      test: [ "CMD-SHELL", "bash -c 'echo >/dev/tcp/localhost/12800'" ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 120s
    volumes:
      - ./skywalking:/skywalking
    environment:
      SW_HEALTH_CHECKER: default
      SW_TELEMETRY: prometheus
      JAVA_OPTS: "-Xms2048m -Xmx2048m"
      SW_STORAGE: banyandb
      SW_STORAGE_BANYANDB_TARGETS: banyandb:17912
      SW_OTEL_RECEIVER: default
      SW_OTEL_RECEIVER_ENABLED_HANDLERS: "otlp-metrics,otlp-traces,otlp-logs"
      # Trace必备：OTLP链路自动转Zipkin存储，不开查不到链路
      SW_RECEIVER_ZIPKIN: default
      SW_RECEIVER_GRPC_PORT: 4317
      SW_QUERY_ZIPKIN: default
  ui:
    image: apache/skywalking-ui:10.4.0
    container_name: ui
    ports:
      - "8080:8080"
    networks:
      - demo
    environment:
      SW_ZIPKIN_ADDRESS: http://oap:9412
      SW_OAP_ADDRESS: http://oap:12800
      SW_ADMIN_ADDRESS: http://oap:17128 # UI绑定Admin端口

networks:
  demo:

SkyWalking OAP 端口对照表：

端口	协议说明	是否默认开启
11800	gRPC（SkyWalking原生Agent上报）	默认开启
12800	HTTP（Booster UI查询后端接口）	默认开启
17128	Admin 管理接口（UI 配置、规则修改）	默认开启
4317	OTLP gRPC	需要手动开启
4318	OTLP HTTP	需要手动开启（本版本暂不支持）