3 大体系 × 3 层指标：Milvus 全链路可观测监控搭建指南

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 96 篇，Milvus 最佳实战「2026」系列第 5 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

Milvus 监控体系全景图

Milvus 运维监控三大体系：监控、告警、日志

Milvus 在生产环境跑着跑着，突然查询变慢了。是数据量的问题？还是某个节点挂了？没有监控，你根本无从下手。向量数据库的运维有个特殊之处：它不像 MySQL 那样有几十年的运维经验可以抄，社区里踩坑分享才刚起步，很多团队都是自己摸着石头过河。

这篇教程覆盖监控、告警、日志三大体系，基于 Milvus 官方文档和社区验证过的方案，手把手带你从零搭建一套完整的运维监控栈。

你将学到什么

• ✅ 在 K8s 中部署 Prometheus + Grafana 监控栈
• ✅ 导入 Milvus 官方 Dashboard（覆盖 8 个组件）
• ✅ 配置分级告警规则和通知策略
• ✅ 用 Grafana Loki + Alloy 搭建统一日志查询系统

开始之前

你需要准备

• 一个运行中的 Kubernetes 集群（v1.30.x）
• 已通过 Helm 或 Milvus Operator 部署的 Milvus 实例（建议 v2.6.x）
• kubectl 命令行工具，且已连接到目标集群
• 集群中有足够的资源运行监控组件（建议至少 4C8G 预留）

预计时间

⏱️ 完成全部部署大约需要 40-60 分钟

难度等级

⭐⭐ 中级 - 需要 K8s 和 Helm 基础

整体架构：先看全局再动手

Milvus 监控架构图

Milvus 监控体系架构：Prometheus → Grafana → Alertmanager / Loki

先别急着敲命令，花两分钟理清整个监控架构。

Milvus 的监控体系围绕三个核心组件展开：

Prometheus 负责数据采集。Milvus 原生内置了 Prometheus 格式的指标端点（http://<host>:9091/metrics），不需要额外装 Exporter，这一点比很多中间件省事。Prometheus 每 15 秒抓取一次指标数据，存入自己的时序数据库。

Grafana 负责可视化。Milvus 官方提供了一个完整的 Dashboard JSON 文件，导入后直接能用，覆盖 Proxy、RootCoord、QueryCoord、QueryNode、DataCoord、DataNode、IndexCoord、IndexNode 这 8 个组件，面板数量超过 100 个。

Loki 负责日志聚合。和 Prometheus 同属 Grafana 生态，使用类似的标签体系，查询语言 LogQL 也和 PromQL 风格接近，学习成本低。

版本选型方面，社区验证过的稳定组合是：Milvus v2.6.14 + Prometheus v3.4.1 + Grafana v11.6.3 + Alertmanager v0.28.1。生产环境有一句老话说得对：稳定性永远比新特性更重要。

这里有个容易忽略的细节：Milvus 有两种部署模式，Standalone 和 Distributed（也叫 Cluster）。Standalone 模式下所有组件跑在一个进程里，指标统一暴露在 9091 端口，监控配置相对简单。Distributed 模式下 Proxy、QueryNode、DataNode 等组件各自独立部署，每个组件都有自己的指标端点，ServiceMonitor 需要分别配置。这篇教程以 Standalone 模式为主，但指标含义和告警逻辑两种模式通用。

第一步：部署 Prometheus + Grafana 监控栈

操作方法

Milvus 官方文档推荐使用 kube-prometheus 快速部署整套监控栈。这个项目打包了 Prometheus Operator、Prometheus、Grafana、Alertmanager 和一系列默认 Dashboard，省去逐个安装的麻烦。

1. 克隆 kube-prometheus 仓库

git clone https://github.com/prometheus-operator/kube-prometheus.git
cd kube-prometheus

2. 创建 CRD 和基础资源

# 先创建 CRD（Custom Resource Definition），等待就绪
kubectl apply --server-side -f manifests/setup

等待 CRD 全部就绪后再执行下一步，别着急。

# 确认 CRD 已创建
kubectl get crd | grep prometheus

3. 部署监控栈组件

kubectl apply -f manifests/

