Skip to main content

Command Palette

Search for a command to run...

在 Istio 中合并监控指标

Updated
2 min read

前些天阅读 Istio 文档的时候发现个语焉不详的东西:Metrics Merging,原文如下:

This option is enabled by default but can be disabled by passing --set meshConfig.enablePrometheusMerge=false during installation. When enabled, appropriate prometheus.io annotations will be added to all data plane pods to set up scraping. If these annotations already exist, they will be overwritten. With this option, the Envoy sidecar will merge Istio’s metrics with the application metrics. The merged metrics will be scraped from /stats/prometheus:15020.

大致翻译一下:这是一个缺省开放的功能,可以在安装时用 --set meshConfig.enablePrometheusMerge=false 参数停用这个功能。这个功能启用后,相对应的 prometheus.io 注解就会被加入到所有数据面 Pod 上,以启用 Prometheus 的指标抓取能力。如果这些注解已经存在,那么就会被覆盖。有了这样的功能,Envoy Sidecar 就会把应用指标和 Istio 指标进行合并,Prometheus 可以从 :15020/stats/prometheus 拉取合并后的指标。

看完之后,一头雾水。翻翻代码看到另一番说辞:

applyPrometheusMerge configures prometheus scraping annotations for the "metrics merge" feature. This moves the current prometheus.io annotations into an environment variable and replaces them pointing to the agent.

这段代码实现了指标合并功能。它会把当前的 prometheus.io 注解保存到环境变量之中,并且将原有注解替换为指向 Agent 的内容。

再结合相关代码,大概可以推断其功能大致如下:

  1. 网格化微服务在网格化之前使用 prometheus.io 注解标注的抓取方法,会被保存到 Sidecar 的环境变量之中;

  2. 合并指标功能,能够将被网格劫持的微服务输出的 Promethues 指标和 Sidecar 自身指标进行合并,输出到 :15020/stats/prometheus 端点,供 Prometheus 拉取。

我们用 Python 的 Prometheus Exporter SDK 中的测试代码做一个示例应用,并使用如下 Dockerfile 进行打包:

FROM python:3.9.13-slim-buster
RUN pip install prometheus-client && mkdir app
COPY server.py /app/server.py
WORKDIR /app
EXPOSE 8000
CMD [ "python3", "server.py" ]

使用 Docker 运行一下,可以看到他输出的简单指标:

$ docker run -p 8000:8000 dustise/promclient:v0.1
Unable to find image 'dustise/promclient:v0.1' locally
v0.1: Pulling from dustise/promclient
...
Status: Downloaded newer image for dustise/promclient:v0.1
$ curl http://127.0.0.1:8000
...
# HELP request_processing_seconds_created Time spent processing request
# TYPE request_processing_seconds_created gauge
request_processing_seconds_created 1.6597804647800276e+09
...

会看到指标中是一些请求相关和 Python 特定的内容,这正像我们一个提供了监控指标的微服务,那么如何将这些“业务”指标和 Sidecar 合并输出呢?根据上文,需要加上 Prometheus 的注解,因此我们准备这样一个 YAML:

apiVersion: apps/v1
kind: Deployment
...
  template:
    metadata:
...
      annotations:
        prometheus.io/path: /
        prometheus.io/port: 8000
        prometheus.io/scrape: true
    spec:
...
---
apiVersion: v1
kind: Service
...

注入 Sidecar 并提交到集群:istioctl kube-inject -f promclient.yaml | kubectl apply -f -

成功后,可以看看新 Pod 是不是发生了像文档所说的变化:

$ kubectl describe po promclient-6c74596f4f-r5z29 | grep prometheus.io
              prometheus.io/path: /stats/prometheus
              prometheus.io/port: 15020
              prometheus.io/scrape: true

看到我们原有的注解的确被替换为缺省内容,那原有内容是不是出现在环境变量之中?

$ kubectl exec -it [pod] -c istio-proxy -- env |  | grep ANNO
ISTIO_PROMETHEUS_ANNOTATIONS={"scrape":"true","path":"/","port":"8000"}

果然出现在这里了。那么指标是否完成合并了?采集一下 Pod 的 15020 端口:

$ http 10.52.1.11:15020/stats/prometheus | grep python | more
# HELP python_gc_objects_collected_total Objects collected during gc
# TYPE python_gc_objects_collected_total counter
python_gc_objects_collected_total{generation="0"} 101.0
python_gc_objects_collected_total{generation="1"} 273.0
...

可以看到,指标已经被合并到了 Sidecar 指标中之中。

方法固然简单,还是存在一些不适用的场景,例如:

  1. 用 mTLS 抓取指标

  2. 应用指标和 Sidecar 指标重名

  3. Prometheus 未配置按照标准注解进行抓取

遇到上述问题,可能就需要关掉合并功能,采用自定义抓取的方式了。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts