服务网格可观测性：Istio 遥测、Kiali 拓扑与全链路追踪实战

传统埋点：
  应用代码加 SDK → 手动 span/metric → 漏埋点 → 成本高、覆盖不全

服务网格：
  Sidecar(Envoy) 自动观测所有进出流量
    · 每个请求自动生成 metric（延迟/错误/流量）
    · 每个请求自动生成 access log
    · 上下文自动传播（traceparent 传递）
  → 零埋点、全覆盖、统一标签（service/namespace）

服务网格观测三大类：
  1. 流量指标：每秒请求数、p95 延迟、错误率（按源/目标服务）
  2. 拓扑关系：哪个服务调用哪个、依赖是否健康
  3. 请求追踪：一次跨服务调用全链路（哪个环节慢/错）
  4. 访问日志：每次调用的元数据（协议、状态、头信息）

控制平面（istiod）：
  · 下发配置、分发证书、聚合遥测定义
  · 不处理业务数据（轻量）

数据平面（Envoy Sidecar）：
  · 处理所有进出 Pod 的流量
  · 生成 metrics / access log / trace
  · 执行 mTLS 与路由策略

遥测链路：
  Envoy(生成数据)
    → Prometheus(抓取 Envoy metrics)
    → Loki(收集 access log)
    → Jaeger/Tempo(收集 trace)
    → Grafana + Kiali(可视化)

# Telemetry API — 控制 Envoy 上报什么
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus
  tracing:
    - providers:
        - name: otel
      randomSamplingPercentage: 10   # 10% trace 采样
  accessLogging:
    - providers:
        - name: otel
      match:
        # 仅记录关键事件，降噪
        mode: CLIENT_AND_SERVER

标准 RED 指标（Istio 提供）：
  istio_requests_total           # 请求量（标签: source/destination）
  istio_request_duration_milliseconds   # 延迟
  istio_requests_total{code=~"5.."}     # 错误率

基础指标（Envoy 原生）：
  envoy_server_uptime_seconds
  envoy_cluster_upstream_cx_active
  envoy_cluster_upstream_rq_pending
  envoy_cluster_upstream_rq_completed

指标自带丰富标签（自动）：
  source_workload / destination_workload
  source_service / destination_service
  source_namespace / destination_namespace
  response_code / response_flags
  request_protocol
  connection_security_policy

用途：
  · 按服务/命名空间任意切分
  · 跨集群对比（cluster 标签）
  · 网格外流量（workload missing 标记）

# Prometheus 抓取 Envoy metrics（Pod 级抓取）
scrape_configs:
  - job_name: istio-metrics
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      # 只抓注入 sidecar 的 Pod
      - source_labels: [__meta_kubernetes_pod_annotation_sidecar_istio_io_status]
        regex: injected
        action: keep
      # 端口 15090（Envoy stats）或 15020（合并）
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: keep

Kiali 提供的视图：
  · 拓扑图（Graph）：服务依赖网络实时呈现
      · 节点=服务，边=调用，宽度=流量，颜色=健康度
      · 异常服务红色高亮
  · 服务详情：每个服务的指标、标签、Pod 列表
  · 健康检查：错误率/延迟/可用性评分
  · 工作负载视图：Deployment → Pod → 容器
  · 流量验证：检查 mTLS 启用状态
  · 配置校验：VirtualService/DestinationRule 错误提示

# Kiali 连接 Prometheus + 控制平面
apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
  namespace: istio-system
spec:
  external_services:
    prometheus:
      url: http://prometheus.monitoring:9090
    istio:
      url: http://istiod.istio-system:15014
    tracing:
      url: http://tempo.monitoring:3200

用拓扑发现异常：
  · 节点变红 = 该服务错误率超标
  · 边变粗/变红 = 调用关系异常
  · 孤立节点 = 服务无调用（可能被误路由）
  · 缺失 mTLS 标记 = 明文流量（安全风险）

→ 拓扑是"定位服务间问题的第一视角"，配合指标深挖根因

Envoy 自动做上下文传播：
  · 入口 Envoy 生成 traceparent / b3 头
  · 转发时透传，下游 Envoy 追加 span
  · 应用 SDK 若已埋点，mesh 头传递与业务 span 自动关联
  · 未埋点的应用也能获得"代理级"全链路追踪

限制：
  · 只追踪"进出代理"的 span（不含业务内部逻辑）
  · 业务逻辑细节需应用自身埋点补充

# 通过 OTel Collector 收集 Envoy trace → Tempo
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  tracing:
    - providers:
        - name: otel
      randomSamplingPercentage: 50
---
# 追踪 provider 定义
apiVersion: telemetry.istio.io/v1alpha1
kind: ExtensionProvider
metadata:
  name: otel
  namespace: istio-system
