企业官网建设流程全解析

• 时序数据库
• 后端
• 数据存储
• 可观测性
• 云原生

导读

本指南围绕 Grafana Mimir 自带的Overview networking（网络总览）仪表盘展开，介绍其展示的接收/发送带宽、in-flight 请求与 TCP 连接三类核心网络指标，以及 "Writes"（写入路径）、"Reads"（读取路径）、"Backend"（后端组件）三组面板的划分逻辑。读完本文，你将了解该仪表盘适用于哪些运维场景、依赖哪些前置指标与标签、每个面板背后的 PromQL 查询逻辑，以及如何通过预编译 JSON 或 Jsonnet mixin 源码安装和定制这张仪表盘。

一、Overview networking 仪表盘是什么

Grafana Mimir 自带一套生产级 Grafana 仪表盘与告警，用于监控 Mimir 集群的状态与健康度，Overview networking 正是其中负责"集群网络状况"总览的一张仪表盘（原文档见 docs/sources/mimir/manage/monitor-grafana-mimir/dashboards/overview-networking/index.md）。

它集中展示以下三类指标：

• Receive bandwidth / Transmit bandwidth（接收带宽 / 发送带宽）：各组件的容器网络收发速率；
• Inflight requests（in-flight 请求数）：当前正在处理中、尚未完成的请求数量；
• Ingress TCP connections（入站 TCP 连接数）：包括 HTTP 与 gRPC 协议的入站连接数，以及与连接数上限的对比。

仪表盘将 Mimir 组件按功能分为Writes（写入）、Reads（读取）、Backend（后端）三组进行展示。这一分组并非随意划分，而是直接来自 mixin 源码中的componentGroups定义（见 operations/mimir-mixin/config.libsonnet）：

注：实际面板选择组件时用的是instance_names匹配器（默认以pod标签匹配），而不是job标签，目的是在微服务模式下只选中具体部署（如只选中 distributor），详见下文"按 instance 匹配组件"一节。

二、适用场景：什么时候看这张仪表盘

官方文档给出了三个典型使用场景：

1. 确认组件间网络通信性能处于最优状态：观察各组件收发带宽是否存在异常峰值、带宽是否被打满，判断链路是否存在瓶颈。
2. 监控网络流量的突变与 in-flight 请求的增长：in-flight 请求突然升高往往意味着组件处理变慢、请求堆积，是潜在故障的前兆，需要及时介入排查。
3. 监控 TCP 连接以发现影响数据写入与查询性能的瓶颈或连接问题：连接数接近上限、连接反复抖动都可能导致写入或查询失败。

三、前置要求：依赖 Additional resources metrics

使用这张仪表盘有一个明确的前置条件：需要 additional resources metrics（额外的资源指标）。这是它在所有 Grafana Mimir 仪表盘中比较特殊的一点——网络带宽面板依赖从基础设施层面采集的指标，而不是 Mimir 自身暴露的指标。

根据 docs/sources/mimir/manage/monitor-grafana-mimir/requirements.md 的说明，提供这些资源指标需要以下采集器：

• cAdvisor（容器资源指标，container_network_*系列即来自 cAdvisor）
• kubelet（Kubernetes 系统组件指标）
• Node Exporter（节点网络与磁盘指标，node_network_*、node_disk_*系列）
• kube-state-metrics（Kubernetes 对象状态指标）

同时还需要满足标签约束：

• 来自 kubelet、kube-state-metrics 和 cAdvisor 的指标，其cluster标签必须与 Mimir 指标的cluster标签取值一致；
• 来自 Node Exporter 和 cAdvisor 的指标，其instance标签必须与 Mimir 指标的instance标签取值一致。

如果使用mimir-distributedHelm chart 的metamonitoring（元监控）能力，这些标签会自动处理好；否则需要在 Prometheus 或 Grafana Alloy 的抓取配置中自行添加cluster、namespace、job、pod、instance等标签（其中cluster、namespace、job、pod、instance均可在编译 mixin 时通过per_cluster_label、per_namespace_label、per_job_label、per_instance_label、per_node_label等配置字段定制）。

