跳到主要内容

SkyWalking 链路追踪与运维

Apache SkyWalking 是面向云原生和分布式系统的应用性能监控（APM）平台。它通过语言 Agent、OpenTelemetry 等方式采集 Trace、Service、Instance、Endpoint 与 Log 关联信息，帮助团队从一次请求追踪到具体服务、依赖调用与异常位置。

SkyWalking 与 Prometheus 的边界不同：Prometheus 适合回答“系统是否异常、趋势是否恶化”，SkyWalking 更适合回答“这一次请求经过了哪些服务、慢在哪里、错误发生在什么调用链”。两者应通过服务名、环境、集群等稳定维度关联，而不是互相替代。

1. 核心架构​

Application Agent / OpenTelemetry
                |
                v
        SkyWalking OAP --> Storage --> SkyWalking UI
                |             |
                |             +--> Elasticsearch / OpenSearch / BanyanDB
                +--> 指标、拓扑、告警与日志关联
  • Agent / Collector：在应用侧创建和上报 Trace、Metric、Log 关联信息。Agent 不应阻塞业务请求。
  • OAP：接收数据、构建服务拓扑、执行分析和告警规则，并向存储后端读写数据。
  • Storage：保存追踪、指标和元数据。上线前需明确索引生命周期、分片、容量与备份策略。
  • UI：用于按服务、实例、端点、Trace ID 和时间范围检索。UI 访问权限应与生产权限模型一致。

2. 接入前的命名规范​

服务、实例和环境的命名会直接影响拓扑质量、告警归属和跨系统检索。先定义以下规则，再批量接入：

维度建议避免
Service稳定业务服务名，如 checkout-api使用动态 Pod 名或发布版本号
Instancepod-name 或 hostname在服务名中拼接实例 ID
Environmentproduction、staging 等受控值未受控的自由文本
Trace ID透传到日志字段写入 Prometheus 标签

Trace 采样率必须按流量、错误率和排障目标选择。全量采样并不总是更好：高 QPS 服务应优先保证错误、慢请求和关键交易链路的可观测性。

3. Java Agent 接入示例​

Java Agent 通常通过 JVM 参数加载。下面示例将服务名、实例名和 OAP 地址显式配置，避免依赖环境默认值。

# Agent 路径应随应用发布，版本需经过兼容性验证。
# 服务名用于拓扑、查询和告警归属，必须稳定且全局可识别。
# 实例名区分同一服务的多个 Pod 或主机。
# OAP 地址可由服务发现或环境变量注入。
java \
  -javaagent:/opt/skywalking/skywalking-agent.jar \
  -Dsw.agent.name=checkout-api \
  -Dsw.agent.instance_name=${HOSTNAME} \
  -Dsw.collector.backend_service=skywalking-oap.monitoring.svc:11800 \
  -jar app.jar

接入后先发起一条可控请求，确认 UI 中出现服务、实例和 Endpoint，再检查跨服务调用是否保持同一条 Trace。只有入口服务有数据而下游缺失，通常是下游 Agent 未接入、协议插件不兼容或 Trace Context 没有透传。

4. Kubernetes 部署重点​

OAP 与 UI 应部署在独立命名空间，并通过 Service 暴露内部地址。生产环境应限制 UI、OAP 管理端口和存储后端的网络访问范围。

env:
  - name: SW_STORAGE
    value: elasticsearch
  - name: SW_STORAGE_ES_CLUSTER_NODES
    # 使用集群内 Service；不要写入单个 Pod IP。
    value: elasticsearch.monitoring.svc:9200
  - name: SW_CORE_RECORD_DATA_TTL
    # 追踪数据保留天数需要与索引生命周期和容量匹配。
    value: "7"
  - name: SW_CORE_METRICS_DATA_TTL
    value: "30"

存储后端的索引模板、分片数和生命周期要按实际写入量设计。追踪数据通常写入密集且保留期短；不要让过长保留期挤占业务日志或指标存储的容量预算。

5. 常用检查与排障​

# 检查 OAP 健康端点或 Kubernetes 就绪状态。
kubectl -n monitoring get pods -l app=skywalking-oap

# 查看 OAP 是否持续接收 Agent 连接与上报异常。
kubectl -n monitoring logs deploy/skywalking-oap --tail=200

# 从应用 Pod 确认 Agent 已被加载；具体参数随镜像封装方式调整。
kubectl -n production exec deploy/checkout-api -- \
  sh -c 'ps -ef | grep -F skywalking-agent | grep -v grep'

常见问题的排查顺序：先确认 Agent 已加载和 OAP 地址可达，再确认服务名、采样和协议插件，最后检查 OAP 到存储后端的写入延迟、索引权限与磁盘容量。不要在生产上为排查问题长期启用 Debug 日志或全量采样。

6. 与指标和日志的关联​

  • 在日志中输出 Trace ID 与 Span ID，并由日志平台建立字段索引，避免从 APM 复制整段应用日志。
  • 在服务名、环境、集群和版本字段上与 Prometheus/Grafana 保持命名一致，方便从告警跳到 Trace。
  • 为高错误率、P99 延迟和依赖调用失败建立联动入口：指标识别范围，Trace 定位单次请求和下游依赖。
  • 对敏感参数、认证信息和业务隐私字段设置脱敏与忽略规则，Agent 采集前先评审数据范围。

7. 学习路径​

  1. 二进制与 Docker 部署：理解 OAP、UI、存储、端口和基础验收。
  2. Java Agent 接入：规范服务命名、加载 Agent 并验证 Trace 上报。
  3. UI、拓扑与 Trace 分析：从 Dashboard 下钻到服务依赖与单条请求。

验收清单​

  • 核心服务、实例和 Endpoint 命名遵循统一规范。
  • 关键请求的 Trace Context 能跨 HTTP、RPC 或消息链路正确透传。
  • OAP、存储、UI 的网络访问和身份权限按最小权限配置。
  • 采样率、数据保留期、索引生命周期与容量预算已评审并可监控。