背景前段时间，我们将istio版本升级到1.12后，现有应用监控中有部分数据丢失（页面上没有显示）。一是基本应用信息丢失。另一个是应用程序JVM数据丢失。接口维度监控数据缺失。修复基本信息是基本信息丢失的第一个问题。页面上实际显示的是我们的一个聚合指标istio_requests_total:source:rate1m。聚合后，可以将多个指标合二为一，降低系统压力。详情请参考Istio的可观测性最佳实践。规范：组：-间隔：30s名称：istio.service.source.istio_requests_total规则：-expr：|sum(irate(istio_requests_total{reporter="source"}[1m]))by(destination_app,source_workload_namespace,response_code,source_app)record:istio_requests_total:source:rate1m本质上是通过以上四个维度统计了istio_requests_total；但是升级之后，查看原始数据发现destination_app和source_app这两个标签不见了。至于为什么丢了，找了半天，终于在升级后的资源文件stats-filter-1.12.yaml中找到了答案：升级后增加了一个tags_to_remove标签，我们需要的两个标签直接删除。后续在当前命名空间下重新创建一个EnvoyFilter资源覆盖默认会恢复这两个标签，修复后监控页面会正常显示。EnvoyFilter实时生效，不需要重建应用Pod。JVM监控JVM数据丢失的应用，直接进入Pod查看暴露的metrics，发现数据都在，一切正常。jvm_memory_pool_bytes_used{pool="CodeCache",}1.32126784E8jvm_memory_pool_bytes_used{pool="Metaspace",}2.74250552E8jvm_memory_pool_bytes_used{pool="CompressedClassSpace",}3.1766024E7jvm_memory_pool_bytes_used{pool="G1EdenSpace",}1.409286144E9jvm_memory_pool_bytes_used{pool="G1SurvivorSpace",}2.01326592E8jvm_memory_pool_bytes_used{pool="G1OldGen",}2.583691248E9说明不是数据源的问题，可能是数据采集节点的问题。进入VictoriaMetrics的目标页面，发现应用确实已经下线了。原来是采集口没接上。我们使用VictoriaMetrics而不是Prometheus。而这个端口15020之前没有被使用过，我们正在使用另一个自定义端口和端点来收集数据。检查后发现15020是istio的默认端口：默认情况下，Istio会在所有数据面pod中添加：metadata:annotations:prometheus.io/path:/stats/prometheusprometheus.io/port:"15020"Annotations用于收集数据。由于我们是自定义端点，因此我们需要修改默认行为：在控制平面上将--setmeshConfig.enablePrometheusMerge=false设置为false。其实官方文档已经说明了，如果不是标准的prometheus.io使用的Note，这个需要设置为false。修改后需要重新构建应用Pod才能生效。有了url标签，接口监控页面也恢复正常了。接口维度接口维度数据丢失的原因与基础数据类似。本质上，原始数据中缺少url标签，因为我们聚合的指标使用url:-interval:30sname:istio.service.source.url.istio_requests_totalrules:-expr:|sum(irate(istio_requests_total{reporter="source"}[1m]))by(destination_app,source_workload_namespace,response_code,source_app,url)最后引用MetricConfig自定义URL标签。{"dimensions":{"url":"request.url_path"}，但这也有一个大前提。当我们标签的索引不在默认标签列表中时，我们需要在Deployment或Istio控制平面标签语句中全局添加我们的自定义。比如这里添加了url的tag，需要添加：meshConfig:defaultConfig:extraStatTags:-url到控制平面，控制平面的修改只有在Pod重建后才会生效。EnvoyFilter的问题查看了MetricConfig的配置，发现指标和指标中的tag可以直接去掉。这是非常有用的，可以大大降低指标采集系统VictoriaMetrics的系统负载。所以参考官方的例子，去掉了一些标签，指标：istio_request_messages_total也去掉了。{"tags_to_remove":["source_principal","source_version","destination_principal","destination_version","source_workload","source_cluster",]},{"name":"istio_request_messages_total","drop":true}但是not没有生效，所以在v1.12中被新的TelemetryAPI取代。使用遥测APIapiVersion:telemetry.istio.io/v1alpha1kind:Telemetrymetadata:name:mesh-istio-testnamespace:istio-testspec:#noselectorspecified,appliestoallworkloadsmetrics:-overrides:-match:metric:GRPC_REQUEST_MESSAGESmode_ANDSAGESmode:CLIdisabled:true但是参考官方文档后发现还是不能生效，GRPC_REQUEST_MESSAGES对应的istio_request_messages_total指标依然存在。然后，我领导查看了Istio源码和相关问题后，发现TelemetryAPI和EnvoyFilter不能同时存在，也就是说会优先使用EnvoyFilter；这就是我之前的配置没有生效的原因。Post-initializeEnvoyFilter如本期所述，需要删除所有当前的EnvoyFilters；删除后生效。新的TelemetryAPI不仅语义更清晰，功能也更加丰富。有了它，我们仍然可以自定义和删除指标、标签等。apiVersion:telemetry.istio.io/v1alpha1kind:Telemetrymetadata:name:mesh-istio-telemetry-testnamespace:testspec:metrics:-overrides:-match:metric:GRPC_RESPONSE_MESSAGES模式：CLIENT_AND_SERVERdisabled:true-tagOverrides:url:value:"request.url_path"-match:metric:ALL_METRICStagOverrides:source_workload:operation:REMOVE比如上面的配置可以删除GRPC_RESPONSE_MESSAGES指标，添加一个url指标，并从所有指标中删除source_workload标签。借助这个声明文件，我们可以满足我们的多种需求。修剪指标后来根据我们的实际需要，借助TelemetryAPI对很多指标和标签进行了修剪，使得指标系统的负载降低了一半左右。效果相当明显。综上所述，这次对Istio升级带来的指标体系问题的定位和修复收获颇丰。Istio之前只是停留在理论阶段。我只知道它可以实现传统微服务中接口粒度的控制，完美弥补了k8s只有服务级别的问题。粗粒度控制；在过去的两周里，我也对现代云原生监控系统有了系统的了解。App->Pod->sidecar->VictoriaMetrics(Prometheus)->Grafana这个过程中的每一个环节都可能出错；所以学无止境。好在借助公司的业务场景，以后有更多的机会参与实践。