四、面板构成与查询原理（源码级解析）

Overview networking 仪表盘由 Jsonnet mixin 源码构建，核心实现位于 operations/mimir-mixin/dashboards/overview-networking.libsonnet，其构建逻辑如下：

($.dashboard('Overview networking') + { uid: std.md5(filename) }) .addClusterSelectorTemplates(false) .addRowIf($._config.gateway_enabled, $.containerNetworkingRowByComponent('Gateway', 'gateway')) .addRow($.containerNetworkingRowByComponent('Writes', 'write')) .addRow($.containerNetworkingRowByComponent('Reads', 'read')) .addRow($.containerNetworkingRowByComponent('Backend', 'backend'))

也就是说，这张仪表盘最多包含四行（Row）：

1. Gateway（可选）：仅当配置启用了 gateway（gateway_enabled为真，默认跟随gem_enabled，见 operations/mimir-mixin/config.libsonnet）时通过addRowIf渲染；
2. Writes：匹配写入路径（distributor + ingester）；
3. Reads：匹配读取路径（query-frontend、querier、ruler-query-frontend、ruler-querier）；
4. Backend：匹配后端组件（query-scheduler、ruler、store-gateway、compactor、alertmanager 等）。

注意addClusterSelectorTemplates(false)：与 Overview 等其他仪表盘不同，它不启用 "all" 选项的 cluster 模板，且 namespace 模板被显式设置为includeAll: false（源码注释为 "Do not allow to include all namespaces"），避免因未选择具体 namespace 而把所有集群数据一次性拉进来。

每一行都由containerNetworkingRowByComponent函数生成四个面板（见 operations/mimir-mixin/dashboards/dashboard-utils.libsonnet）。

4.1 Receive bandwidth / Transmit bandwidth（接收/发送带宽）

这两个面板由 containerNetworkBytesPanel 生成，面板单位统一为Bps，采用堆叠（stack）显示并支持显示全部 tooltip，图例以instance（默认pod）标签区分。

在Kubernetes 部署下，底层查询（见 config.libsonnet 的resources_panel_queries.kubernetes）为：

sum by(pod) (rate(container_network_receive_bytes_total{namespace=~"$namespace", pod=~"<组件匹配器>"}[$__rate_interval])) sum by(pod) (rate(container_network_transmit_bytes_total{namespace=~"$namespace", pod=~"<组件匹配器>"}[$__rate_interval]))

在baremetal（裸金属）部署下，查询则改用 Node Exporter 的节点网络指标（见 config.libsonnet）：

sum by(instance) (rate(node_network_receive_bytes_total{namespace=~"$namespace", instance=~"<组件匹配器>"}[$__rate_interval])) sum by(instance) (rate(node_network_transmit_bytes_total{namespace=~"$namespace", instance=~"<组件匹配器>"}[$__rate_interval]))

两个面板分别对应预编译 JSON 中的 "Receive bandwidth" 与 "Transmit bandwidth" 面板（见 operations/mimir-mixin-compiled/dashboards/mimir-overview-networking.json）。

4.2 Inflight requests（in-flight 请求数）

面板标题为Inflight requests (per pod)，单位short，同时绘制两列序列：

avg(cortex_inflight_requests{namespace=~"$namespace", pod=~"<组件匹配器>"}) max(cortex_inflight_requests{namespace=~"$namespace", pod=~"<组件匹配器>"})

即取组内各实例 in-flight 请求数的平均与最高两个视角：平均值反映整体负载水平，最大值反映是否存在单实例请求堆积的尖峰。cortex_inflight_requests由 Mimir 自身暴露（Gauge 类型，标签含method、route），其语义可参见 pkg/querier/dispatcher.go 中的说明：Mimir 会同时上报cortex_querier_inflight_requests（querier 维度）与cortex_inflight_requests（通用服务器维度），相关测试用例见 pkg/querier/dispatcher_test.go。从源码结构看，in-flight 请求数持续走高是"处理能力跟不上入站流量"的直接信号，通常与查询/推送并发高峰或下游依赖变慢相关。

