建站
咨詢
售后
建站咨詢
新聞中心
背景
前段時(shí)間我們將 istio 版本升級到 1.12 后導(dǎo)致現(xiàn)有的應(yīng)用監(jiān)控有部分?jǐn)?shù)據(jù)丟失（頁面上顯示不出來）。
- 一個(gè)是應(yīng)用基礎(chǔ)信息丟失。
- 再一個(gè)是應(yīng)用 JVM 數(shù)據(jù)丟失。
- 接口維度的監(jiān)控?cái)?shù)據(jù)丟失。
修復(fù)
基礎(chǔ)信息
首先是第一個(gè)基礎(chǔ)信息丟失的問題，頁面上其實(shí)顯示的是我們的一個(gè)聚合指標(biāo)istio_requests_total:source:rate1m。
聚合后可以將多個(gè)指標(biāo)合并為一個(gè)，減少系統(tǒng)壓力
具體可以參考 Istio 的最佳實(shí)踐 Observability Best Practices 有詳細(xì)說明。
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ì)上是通過以上四個(gè)維度進(jìn)行統(tǒng)計(jì) istio_requests_total；但在升級之后查看原始數(shù)據(jù)發(fā)現(xiàn)丟失了 destination_app, source_app 這兩個(gè) tag。
至于為啥丟失，查了許久，最后在升級后的資源文件 stats-filter-1.12.yaml 中找到了答案:
升級后新增了 tags_to_remove 標(biāo)記，將我們所需要的兩個(gè) tag 直接刪掉了。
后續(xù)在當(dāng)前 namespace 下重新建一個(gè) EnvoyFilter 資源覆蓋掉默認(rèn)的便能恢復(fù)這兩個(gè) tag，修復(fù)后監(jiān)控頁面也顯示正常了。
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說明不是數(shù)據(jù)源的問題，那就可能是數(shù)據(jù)采集節(jié)點(diǎn)的問題了。
進(jìn)入VictoriaMetrics 的 target 頁面發(fā)現(xiàn)應(yīng)用確實(shí)已經(jīng)下線，原來是采集的端口不通導(dǎo)致的。
我們使用 VictoriaMetrics 代替了 Prometheus。
而這個(gè)端口 15020 之前并未使用，我們使用的是另外一個(gè)自定義端口和端點(diǎn)來采集數(shù)據(jù)。
經(jīng)過查閱發(fā)現(xiàn) 15020 是 istio 默認(rèn)的端口：
原來在默認(rèn)情況下 Istio 會為所有的數(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)說明，如果不是使用的標(biāo)準(zhǔn) prometheus.io 注解，需要將這個(gè)設(shè)置為 false。
修改后需要重建應(yīng)用 Pod 方能生效。
有了 url 這個(gè) tag 后，接口監(jiān)控頁也恢復(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)沒有在默認(rèn) tag 列表中時(shí)，需要在 Deployment 或者是 Istio 控制面中全局加入我們自定義的 tag 聲明。
比如這里新增了 url 的 tag，那么就需要在控制面中加入：
meshConfig:
defaultConfig:
extraStatTags:
- url
修改了控制面后需要重新構(gòu)建 Pod 后才會生效。
EnvoyFilter的問題
查看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
}但并沒有生效，于是換成了在 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 所對應(yīng)的 istio_request_messages_total 指標(biāo)依然存在。
接著在我領(lǐng)導(dǎo)查看 Istio 源碼以及相關(guān) issue 后發(fā)現(xiàn) Telemetry API 和 EnvoyFilter 是不能同時(shí)存在的，也就是說會優(yōu)先使用 EnvoyFilter；這也就是為什么我之前配置沒有生效的原因。
后初始化 EnvoyFilter
正如這個(gè) issue 中所說，需要刪掉現(xiàn)在所有的 EnvoyFilter；刪除后果然就生效了。
新的 Telemetry API 不但語義更加清晰，功能也一樣沒少，借助他我們依然可以自定義、刪除指標(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é)
本次定位修復(fù) Istio 升級后帶來的指標(biāo)系統(tǒng)問題收獲巨大，之前對 Istio 一直只停留在理論階段，只知道他可以實(shí)現(xiàn)傳統(tǒng)微服務(wù)中對接口粒度的控制，完美彌補(bǔ)了 k8s 只有服務(wù)層級的粗粒度控制；
這兩周下來對一個(gè)現(xiàn)代云原生監(jiān)控系統(tǒng)也有了系統(tǒng)的認(rèn)識，從 App->Pod->sidecar->VictoriaMetrics(Prometheus)->Grafana 這一套流程中每個(gè)環(huán)節(jié)都可能會出錯；
所以學(xué)無止境吧，幸好借助公司業(yè)務(wù)場景后續(xù)還有更多機(jī)會參與實(shí)踐。
新聞名稱：Istio升級后踩的坑
瀏覽路徑：http://m.fisionsoft.com.cn/article/cdhscdd.html
