Istio 升级后踩的坑

前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失（页面上显示不出来）。,,,,首先是第一个基础信息丢失的问题，页面上其实显示的是我们的一个聚合指标istio_requests_total:source:rate1m。,具体可以参考 Istio 的最佳实践 Observability Best Practices 有详细说明。,本质上是通过以上四个维度进行统计 istio_requests_total；但在升级之后查看原始数据发现丢失了 destination_app, source_app 这两个 tag。,至于为啥丢失，查了许久，最后在升级后的资源文件 stats-filter-1.12.yaml 中找到了答案:,,升级后新增了 tags_to_remove 标记，将我们所需要的两个 tag 直接删掉了。,后续在当前 namespace 下重新建一个 EnvoyFilter 资源覆盖掉默认的便能恢复这两个 tag，修复后监控页面也显示正常了。,JVM 数据丢失的这个应用，直接进入 Pod 查看暴露出的 metric，发现数据都有，一切正常。,说明不是数据源的问题，那就可能是数据采集节点的问题了。,进入VictoriaMetrics 的 target 页面发现应用确实已经下线，原来是采集的端口不通导致的。,,而这个端口 15020 之前并未使用，我们使用的是另外一个自定义端口和端点来采集数据。,经过查阅发现 15020 是 istio 默认的端口：,,原来在默认情况下 Istio 会为所有的数据面 Pod 加上：,这个注解用于采集数据，由于我们是自定义的端点，所以需要修改默认行为：,,在控制面将 –set meshConfig.enablePrometheusMerge=false 设置为 false，其实官方文档已经说明，如果不是使用的标准 prometheus.io 注解，需要将这个设置为 false。,有了 url 这个 tag 后，接口监控页也恢复了正常。,接口维度的数据丢失和基本数据丢失的原因类似，本质上也是原始数据中缺少了 url 这个 tag，因为我们所聚合的指标使用了 url：,最终参考了 MetricConfig 自定义了 URL 的tag.,,但这也有个大前提，当我们 tag 的指标没有在默认 tag 列表中时，需要在 Deployment 或者是 Istio 控制面中全局加入我们自定义的 tag 声明。,比如这里新增了 url 的 tag，那么就需要在控制面中加入：,查看MetricConfig的配置后发现是可以直接去掉指标以及去掉指标中的 tag ，这个很有用，能够大大减低指标采集系统 VictoriaMetrics 的系统负载。,于是参考了官方的示例，去掉了一些 tag，同时还去掉了指标：istio_request_messages_total。,但并没有生效，于是换成了在 v1.12 中新增的 Telemetry API。,,但是参考了官方文档后发现依然不能生效，GRPC_REQUEST_MESSAGES 所对应的 istio_request_messages_total 指标依然存在。,接着在我领导查看 Istio 源码以及相关 issue 后发现 Telemetry API 和 EnvoyFilter 是不能同时存在的，也就是说会优先使用 EnvoyFilter；这也就是为什么我之前配置没有生效的原因。,,,正如这个 issue 中所说，需要删掉现在所有的 EnvoyFilter；删除后果然就生效了。,新的 Telemetry API 不但语义更加清晰，功能也一样没少，借助他我们依然可以自定义、删除指标、tag 等。,比如以上配置便可以删除掉 GRPC_RESPONSE_MESSAGES 指标，新增一个 url 的指标，同时在所有指标中删除了 source_workload 这个 tag。,借助于这一个声明文件便能满足我们多个需求。,后续根据我们实际需求借助于 Telemetry API 裁剪掉了许多指标和 tag，使得指标系统负载下降了一半左右。,,效果相当明显。,本次定位修复 Istio 升级后带来的指标系统问题收获巨大，之前对 Istio 一直只停留在理论阶段，只知道他可以实现传统微服务中对接口粒度的控制，完美弥补了 k8s 只有服务层级的粗粒度控制；,这两周下来对一个现代云原生监控系统也有了系统的认识，从 App->Pod->sidecar->VictoriaMetrics(Prometheus)->Grafana 这一套流程中每个环节都可能会出错；,所以学无止境吧，幸好借助公司业务场景后续还有更多机会参与实践。