4.3 Ingress TCP connections（入站 TCP 连接数）

面板标题为Ingress TCP connections (per pod)，面板描述为"The number of ingress TCP connections (HTTP and gRPC protocol)"，同样以short为单位绘制三条序列：

avg(sum by(pod) (cortex_tcp_connections{namespace=~"$namespace", pod=~"<组件匹配器>"})) max(sum by(pod) (cortex_tcp_connections{namespace=~"$namespace", pod=~"<组件匹配器>"})) min(cortex_tcp_connections_limit{namespace=~"$namespace", pod=~"<组件匹配器>"})

• 前两行分别显示每个 pod 入站连接数的平均与最高（先按 pod 聚合再求聚合值）；
• 第三行显示cortex_tcp_connections_limit（连接数上限）的min值，作为参考上限线。

当实际连接数（avg/max 曲线）逼近或持续触及 limit 线时，说明该组件正在耗尽 TCP 连接资源，可能影响数据写入与查询性能——这正是官方文档建议用这张仪表盘排查连接瓶颈的原因。

五、按 instance 匹配组件：为什么不用 job 选择

一个值得注意的细节是：Overview networking 的行面板在选择组件时，不通过job标签而是通过 instance（默认pod）标签正则匹配。containerNetworkingRowByComponent源码中明确注释：

Match series using namespace + instance instead of the job so that we can select only specific deployments (e.g. "distributor in microservices mode").

这样做的目的是精准选中某类部署（如微服务模式下的 distributor），避免与同 namespace 中其他应用或单二进制（monolithic）部署的mimirjob 混淆。组件匹配器定义在 config.libsonnet 的instance_names中：

• 单组件（如distributor、ingester、query_frontend）用instanceMatcher(componentNameRegexp.<组件>)生成；
• 分组（write、read、backend）用componentsGroupMatcher把组内各组件正则用|连接后套入同一个 instance 匹配器。

在 Kubernetes 部署下，匹配器会被包装成 Helm 兼容形式(.*mimir-)?<regexp>.*。以预编译 JSON 中的 Writes 行为例，实际表达式会展开为：

avg(cortex_inflight_requests{cluster=~"$cluster", namespace=~"$namespace", pod=~"(.*mimir-)?(distributor|ingester).*"})

（见 operations/mimir-mixin-compiled/dashboards/mimir-overview-networking.json）。因此，若你自行定制了 mixin 的per_instance_label（默认pod），面板会自动跟随该配置。

六、部署类型与集群选择

6.1 Kubernetes 与 baremetal 的差异

默认情况下，所有 Grafana Mimir 仪表盘都假定 Mimir 部署在 Kubernetes 上（对应deployment_type: 'kubernetes'）。如果你运行在裸金属环境，需要在 mixin 配置中设置deployment_type: 'baremetal'并重新编译仪表盘。这一设置直接决定网络带宽面板的底层指标来源：

• kubernetes：container_network_receive_bytes_total/container_network_transmit_bytes_total（cAdvisor，按 pod 聚合）；
• baremetal：node_network_receive_bytes_total/node_network_transmit_bytes_total（Node Exporter，按 instance 聚合）。

6.2 集群与 namespace 选择器

仪表盘顶部提供cluster（集群）与namespace（命名空间）两个下拉模板变量。在单二进制（singleBinary）部署下仅提供job变量；在微服务部署下提供cluster+namespace（若启用 compartments，还会额外提供read_compartment变量），相关逻辑见 dashboard-utils.libsonnet。由于本仪表盘调用了addClusterSelectorTemplates(false)，namespace不允许选择 "All"，以确保面板查询始终落在具体的命名空间范围内。

七、安装与使用方式