这一步会部署 Prometheus、Grafana、Alertmanager 等组件，拉取镜像可能需要几分钟。

4. 给 Prometheus 添加 Milvus 抓取权限

kube-prometheus 默认的 prometheus-k8s ServiceAccount 权限不够，需要打一个补丁：

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s-milvus
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["replicasets"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-k8s-milvus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-k8s-milvus
subjects:
- kind: ServiceAccount
  name: prometheus-k8s
  namespace: monitoring
EOF

5. 启用 Milvus 的 ServiceMonitor

根据你的部署方式，选择对应的配置方法：

Helm 部署的 Milvus：

helm upgrade my-release milvus/milvus \
  --set metrics.serviceMonitor.enabled=true \
  --reuse-values

Milvus Operator 部署的 Milvus：

在 Milvus CR 中确认以下配置：

spec:
  components:
    disableMetric: false

默认就是 false，一般不需要改。如果你之前手动关过，记得打开。

6. 访问 Grafana

# 端口转发到本地
kubectl port-forward -n monitoring svc/grafana 3000:3000

浏览器打开 http://localhost:3000，默认账号 admin，密码 admin。

验证成功

打开 Prometheus 的 Web UI（端口 9090），在查询框输入 up，如果你能看到 milvus 相关的 target 状态为 1，说明指标抓取正常。

# 端口转发 Prometheus
kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090

✅ 如果你在 Prometheus 的 Targets 页面看到 Milvus 相关的 endpoint 状态为 UP，恭喜你，监控数据采集已经跑通了！

常见问题

问题：Prometheus Targets 页面显示 Milvus endpoint 为 DOWN

解决方案：检查 ServiceMonitor 的 namespace selector 是否匹配 Milvus 所在的 namespace。默认情况下 kube-prometheus 只监控 monitoring、default 等命名空间。如果 Milvus 部署在其他 namespace，需要在 Prometheus 的 serviceMonitorSelector 中添加匹配规则。

问题：Grafana 登录后看不到任何数据

解决方案：确认 Prometheus 数据源已自动配置。kube-prometheus 会自动添加 Prometheus 数据源，但如果你手动安装的 Grafana，需要到 Configuration → Data Sources 中手动添加 Prometheus 的地址。

第二步：导入官方 Dashboard，读懂核心指标

Milvus 8 大组件核心指标

Milvus 8 大组件核心指标地图，重点标记代理层和查询节点

这一步是整个监控体系里信息密度最高的环节。Milvus 官方提供了完整的 Grafana Dashboard，面板超过 100 个，但真正需要日常关注的核心指标其实就那么几个。

导入官方 Dashboard

1. 下载 Dashboard JSON 文件

wget https://raw.githubusercontent.com/milvus-io/milvus/refs/heads/master/deployments/monitor/grafana/milvus-dashboard.json

2. 导入到 Grafana

• 打开 Grafana → Dashboards → Import
• 点击 Upload JSON file，选择刚才下载的 milvus-dashboard.json
• 选择 Prometheus 数据源
• 点击 Import

导入成功后你会看到一个结构清晰的 Dashboard。

核心指标解读

Milvus 的指标命名遵循 milvus_{角色}_{指标名} 的规则。下面按优先级排列，先看哪些：

顶层概览（Service Quality）

这几个指标决定了 Milvus 的整体健康状态：

Proxy（代理层）

Proxy 是 Milvus 的流量入口，所有请求都经过它。重点看这几个：

• Search Vector Count Rate：每秒处理的搜索向量数，反映系统吞吐
• Cache Hit Rate：缓存命中率，低的话说明频繁查磁盘，性能会打折
• Request Success Rate / Failed Rate：请求成功和失败的比率

QueryNode（查询节点）

这是实际执行搜索的组件，直接决定查询性能：

• Search Latency（Queue/Semcore/Reduce）：搜索延迟按阶段拆分。Queue 是排队时间，Semcore 是向量计算时间，Reduce 是结果合并时间。哪个阶段高，就优化哪个环节
• CPU Usage Ratio：QueryNode 的 CPU 占用率，向量检索是 CPU 密集型操作

DataCoord + DataNode（数据层）

数据写入和存储相关的指标：

• Segment Num：段数量，段太多会影响查询性能
• Storage Rows：存储行数，用于评估数据增长趋势
• Flush Latency：刷盘延迟，频繁 flush 会影响写入性能

IndexCoord + IndexNode（索引层）

这两个组件负责索引构建，通常在批量导入数据或重建索引时需要重点关注：

• Index Task Rate：索引构建任务的速率
• Build Index Latency：构建索引的耗时，向量索引（如 IVF、HNSW）构建时间通常较长
• Save Index Latency：索引保存到磁盘的耗时

RootCoord（根协调器）

管理全局元数据的组件，DDL 操作（创建/删除 Collection）都经过它：

• DDL Request Rate / Latency：DDL 请求速率和延迟
• Collection Num / Partition Num：当前 Collection 和 Partition 数量
• Timestamp：时间戳相关指标，用于判断系统时钟是否正常

说实话，100 多个面板全看一遍不太现实。建议先把 Service Quality 概览和 Proxy 面板盯住，这两个覆盖了 80% 的日常运维场景。其他组件的面板出了问题再针对性看。

第三步：配置告警规则

告警工作流程

从指标采集到通知发送的完整告警链路

监控看板搭好了，但你不可能 24 小时盯着屏幕。告警规则就是把你的注意力从大海捞针变成有异常才看。

基于 Grafana 创建告警

在 Grafana 中为 Milvus 创建告警的步骤：

1. 在 Dashboard 中添加告警规则

打开 Milvus Dashboard，找到一个关键面板（比如内存使用率），点击面板标题 → Edit → Alert，然后创建告警规则。

2. 配置告警查询

以内存使用率为例，PromQL 查询语句：

process_resident_memory_bytes{app_kubernetes_io_name="milvus", app_kubernetes_io_instance=~"my-release", namespace="default"}

注意：Grafana 告警查询不支持模板变量（如 $instance），必须写死具体的标签值。

3. 设置阈值和通知方式

阈值设置可以参考通用的默认规则作为基线：

4. 配置通知通道

在 Grafana 的 Alerting → Contact Points 中添加通知方式：钉钉 Webhook、企业微信、邮件等，根据团队习惯选一个。

基于 Prometheus AlertManager 的告警

如果你用的是 kube-prometheus 全家桶，Alertmanager 已经部署好了。创建一个 Milvus 专用的告警规则文件：

# milvus-alerts.yaml
groups:
  - name: milvus-alerts
    rules:
      # Milvus 服务存活监控
      - alert: MilvusServerDown
        expr: up{job="milvus"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Milvus 实例 {{ $labels.instance }} 不可用"

      # 内存使用率过高
      - alert: MilvusHighMemory
        expr: process_resident_memory_bytes{job="milvus"} / (1024 * 1024 * 1024) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Milvus 内存持续偏高"

      # 慢查询过多
      - alert: MilvusSlowQuery
        expr: increase(milvus_slow_query[5m]) > 10
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Milvus 近 5 分钟慢查询数量异常"

      # 搜索失败率过高
      - alert: MilvusHighSearchFailureRate
        expr: rate(milvus_proxy_search_vectors_count{status="failed"}[5m]) / rate(milvus_proxy_search_vectors_count[5m]) > 0.05
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Milvus 搜索失败率超过 5%"

上面的 YAML 只是基础框架，实际使用时需要根据你的 Milvus 实例规格计算合理的内存阈值。

告警收敛的几个实用原则：

• 抖动过滤：设置 for: 5m，连续 5 分钟超过阈值才触发，避免瞬尖导致误报
• 分级通知：Warning 级别发消息，Critical 级别发短信，Fatal 级别打电话
• 告警抑制：同一实例已触发 Critical 告警时，自动屏蔽该实例的 Warning 告警

关于阈值怎么定，有一个实用的思路：先跑一周观察正常基线。比如你的 Milvus 正常情况下 Search Latency P99 在 50ms 左右，那告警阈值可以设到 150ms-200ms，留出足够的缓冲空间。不要上来就设很紧的阈值，否则告警疲劳会让整个告警体系形同虚设。

Alertmanager 的路由配置支持这些策略：

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default'

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

验证成功

# 检查告警规则是否加载
kubectl exec -n monitoring prometheus-prometheus-k8s-0 \
  -- wget -qO- http://localhost:9090/api/v1/rules | grep milvus

✅ 如果你能看到刚才创建的告警规则名称，说明规则已生效。

常见问题

问题：Grafana 告警创建后一直显示 Pending

解决方案：检查 PromQL 查询是否能返回数据。在 Grafana 的 Explore 页面先跑一遍你的查询语句，确认有结果。

第四步：搭建日志系统（Grafana Loki + Alloy）

日志采集管线

日志采集管线：Milvus Pod → Alloy → Loki → Grafana Explore

指标和告警解决了出了什么问题的问题，但为什么出问题往往需要看日志。Milvus 的组件日志分散在各个 Pod 里，kubectl logs 翻起来效率很低。Loki 把所有日志集中到一个地方，用标签过滤，查询速度快很多。

部署 Loki

1. 添加 Grafana Helm 仓库

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

2. 配置对象存储

Loki 需要对象存储来保存日志数据。测试环境可以用 MinIO，生产环境建议用云厂商的对象存储。这里以 MinIO 为例：

# loki-values.yaml
loki:
  commonConfig:
    replication_factor: 1
  auth_enabled: false
minio:
  enabled: true

3. 安装 Loki

kubectl create ns loki
helm install --values loki-values.yaml loki grafana/loki -n loki

部署 Alloy 采集日志

Milvus 官方文档推荐使用 Alloy（Promtail 的继任者）来采集日志。Alloy 是 Grafana 生态中的新一代可观测性收集器，基于 OpenTelemetry Collector 构建，可以同时处理 metrics、logs、traces 三类信号。相比 Promtail，Alloy 的配置更灵活，且官方持续维护。如果你是全新部署，建议直接用 Alloy。

1. 创建 Alloy 配置文件

# alloy-values.yaml
alloy:
  configMap:
    content: |
      loki.write "default" {
        endpoint {
          url = "http://loki-gateway.loki.svc:80/loki/api/v1/push"
        }
      }

      discovery.kubernetes "pods" {
        role = "pod"
      }

      discovery.relabel "pods" {
        targets = discovery.kubernetes.pods.targets

        rule {
          source_labels = ["__meta_kubernetes_pod_name"]
          target_label  = "pod"
        }
        rule {
          source_labels = ["__meta_kubernetes_namespace"]
          target_label  = "namespace"
        }
        rule {
          source_labels = ["__meta_kubernetes_pod_container_name"]
          target_label  = "container"
        }
      }

      loki.source.kubernetes "pods" {
        targets    = discovery.relabel.pods.output
        forward_to = [loki.write.default.receiver]
      }

这个配置会采集所有 K8s Pod 的日志并发送到 Loki。如果你只想采集 Milvus 相关的日志，可以在 discovery.relabel 中添加 namespace 过滤。

2. 安装 Alloy

helm install alloy grafana/alloy -n loki -f alloy-values.yaml

配置 Grafana 数据源并查询日志

1. 添加 Loki 数据源

在 Grafana 中：Connections → Add new connection → 选择 Loki → 填入 Loki 的 URL（如 http://loki-gateway.loki.svc:80）→ Save & test。

2. 查询 Milvus 日志

在 Grafana 的 Explore 页面，选择 Loki 数据源，输入查询：

{namespace="default", app_kubernetes_io_name="milvus"}

如果你想过滤特定关键词：

{namespace="default", app_kubernetes_io_name="milvus"} |= "error"

验证成功

在 Grafana Explore 页面执行上面的 LogQL 查询，如果你能看到 Milvus Pod 的日志输出，说明日志采集链路已经打通。

✅ 如果你能查到日志并且时间戳正确（注意 Docker 镜像默认使用 UTC 时区），日志系统部署完成！

进阶：Milvus 访问日志配置

Milvus 还提供了一个独立的访问日志功能，可以记录每一次请求的详细信息，包括用户、耗时、集合名称等。对于排查慢查询和审计需求很有用。

在 Milvus 的配置中启用访问日志：

proxy:
  accessLog:
    enable: true
    filename: "access_log.txt"
    localPath: "/var/logs/milvus"
    maxSize: 500           # 单个日志文件最大 500MB
    rotatedTime: 24        # 每 24 小时轮转一次
    maxBackups: 7          # 保留最近 7 个日志文件

Milvus 支持自定义日志格式，可以用 17 个内置变量自由组合。比如按查询类型分别配置格式：

proxy:
  accessLog:
    enable: true
    formatters:
      base:
        format: "[$time_now] [ACCESS] <$user_name: $user_addr> $method_name-$method_status-$error_code [traceID: $trace_id] [timeCost: $time_cost]"
      query:
        format: "[$time_now] [ACCESS] <$user_name: $user_addr> $method_status-$method_name [traceID: $trace_id] [timeCost: $time_cost] [database: $database_name] [collection: $collection_name]"
        methods: ["Query", "Search"]

这样 Query 和 Search 操作会额外记录数据库名和集合名，其他操作用基础格式。支持的变量包括 $method_name、$time_cost、$trace_id、$collection_name、$error_code 等，覆盖了常见的排查需求。

如果日志量比较大，还可以配置自动上传到 MinIO：

proxy:
  accessLog:
    enable: true
    minioEnable: true
    remotePath: "/milvus/logs/access_logs"
    remoteMaxTime: 0        # 0 表示不限制上传时间

常见问题汇总

Q1：kube-prometheus 安装后 Prometheus 没有抓取到 Milvus 指标？

A：按顺序排查：① 确认 ServiceMonitor 已创建（kubectl get servicemonitor）；② 确认 Prometheus 的 serviceMonitorNamespaceSelector 包含 Milvus 所在的 namespace；③ 确认 Milvus 的指标端点（9091 端口）可访问。

Q2：官方 Dashboard 导入后有些面板显示 No Data？

A：这通常是因为标签值不匹配。官方 Dashboard 的变量可能用了固定的 label（如 app_kubernetes_io_instance），如果你的 Milvus 部署用了不同的 release name 或标签，需要手动调整 Dashboard 变量。

Q3：Loki 日志查询很慢怎么办？

A：Loki 的查询性能和标签索引有关。确保查询时至少包含一个标签（如 {namespace="default"}），避免全量扫描。日志量大时建议启用 Loki 的 chunk cache 和写入去重。

Q4：Promtail 和 Alloy 该选哪个？

A：新项目建议直接用 Alloy。Milvus 官方文档已更新为推荐 Alloy，它是 Promtail 的继任者，功能更全面。已有 Promtail 的环境可以继续用，不用急着迁移。

下一步学习

• 📚 Milvus WebUI（v2.6.x）：通过 http://<host>:9091/webui 直接查看系统状态，轻量级监控的快速入口
• 📚 Attu：Milvus 的开源 GUI 管理工具，适合日常数据管理和 Collection 操作
• 📚 Milvus Backup：官方数据备份工具，配合监控告警使用更安心

总结

回顾一下，这篇教程覆盖了 Milvus 运维监控的三个核心体系：

监控：Prometheus 通过 ServiceMonitor 自动发现 Milvus 指标端点，Grafana 导入官方 Dashboard 后可查看 8 个组件的 100+ 面板。日常重点盯 Service Quality 概览和 Proxy 面板。

告警：以常用的默认阈值（内存 ≥80%、CPU ≥90%）为基线，配合抖动过滤和分级通知，做到有异常才通知，通知了就是真问题。

日志：Loki + Alloy 把分散在各个 Pod 的日志集中管理，用 LogQL 标签过滤，查询效率比 kubectl logs 高得多。

三个体系搭建完成后，你的 Milvus 就从裸奔状态变成了全面可观测。建议收藏这篇教程，下次搭建监控环境时直接翻出来跟着做。

官方文档：https://milvus.io/docs/monitor_overview.md

官方 Dashboard JSON：https://github.com/milvus-io/milvus/blob/master/deployments/monitor/grafana/milvus-dashboard.json

kube-prometheus 项目：https://github.com/prometheus-operator/kube-prometheus

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！