背景

前段時間我們將 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 這一套流程中每個環節都可能會出錯；

所以學無止境吧，幸好借助公司業務場景后續還有更多機會參與實踐。