Grafana 不支持原生“Row Restrictions”，因其仅为可视化层，不存储数据也不动态裁剪查询结果；需通过数据源过滤、变量嵌入查询及文件夹权限三层控制实现行级隔离。
Grafana 本身没有名为 “Row Restrictions” 的原生机制。这个术语常见于其他 BI 工具（如 Power BI、Tableau），用于按行级字段值过滤数据可见性；但在标准 Grafana（包括开源版和 Azure 托管版）中，不支持基于查询结果中某列值（例如 namespace 字段）自动限制用户仅能看到自己所属命名空间的数据行。
为什么不能直接用“Row Restrictions”？
Grafana 是一个可视化层，它不存储原始指标数据，也不在查询执行时对返回的 time series 或表格结果做动态行级裁剪。Prometheus、Loki、Elasticsearch 等后端数据源决定返回哪些时间序列或日志条目——Grafana 只负责渲染。因此，真正的隔离必须前置到查询阶段或数据访问入口。
替代方案：用变量 + 查询过滤 + 权限控制实现等效效果
要让开发小组 A 只看到 namespace="team-a" 的指标，小组 B 只看到 namespace="team-b"，需组合以下三层控制：
-
数据源层过滤（推荐）：为每个小组配置独立 Prometheus 数据源，并在数据源 URL 中添加固定 label 过滤。例如：
•http://prom-team-a:9090?match[]={namespace=~"team-a"}
•http://prom-team-b:9090?match[]={namespace=~"team-b"}
这样所有通过该数据源发起的查询天然只覆盖对应命名空间，无需修改每条 PromQL。 -
仪表板变量 + 查询内嵌过滤：创建一个隐藏变量
namespace，默认值设为该小组专属命名空间（如team-a），并在所有面板的 PromQL 中显式加入过滤条件：
rate(http_requests_total{namespace="$namespace"}[5m])
变量值由 Grafana 管理员预设，普通用户不可编辑（设置变量为 “Hidden” + “Constant” 类型）。 -
文件夹级权限隔离：将不同小组的仪表板放入独立文件夹（如 “Team-A Dashboards”、“Team-B Dashboards”），然后为每个文件夹单独授予对应团队的
Viewer权限。配合 Grafana 团队同步（如对接 Microsoft Entra ID 组），可确保 team-a 组成员只能看到并访问 team-a 文件夹下的内容，无法发现其他命名空间的仪表板。
进阶建议：结合 Kubernetes RBAC 和多租户数据采集
如果监控数据来自集群内部（如 kube-state-metrics、cAdvisor），更彻底的做法是在采集侧就做隔离：
- 为每个开发小组部署独立的
prometheus-operator实例，限定其ServiceMonitor和PrometheusRule的namespaceSelector，只抓取本组命名空间； - 使用
PodMonitor或Probe配置时，也加上namespaceSelector.matchNames: ["team-a"]； - 这样每个小组对应一个专属 Prometheus 实例，Grafana 只需接入多个数据源——既物理隔离，又避免查询误读。
不复杂但容易忽略：关键不在“限制哪几行”，而在“不让那些行被查出来”。把边界前移到数据源和采集层，比在 Grafana 里兜圈子更可靠、更高效。
