运维与可观测性

服务网格把流量路径变长：app → Sidecar → 对端 Sidecar → app。没有 指标、访问日志、分布式追踪，故障定位会比单体更难。好在 Envoy 与 Istio 内置大量 遥测出口，可与 observability-essentials 三支柱对齐。

学习目标

• 列举网格默认提供的 Metrics、Access Log、Trace 传播
• 知道 Prometheus / Grafana 与 Istio 集成思路
• 建立 Sidecar 资源与升级运维 checklist

三支柱在网格中的落点

支柱	网格侧	说明
Metrics	Envoy stats → Prometheus	QPS、延迟、4xx/5xx、TCP 连接
Logs	Sidecar access log	每请求一条，含 upstream、response flags
Traces	W3C traceparent / B3 头	与 obs-traces 一致

应用若已用 Micrometer + OTel（obs-spring），需保证 trace 头经 Sidecar 透传，避免 span 断链。

关键指标

运维常看（RED 方法，见 obs-dashboards）：

• Rate — istio_requests_total
• Errors — 5xx 比例、response_flags（UF=upstream failure 等）
• Duration — P50/P99 延迟 histogram

按 destination_service、source_workload 维度拆分，金丝雀发布时对比 v1/v2。

访问日志

Envoy access log 示例字段：

[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT%
%duration% %UPSTREAM_HOST%

RESPONSE_FLAGS 帮助区分超时（UT）、连接拒绝（UC）、熔断摘除（UO）——对照 obs-incident 排查流程。

控制面与 Sidecar 运维

• 升级 Istio：先 istiod，再滚动工作负载；关注 CRD 版本
• 配置漂移：GitOps 管理 VirtualService；istioctl analyze 进 CI
• 资源：Sidecar 默认 request 可能偏大/偏小，按峰值调优
• mTLS 证书：监控 Istiod 签发失败、Secret 过期事件

与 k8s-resources 一样，为 mesh 组件设 HPA / PDB。

与 Spring Cloud 可观测对照

sc-observability 强调 Actuator + 注册中心元数据；上网格后：

• 服务拓扑 可由 Kiali（Istio 生态）从 metrics 推导
• 业务指标 仍在应用暴露（订单数、报名成功率）
• 基础设施指标 由 Sidecar 统一，减少各语言 SDK 重复

练习

• 列出金丝雀发布需盯的 5 个指标（错误率、延迟…）
• 读 obs-intro，写 mesh 如何补「无 SDK 插桩」
• 设计一条告警：course-service 5xx > 1% 持续 5 分钟

小结

网格自带流量级可观测；业务 SLO 仍要应用指标。 下一课综合练习：为 Spring Cloud 服务画网格拓扑。