7.1 从预编译包安装

Grafana Mimir 官方提供了已经编译好的 JSON 仪表盘，可以直接导入 Grafana：

1. 下载仪表盘 JSON：operations/mimir-mixin-compiled/dashboards/mimir-overview-networking.json；
2. 在 Grafana 中通过Import dashboard导入该 JSON 文件；
3. 同时在 Prometheus 中安装配套的 recording rules（operations/mimir-mixin-compiled/rules.yaml）与 alerts（operations/mimir-mixin-compiled/alerts.yaml）。

预编译仪表盘使用默认标签配置（cluster、namespace、job、pod、instance），不支持定制标签名；需要定制标签名的场景请改用源码编译方式。

7.2 从 Jsonnet mixin 源码编译

仪表盘全部由 Jsonnet 定义，可以从源码编译并定制配置：

1. 克隆 Mimir 源码仓库；
2. 查看并修改 mixin 配置 operations/mimir-mixin/config.libsonnet（如deployment_type、per_instance_label、per_namespace_label、gateway_enabled等）；
3. 执行make build-mixin编译；
4. 将生成结果导入 Grafana（operations/mimir-mixin-compiled/dashboards/）并安装到 Prometheus。

如果已经用 Jsonnet 管理基础设施，还可以把 mixin 以 vendor 方式集成进自己的仓库，通过_config+::覆写配置后再编译。

八、实际效果示例

下图是官方文档提供的一张来自 demo 集群的 Overview networking 仪表盘截图，展示了 Writes / Reads / Backend 各组面板在同一页面上的呈现效果：

从图中可以看到，每个分组行都包含接收带宽（Receive bandwidth）、发送带宽（Transmit bandwidth）、每 pod in-flight 请求数（Inflight requests (per pod)）与每 pod 入站 TCP 连接数（Ingress TCP connections (per pod)）四个面板，与上文源码解析的四面板结构一一对应。

九、排查实践建议

结合官方文档列出的用途与上文的面板原理，给出几条实战建议：

• 看整体：优先观察各组的 Transmit/Receive bandwidth 是否出现持续高位或突增，判断是否需要扩容或检查跨组件调用量异常；
• 看堆积：若某个分组（尤其是 Writes 组的 ingester 或 Reads 组的 querier）的 Inflight requests (per pod) 平均值快速上升且最大值远超平均值，说明存在请求堆积，应结合组件自身延迟指标（可跳转至对应的 Writes / Reads / Queries 仪表盘）进一步定位；
• 看连接：若 Ingress TCP connections 的 avg/max 曲线逼近甚至越过cortex_tcp_connections_limit参考线，需要排查连接泄漏、连接数配置上限以及是否存在大量短连接；
• 先满足前置条件：确认 Prometheus 抓取到了 cAdvisor/kubelet/Node Exporter/kube-state-metrics 的指标，且cluster、instance等标签与 Mimir 指标一致，否则带宽面板会显示为空。

十、相关资源

• 本仪表盘官方文档：docs/sources/mimir/manage/monitor-grafana-mimir/dashboards/overview-networking/index.md
• 仪表盘总览：docs/sources/mimir/manage/monitor-grafana-mimir/dashboards/_index.md
• 标签与前置指标要求：docs/sources/mimir/manage/monitor-grafana-mimir/requirements.md
• 安装仪表盘与告警：docs/sources/mimir/manage/monitor-grafana-mimir/installing-dashboards-and-alerts.md
• mixin 源码（本仪表盘定义）：operations/mimir-mixin/dashboards/overview-networking.libsonnet
• 面板构建工具函数：operations/mimir-mixin/dashboards/dashboard-utils.libsonnet
• mixin 全局配置（分组、标签、指标查询）：operations/mimir-mixin/config.libsonnet
• 预编译 JSON：operations/mimir-mixin-compiled/dashboards/mimir-overview-networking.json

• 时序数据库
• 后端
• 数据存储
• 可观测性
• 云原生