跳到主要内容

Kubernetes APM 选型:SkyWalking vs Pinpoint vs Elastic APM

场景与目标

在稳定跑业务的同时,想看清每个请求的链路和慢点在哪里。这篇文章一边说清楚 SkyWalking / Pinpoint / Elastic APM 的差异,一边手把手带你在 K8s 里拉起一套 SkyWalking,用最少的步骤让应用产生日志和指标,最后确认 UI 里能看到 Trace。

方案对比(一句话概括)

方案优点注意点适合谁
SkyWalkingJava/Envoy/OTel 都能接,UI 清晰,支持 Service MeshOAP 依赖 ES/其他存储,注意资源想要“一套打通大部分语言和 Mesh”的团队
PinpointJava/Php 探针成熟,拓扑/调用栈直观语言覆盖面相对窄,探针版本要跟紧JVM/Php 业务为主的团队
Elastic APM和 ELK 打通,日志 + APM 一站式ES 开销大,Agent 需按语言配置已经用 ELK,想顺手接 APM 的团队

这里选 SkyWalking 落地示例,原因很直接:兼容多语言和 Istio,社区活跃,部署脚本也成熟。

在 K8s 部署 SkyWalking(Helm)

  1. 准备命名空间和 Helm 源:
kubectl create namespace observability --dry-run=client -o yaml | kubectl apply -f -
helm repo add skywalking https://apache.jfrog.io/artifactory/skywalking-helm
helm repo update
  1. 安装 SkyWalking(使用内置 Elasticsearch 单节点,先跑通):
helm upgrade --install skywalking skywalking/skywalking \
--namespace observability \
--set elasticsearch.replicas=1 \
--set elasticsearch.minimumMasterNodes=1 \
--set ui.service.type=ClusterIP \
--set oap.env.SW_OTEL_RECEIVER_ENABLED=true \
--set oap.env.SW_TELEMETRY=none
kubectl -n observability wait --for=condition=Available deploy -l app=skywalking --timeout=300s

生产请将 ES/存储独立出来,或改用 ClickHouse 支持,避免单点。

  1. 查看服务入口:
kubectl -n observability get svc skywalking-oap skywalking-ui
  • skywalking-oap 暴露 gRPC/HTTP(OTLP/Zipkin) 端口。
  • skywalking-ui 提供 Web 界面,默认 8080。

接入应用(Java 和 Istio)

Java 应用注入 Agent

在 Deployment 中给容器挂上 SkyWalking Java Agent(示例基于官方镜像):

apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-java
namespace: demo
spec:
replicas: 1
selector:
matchLabels:
app: demo-java
template:
metadata:
labels:
app: demo-java
spec:
containers:
- name: app
image: your/java-app:latest
env:
- name: SW_AGENT_NAME
value: demo-java
- name: SW_AGENT_COLLECTOR_BACKEND_SERVICES
value: skywalking-oap.observability.svc.cluster.local:11800
- name: JAVA_TOOL_OPTIONS
value: "-javaagent:/skywalking/agent/skywalking-agent.jar"
volumeMounts:
- name: skywalking-agent
mountPath: /skywalking/agent
volumes:
- name: skywalking-agent
emptyDir: {}
initContainers:
- name: agent-init
image: apache/skywalking-java-agent:9.2.0
command: ['sh', '-c', 'cp -R /skywalking/agent/* /skywalking-agent']
volumeMounts:
- name: skywalking-agent
mountPath: /skywalking-agent

轻量做法:也可将 Agent bake 进镜像;关键是 SW_AGENT_COLLECTOR_BACKEND_SERVICES 指向 OAP 的 11800 端口。

Istio Sidecar 集成(Envoy 直接上报)

在 Istio meshConfig 中配置 Zipkin 到 SkyWalking OAP(OAP 兼容 Zipkin)即可:

meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 50.0
zipkin:
address: skywalking-oap.observability.svc.cluster.local:9411

滚动更新 Sidecar,网格流量会自动上报。

验证结果

  1. 转发 UI 端口:
kubectl -n observability port-forward svc/skywalking-ui 8080:8080

浏览器打开 http://localhost:8080,进入 “Trace” 或 “Topology” 查看 demo-java/Istio 服务是否出现。

  1. 手动触发流量:
kubectl -n demo exec deploy/demo-java -- curl -s http://<your-service>/health

刷新 UI,确认有新 Trace 记录,跨度名称与调用链正确。

排障清单

  • Agent 无法上报:检查容器能否解析 skywalking-oap,端口 11800 是否可达;查看应用日志中是否有 SkyWalking 连接错误。
  • Trace 采样太低:提升 sampling 或在 Java 端设置 SW_AGENT_SAMPLE=-1(全采样,验证用)。
  • UI 无数据但 OAP 正常:查看 skywalking-oap Pod 日志,确认存储后端是否报错(ES/ClickHouse 连接)。
  • Istio 未上报:确认 meshConfig 已分发,或检查 Sidecar 是否启用了 Zipkin 配置。

生产落地要点

  • 把 OAP 存储换成外部 ES/ClickHouse,并开启持久化;OAP/ES 分开水平扩容。
  • 给 Agent/OAP/ES 配置资源限制与 HPA;高并发环境建议单独部署 OTel Collector 进行缓冲和出口控制。
  • 统一 service.name/env/version 标签,便于在 UI 里按环境、版本过滤。
  • 将 Helm values 纳入 GitOps 仓库,上线前用 helm template + kubectl apply --server-dry-run 校验。
  • 为 UI/OAP 加 RBAC/Ingress 访问控制,避免随便被访问。

总结

选型上,SkyWalking 覆盖面广、上手快;Pinpoint 适合 JVM/Php;Elastic APM 则和 ELK 一体化。文中的步骤能让你在集群里 10 分钟跑起 SkyWalking,给应用挂上探针,并在 UI 里看到真实链路。剩下的就是按业务量级加固存储、扩容 Collector,慢慢把追踪纳入日常值班和故障定位流程里。