Istio 升級(jí)后踩的坑

作者：crossoverJie 2023-02-20 08:11:04

本次定位修復(fù) Istio 升級(jí)后帶來(lái)的指標(biāo)系統(tǒng)問(wèn)題收獲巨大，之前對(duì) Istio 一直只停留在理論階段，只知道他可以實(shí)現(xiàn)傳統(tǒng)微服務(wù)中對(duì)接口粒度的控制，完美彌補(bǔ)了 k8s 只有服務(wù)層級(jí)的粗粒度控制。

背景

前段時(shí)間我們將 istio 版本升級(jí)到 1.12 后導(dǎo)致現(xiàn)有的應(yīng)用監(jiān)控有部分?jǐn)?shù)據(jù)丟失（頁(yè)面上顯示不出來(lái)）。

一個(gè)是應(yīng)用基礎(chǔ)信息丟失。
再一個(gè)是應(yīng)用 JVM 數(shù)據(jù)丟失。
接口維度的監(jiān)控?cái)?shù)據(jù)丟失。

修復(fù)

基礎(chǔ)信息

首先是第一個(gè)基礎(chǔ)信息丟失的問(wèn)題，頁(yè)面上其實(shí)顯示的是我們的一個(gè)聚合指標(biāo)istio_requests_total:source:rate1m。

聚合后可以將多個(gè)指標(biāo)合并為一個(gè)，減少系統(tǒng)壓力

具體可以參考 Istio 的最佳實(shí)踐 Observability Best Practices 有詳細(xì)說(shuō)明。

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

本質(zhì)上是通過(guò)以上四個(gè)維度進(jìn)行統(tǒng)計(jì) istio_requests_total；但在升級(jí)之后查看原始數(shù)據(jù)發(fā)現(xiàn)丟失了 destination_app, source_app 這兩個(gè) tag。

至于為啥丟失，查了許久，最后在升級(jí)后的資源文件 stats-filter-1.12.yaml 中找到了答案:

升級(jí)后新增了 tags_to_remove 標(biāo)記，將我們所需要的兩個(gè) tag 直接刪掉了。

后續(xù)在當(dāng)前 namespace 下重新建一個(gè) EnvoyFilter 資源覆蓋掉默認(rèn)的便能恢復(fù)這兩個(gè) tag，修復(fù)后監(jiān)控頁(yè)面也顯示正常了。

EnvoyFilter 是實(shí)時(shí)生效的，并不需要重建應(yīng)用 Pod。

JVM 監(jiān)控

JVM 數(shù)據(jù)丟失的這個(gè)應(yīng)用，直接進(jìn)入 Pod 查看暴露出的 metric，發(fā)現(xiàn)數(shù)據(jù)都有，一切正常。

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

說(shuō)明不是數(shù)據(jù)源的問(wèn)題，那就可能是數(shù)據(jù)采集節(jié)點(diǎn)的問(wèn)題了。

進(jìn)入VictoriaMetrics 的 target 頁(yè)面發(fā)現(xiàn)應(yīng)用確實(shí)已經(jīng)下線，原來(lái)是采集的端口不通導(dǎo)致的。

我們使用 VictoriaMetrics 代替了 Prometheus。

而這個(gè)端口 15020 之前并未使用，我們使用的是另外一個(gè)自定義端口和端點(diǎn)來(lái)采集數(shù)據(jù)。

經(jīng)過(guò)查閱發(fā)現(xiàn) 15020 是 istio 默認(rèn)的端口：

原來(lái)在默認(rèn)情況下 Istio 會(huì)為所有的數(shù)據(jù)面 Pod 加上：

metadata:
  annotations:
    prometheus.io/path: /stats/prometheus
    prometheus.io/port: "15020"

這個(gè)注解用于采集數(shù)據(jù)，由于我們是自定義的端點(diǎn)，所以需要修改默認(rèn)行為：

在控制面將 --set meshConfig.enablePrometheusMerge=false 設(shè)置為 false，其實(shí)官方文檔已經(jīng)說(shuō)明，如果不是使用的標(biāo)準(zhǔn) prometheus.io 注解，需要將這個(gè)設(shè)置為 false。

修改后需要重建應(yīng)用 Pod 方能生效。

有了 url 這個(gè) tag 后，接口監(jiān)控頁(yè)也恢復(fù)了正常。

接口維度

接口維度的數(shù)據(jù)丟失和基本數(shù)據(jù)丟失的原因類似，本質(zhì)上也是原始數(shù)據(jù)中缺少了 url 這個(gè) tag，因?yàn)槲覀兯酆系闹笜?biāo)使用了 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"
},

但這也有個(gè)大前提，當(dāng)我們 tag 的指標(biāo)沒(méi)有在默認(rèn) tag 列表中時(shí)，需要在 Deployment 或者是 Istio 控制面中全局加入我們自定義的 tag 聲明。

比如這里新增了 url 的 tag，那么就需要在控制面中加入：

meshConfig:
  defaultConfig:
    extraStatTags:
     - url

修改了控制面后需要重新構(gòu)建 Pod 后才會(huì)生效。

EnvoyFilter的問(wèn)題

查看MetricConfig的配置后發(fā)現(xiàn)是可以直接去掉指標(biāo)以及去掉指標(biāo)中的 tag ，這個(gè)很有用，能夠大大減低指標(biāo)采集系統(tǒng) VictoriaMetrics 的系統(tǒng)負(fù)載。

于是參考了官方的示例，去掉了一些 tag，同時(shí)還去掉了指標(biāo)：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
}

但并沒(méi)有生效，于是換成了在 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

但是參考了官方文檔后發(fā)現(xiàn)依然不能生效，GRPC_REQUEST_MESSAGES 所對(duì)應(yīng)的 istio_request_messages_total 指標(biāo)依然存在。

接著在我領(lǐng)導(dǎo)查看 Istio 源碼以及相關(guān) issue 后發(fā)現(xiàn) Telemetry API 和 EnvoyFilter 是不能同時(shí)存在的，也就是說(shuō)會(huì)優(yōu)先使用 EnvoyFilter；這也就是為什么我之前配置沒(méi)有生效的原因。

后初始化 EnvoyFilter

正如這個(gè) issue 中所說(shuō)，需要?jiǎng)h掉現(xiàn)在所有的 EnvoyFilter；刪除后果然就生效了。

新的 Telemetry API 不但語(yǔ)義更加清晰，功能也一樣沒(méi)少，借助他我們依然可以自定義、刪除指標(biāo)、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 指標(biāo)，新增一個(gè) url 的指標(biāo)，同時(shí)在所有指標(biāo)中刪除了 source_workload 這個(gè) tag。

借助于這一個(gè)聲明文件便能滿足我們多個(gè)需求。

裁剪指標(biāo)

后續(xù)根據(jù)我們實(shí)際需求借助于 Telemetry API 裁剪掉了許多指標(biāo)和 tag，使得指標(biāo)系統(tǒng)負(fù)載下降了一半左右。

效果相當(dāng)明顯。

總結(jié)

這兩周下來(lái)對(duì)一個(gè)現(xiàn)代云原生監(jiān)控系統(tǒng)也有了系統(tǒng)的認(rèn)識(shí)，從 App->Pod->sidecar->VictoriaMetrics(Prometheus)->Grafana 這一套流程中每個(gè)環(huán)節(jié)都可能會(huì)出錯(cuò)；

所以學(xué)無(wú)止境吧，幸好借助公司業(yè)務(wù)場(chǎng)景后續(xù)還有更多機(jī)會(huì)參與實(shí)踐。

責(zé)任編輯：武曉燕來(lái)源： crossoverJie