共计 3763 个字符，预计需要花费 10 分钟才能阅读完成。
背景
前段时间咱们将 istio 版本升级到 1.12 后导致现有的利用监控有局部数据失落（页面上显示不进去）。
- 一个是利用根底信息失落。
- 再一个是利用 JVM 数据失落。
- 接口维度的监控数据失落。
修复
根底信息
首先是第一个根底信息失落的问题，页面上其实显示的是咱们的一个聚合指标 istio_requests_total:source:rate1m。
聚合后能够将多个指标合并为一个，缩小零碎压力
具体能够参考 Istio 的最佳实际 Observability Best Practices 有具体阐明。
spec:
groups:
- interval: 30s
name: istio.service.source.istio_requests_total
rules:
- 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 这两个 tag。
至于为啥失落，查了许久，最初在降级后的资源文件 stats-filter-1.12.yaml 中找到了答案:
降级后新增了 tags_to_remove 标记，将咱们所须要的两个 tag 间接删掉了。
后续在以后 namespace 下从新建一个 EnvoyFilter 资源笼罩掉默认的便能复原这两个 tag，修复后监控页面也显示失常了。
EnvoyFilter 是实时失效的，并不需要重建利用 Pod。
JVM 监控
JVM 数据失落的这个利用，间接进入 Pod 查看暴露出的 metric，发现数据都有，一切正常。
jvm_memory_pool_bytes_used{pool="Code Cache",} 1.32126784E8
jvm_memory_pool_bytes_used{pool="Metaspace",} 2.74250552E8
jvm_memory_pool_bytes_used{pool="Compressed Class Space",} 3.1766024E7
jvm_memory_pool_bytes_used{pool="G1 Eden Space",} 1.409286144E9
jvm_memory_pool_bytes_used{pool="G1 Survivor Space",} 2.01326592E8
jvm_memory_pool_bytes_used{pool="G1 Old Gen",} 2.583691248E9阐明不是数据源的问题，那就可能是数据采集节点的问题了。
进入 VictoriaMetrics 的 target 页面发现利用的确曾经下线，原来是采集的端口不通导致的。
咱们应用 VictoriaMetrics 代替了 Prometheus。
而这个端口 15020 之前并未应用，咱们应用的是另外一个自定义端口和端点来采集数据。
通过查阅发现 15020 是 istio 默认的端口：
原来在默认状况下 Istio 会为所有的数据面 Pod 加上：
metadata:
annotations:
prometheus.io/path: /stats/prometheus
prometheus.io/port: "15020"这个注解用于采集数据，因为咱们是自定义的端点，所以须要批改默认行为：
在管制面将 --set meshConfig.enablePrometheusMerge=false 设置为 false，其实官网文档曾经阐明，如果不是应用的规范 prometheus.io 注解，须要将这个设置为 false。
批改后须要重建利用 Pod 方能失效。
有了 url 这个 tag 后，接口监控页也复原了失常。
接口维度
接口维度的数据失落和根本数据失落的起因相似，实质上也是原始数据中短少了 url 这个 tag，因为咱们所聚合的指标应用了 url：
- interval: 30s
name: istio.service.source.url.istio_requests_total
rules:
- expr: |
sum(irate(istio_requests_total{reporter="source"}[1m]))
by (
destination_app,
source_workload_namespace,
response_code,
source_app,
url
)最终参考了 MetricConfig 自定义了 URL 的 tag.
{
"dimensions": {"url": "request.url_path"},但这也有个大前提，当咱们 tag 的指标没有在默认 tag 列表中时，须要在 Deployment 或者是 Istio 管制面中全局退出咱们自定义的 tag 申明。
比方这里新增了 url 的 tag，那么就须要在管制面中退出：
meshConfig:
defaultConfig:
extraStatTags:
- url批改了管制面后须要从新构建 Pod 后才会失效。
EnvoyFilter 的问题
查看 MetricConfig 的配置后发现是能够间接去掉指标以及去掉指标中的 tag，这个很有用，可能大大减低指标采集零碎 VictoriaMetrics 的零碎负载。
于是参考了官网的示例，去掉了一些 tag，同时还去掉了指标：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
} 但并没有失效，于是换成了在 v1.12 中新增的 Telemetry API。
应用 Telemetry API
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: mesh-istio-test
namespace: istio-test
spec:
# no selector specified, applies to all workloads
metrics:
- overrides:
- match:
metric: GRPC_REQUEST_MESSAGES
mode: CLIENT_AND_SERVER
disabled: true 然而参考了官网文档后发现仍然不能失效，GRPC_REQUEST_MESSAGES 所对应的 istio_request_messages_total 指标仍然存在。
接着在我领导查看 Istio 源码以及相干 issue 后发现 Telemetry API 和 EnvoyFilter 是不能同时存在的，也就是说会优先应用 EnvoyFilter；这也就是为什么我之前配置没有失效的起因。
后初始化 EnvoyFilter
正如这个 issue 中所说，须要删掉当初所有的 EnvoyFilter；删除后果然就失效了。
新的 Telemetry API 岂但语义更加清晰，性能也一样没少，借助他咱们仍然能够自定义、删除指标、tag 等。
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: mesh-istio-telemetry-test
namespace: test
spec:
metrics:
- overrides:
- match:
metric: GRPC_RESPONSE_MESSAGES
mode: CLIENT_AND_SERVER
disabled: true
- tagOverrides:
url:
value: "request.url_path"
- match:
metric: ALL_METRICS
tagOverrides:
source_workload:
operation: REMOVE 比方以上配置便能够删除掉 GRPC_RESPONSE_MESSAGES 指标，新增一个 url 的指标，同时在所有指标中删除了 source_workload 这个 tag。
借助于这一个申明文件便能满足咱们多个需要。
裁剪指标
后续依据咱们理论需要借助于 Telemetry API 裁剪掉了许多指标和 tag，使得指标零碎负载降落了一半左右。
成果相当显著。
总结
本次定位修复 Istio 降级后带来的指标零碎问题播种微小，之前对 Istio 始终只停留在实践阶段，只晓得他能够实现传统微服务中对接口粒度的管制，完满补救了 k8s 只有服务层级的粗粒度管制；
这两周下来对一个古代云原生监控零碎也有了零碎的意识，从 App->Pod->sidecar->VictoriaMetrics(Prometheus)->Grafana 这一套流程中每个环节都可能会出错；
所以学无止境吧，幸好借助公司业务场景后续还有更多机会参加实际。
