SkyWalking 的高级可观测性领域 —— Service Mesh（服务网格）可观测性。

随着云原生技术的发展，越来越多的系统采用 Istio + Envoy 架构，传统的 APM 探针（如 Java Agent）无法直接注入到 Sidecar 中。而 SkyWalking 提供了 零侵入、非 SDK 模式的解决方案，让你无需修改应用代码，也能实现对服务网格的全面监控。

---

🌐 高级特性探索：Service Mesh 可观测性（Istio + Envoy）

✅ 目标：
实现对 Istio 服务网格中 数据平面（Envoy Sidecar） 的链路追踪、指标采集和拓扑生成，无需应用集成 SkyWalking Agent。

---

一、为什么需要 Service Mesh 可观测性？

在 Istio 服务网格中：

+----------------+     +------------------+
|   Application  |     |   Application    |
|                |     |                  |
+-------+--------+     +---------+--------+
        |                        |
        |                        |
+-------v--------+     +---------v--------+
|  Envoy (Sidecar)|     |  Envoy (Sidecar)  |
|  (Data Plane)   |     |  (Data Plane)     |
+----------------+     +------------------+
        |                        |
        +------------+-----------+
                     |
              +------v-------+
              |  Istio Control Plane  |
              |  (Pilot, Mixer, etc)  |
              +-----------------------+

传统 APM 的局限：

• Java Agent 无法注入到 Envoy 中
• 应用不埋点时，无法采集链路
• 只能监控“控制面”，看不到“数据面”的真实调用

SkyWalking 的优势：

✅ 通过分析 Envoy 的访问日志（Access Log），重建调用链和拓扑图，实现零侵入监控

---

二、SkyWalking 如何监控 Istio/Envoy？

SkyWalking 通过 Envoy Access Log Service (ALS) 或 日志采集 方式，获取 Sidecar 的每一次请求记录，并从中提取：

• 请求来源（source）
• 目标服务（destination）
• 响应时间
• 状态码
• traceId（来自 W3C Trace Context）

然后在 OAP 中：

1. 解析日志
2. 重建调用链（Trace）
3. 生成服务拓扑图
4. 聚合指标（QPS、P99、SLA）

---

三、核心实现方式（两种）

方式 1️⃣：Envoy ALS（推荐，生产级）

Envoy 支持将访问日志实时发送到 gRPC 服务（ALS），SkyWalking OAP 提供 ALS 接收器。

架构：

Envoy Sidecar → gRPC → SkyWalking OAP (ALS Receiver) → 存储 → UI

优点：

• 实时性高
• 性能好
• 支持结构化日志

配置示例（Envoy ALS）：

access_log:
  - name: skywalking.als
    config:
      grpc_service:
        envoy_grpc:
          cluster_name: skywalking_als
        timeout: 0.25s

✅ SkyWalking OAP 需启用 receiver-envoy-metrics 或 receiver-metric 模块。

---

方式 2️⃣：文件日志采集（简单，适合测试）

Envoy 将访问日志写入文件 → 通过 Filebeat/Fluentd 发送到 SkyWalking。

日志格式要求（JSON）：

{
  "start_time": "2025-04-05T10:00:00.123Z",
  "method": "GET",
  "path": "/api/user",
  "response_code": 200,
  "upstream_host": "user-service:8080",
  "upstream_cluster": "inbound|8080|http|user-service.default.svc.cluster.local",
  "trace_id": "abc123-def456",
  "span_id": "ghi789",
  "duration": 120
}

SkyWalking 配置：

# application.yml
receiver-access-log:
  als-http:
    enabled: true
    host: 0.0.0.0
    port: 1234

然后用 Filebeat 发送日志到 http://oap:1234。

---

四、关键配置（OAP 端）

确保 application.yml 中启用了 Mesh 监控模块：

# 启用 Envoy 访问日志接收器
receiver-access-log:
  # ALS over HTTP（用于文件日志）
  als-http:
    enabled: true
    host: 0.0.0.0
    port: 1234

  # ALS over gRPC（用于 Envoy 直连）
  als-grpc:
    enabled: true
    host: 0.0.0.0
    port: 11800
    # authentication: bearerToken

✅ 注意：11800 是 gRPC 端口，与 Agent 共用，但路径不同。

---

五、Envoy Sidecar 配置（Istio）

1. 启用访问日志

修改 Istio 配置（MeshConfig）：

meshConfig:
  accessLogEncoding: JSON
  accessLogFormat: |
    {
      "start_time": "%START_TIME%",
      "method": "%REQ(:METHOD)%",
      "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
      "protocol": "%PROTOCOL%",
      "response_code": "%RESPONSE_CODE%",
      "response_flags": "%RESPONSE_FLAGS%",
      "bytes_received": "%BYTES_RECEIVED%",
      "bytes_sent": "%BYTES_SENT%",
      "duration": "%DURATION%",
      "upstream_host": "%UPSTREAM_HOST%",
      "upstream_cluster": "%UPSTREAM_CLUSTER%",
      "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
      "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
      "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
      "requested_server_name": "%REQUESTED_SERVER_NAME%",
      "authority": "%REQ(:AUTHORITY)%",
      "user_agent": "%REQ(USER-AGENT)%", 
      "trace_id": "%REQ(X-B3-TraceId)%",
      "span_id": "%REQ(X-B3-SpanId)%"
    }

2. （可选）配置 ALS gRPC 上报

envoy_access_log_service:
  tcp_grpc:
    cluster_name: skywalking_als

---

六、验证监控效果

部署后，访问 SkyWalking UI：

1. Topology（拓扑图）

• 能看到服务之间的调用箭头
• 服务名来自 Envoy 的 upstream_cluster
• 即使没有 Java Agent，也能看到依赖关系

2. Trace（调用链）

• 查看某次请求的 Trace
• Span 类型为 Exit 或 Entry，来自 Envoy
• 包含 trace_id，可与应用日志关联

3. Metrics（指标）

• 服务 P99 响应时间
• QPS、错误率
• 基于 Envoy 日志聚合

---

七、优势与限制

优势	说明
✅ 零侵入	应用无需任何改动
✅ 支持多语言	无论应用是 Java、Go、Node.js 都能监控
✅ 统一视图	与 Agent 数据融合，形成完整链路
✅ 云原生友好	原生支持 Kubernetes + Istio

限制	说明
⚠️ 无法监控应用内部性能	如 JVM、方法耗时，仍需 Agent
⚠️ 依赖日志格式	必须包含 trace_id、duration 等字段
⚠️ 精度略低	基于日志，不如 Agent 字节码增强精确

---

✅ 最佳实践建议

场景	建议
🔹 纯 Mesh 环境	使用 ALS + SkyWalking 实现基础监控
🔹 混合环境（Agent + Mesh）	同时启用，SkyWalking 自动关联
🔹 高性能要求	使用 ALS gRPC，避免日志落盘
🔹 多租户	通过 namespace 隔离不同网格

---

🎯 总结：Service Mesh 监控口诀

“一配 Envoy 日志，二启 OAP ALS，三看拓扑链路，四融 Agent 数据”

SkyWalking 的 Service Mesh 可观测性，让你在 不修改应用的前提下，依然能“看得见”服务网格的每一次调用。