spec:
  opentelemetry:
    service: otel-collector.monitoring.svc:4317
    port: 4317
    # 全采样走网关采样？此处 50% 为代理内采样

网格追踪采样选择：
  · randomSamplingPercentage: 10-50   # 概率采样，默认常低
  · 错误 span 高保真：配合尾部采样（Collector tail_sampling）
  · 全链路排障 vs 成本：生产建议 10% + 错误全留

Envoy 访问日志记录每次调用：
  协议、状态码、延迟、头信息、字节数
  → 可对接 Loki / ELK / 对象存储

默认字段：
  %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%
  %RESPONSE_CODE% %DURATION% %BYTES_RECEIVED% %BYTES_SENT%
  %UPSTREAM_CLUSTER% %DOWNSTREAM_REMOTE_ADDRESS%

# EnvoyFileAccessLog → 采集器 → Loki
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  accessLogging:
    - providers:
        - name: file
      match:
        mode: CLIENT_AND_SERVER
---
apiVersion: telemetry.istio.io/v1alpha1
kind: ExtensionProvider
metadata:
  name: file
  namespace: istio-system
spec:
  envoyFileAccessLog:
    path: /dev/stdout      # 输出到 stdout
    logFormat:
      text: "[%START_TIME%] %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL% %RESPONSE_CODE% %DURATION% %BYTES_RECEIVED% %BYTES_SENT% %UPSTREAM_CLUSTER% %DOWNSTREAM_REMOTE_ADDRESS%\n"
# Promtail/Loki 采集 stdout 并打上 service/namespace 标签

Linkerd vs Istio 观测差异：
  · 更轻：单控制平面，资源开销低
  · viz 插件内置拓扑、tap、指标
  · 自动 golden metrics（每链路 TCP+HTTP）

Linkerd 核心组件：
  · linkerd viz → Web 拓扑图
  · linkerd tap → 实时抓包查看请求
  · linkerd top → 实时吞吐/延迟
  · metrics 从数据平面代理抓取

# linkerd 自动暴露 metrics（每个代理 + 控制平面）
scrape_configs:
  - job_name: linkerd
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_linkerd_io_created_by]
        regex: .+
        action: keep
      - source_labels: [__meta_kubernetes_pod_container_name]
        regex: proxy
        action: keep

需要 L7 精细策略（限流/重试/灰度复杂规则）→ Istio（观测也更丰富）
追求极简、低开销、快速上手 → Linkerd（viz 自带够用）
大型网格（多集群/多租户）→ Istio（生态更全）

# 服务错误率 SLO（网格自动数据）
sum(rate(istio_requests_total{code=~"5..", destination_service=~"payment.*"}[5m]))
/ sum(rate(istio_requests_total{destination_service=~"payment.*"}[5m]))
< 0.999

# p95 延迟 SLO
histogram_quantile(0.95,
  sum by (le, destination_service) (rate(istio_request_duration_milliseconds_bucket[5m]))
) < 500

# 典型网格告警
groups:
  - name: mesh.rules
    rules:
      - alert: MeshHighErrorRate
        expr: |
          sum by (destination_service) (
            rate(istio_requests_total{code=~"5.."}[5m])
          ) / sum by (destination_service) (
            rate(istio_requests_total[5m])
          ) > 0.01
        for: 5m
        labels:
          severity: critical
      - alert: MeshTrafficDisappeared
        expr: |
          sum(rate(istio_requests_total[10m])) == 0
        for: 10m
        annotations:
          summary: "网格流量消失（可能 Sidecar 全部异常）"

服务网格层：流量/网络/协议/延迟（自动）
应用层：业务语义（埋点，如订单金额、用户动作）
基础设施层：K8s/节点/容器资源

三层配合：
  · 指标异常 → 网格定位"哪个服务间的调用坏了"
  · 追踪定位"哪一跳慢"
  · 应用埋点定位"为什么慢（业务原因）"

□ 全网格注入 Sidecar（ns 级默认）
□ Prometheus 抓取 Envoy 指标（RED 三色齐备）
□ 追踪：OTel Collector + Tempo（10% 采样 + 错误全留）
□ 访问日志 → Loki（结构化 + 标签）
□ Kiali 拓扑接入（发现依赖与异常）
□ 网格层 SLO + 告警
□ 检测 mTLS 覆盖（明文流量告警）
□ 定期做"网格观测演练"（chaos 验证盲区）

多集群（primary-remote）：
  · 全局拓扑需汇聚各集群遥测
  · Prometheus 联邦 / Thanos 全局查询
  · Kiali 接全局 Prometheus（cluster 标签切分）
  · 追踪汇聚到统一 Tempo