在GPU资源价值高的复杂环境中，传统中心化Prometheus架构面临安全与性能双重难题：千级命名空间指标集中存储，向租户开放会导致数据泄露与性能干扰。Adobe所提出的开源方案通过引入租户识别代理、基于命名空间约束的PromQL过滤，以及基于Kubernetes自定义资源的指标访问控制，构建了从查询到存储的全链路隔离机制。该方案以核心组件prom-label-proxy保障查询安全性，以MetricAccess规范指标采集边界，同时通过remote write实现租户专属存储。实际场景中，该方案可显著优化资源利用，使某租户时间序列从超10000条降至约300条，彻底规避数据泄露与性能风险，为多租户下的GPU可观测与运维提供了可靠路径。随着Kubernetes多租户化趋势演进，此类兼顾数据安全与高并发访问的可观测架构，将成为企业解决GPU资源利用效能问题的重要参考。

--91likeyou---

该平台还引入了一个名为 MetricAccess 的 Kubernetes 自定义资源，允许团队声明自己需要哪些指标。指标定义可以使用准确的指标名称、正则表达式或 PromQL 选择器。这既提供了一种自助机制，又将底层的数据采集和访问控制保留在平台团队手中。

对于需要自有仪表板和告警的团队，该设计可以定期通过 remote write 将经过筛选的一组指标写入租户专属的 Prometheus 实例。启用 metricIsolation 后，只会采集该租户自己的时间序列，既减少租户 Prometheus 中存储的数据量，也限制了可供查询的数据范围。

Adobe 表示，在一个示例配置中，某个租户存储的时间序列数量从超过 10,000 条减少到了约 300 条。除了降低存储和查询需求外，这还形成了另一道隔离边界：从未被采集到租户存储中的数据，之后也就不可能通过该存储暴露出去。

这种分离方式也改变了运维模式。中心 Prometheus 继续负责整个基础设施范围内的数据采集，而租户专属的 Prometheus 实例则负责各个团队所需的仪表板和查询。因此，共享系统不必再为每位开发者的日常可观测性查询提供服务。

眼下最直接的使用场景是 GPU 可见性。加速器资源可能是一项巨大的基础设施成本，但分配了 GPU，并不意味着这些 GPU 正在执行有价值的工作。作者提到，他们曾发现一块 GPU 尽管已经分配并处于通电状态，利用率却连续 11 天保持为零。

借助 GPU 利用率、帧缓冲区内存、功耗和请求速率等指标，团队可以构建查询，识别闲置 GPU、消耗电力却没有对应应用流量的 GPU，或者虽然工作负载正在接收流量、GPU 资源却仍未得到充分利用的情况。

尽管 GPU 是最直观的示例，但该架构并非 GPU 专用。其底层模式是一套面向租户的可观测性层，围绕身份验证、查询隔离、受控的指标访问以及可选的租户专属存储构建。

随着 Kubernetes 集群逐渐成为应用团队、数据工作负载和 AI 工作负载共享的平台，这一点变得越来越重要。平台团队既需要为开发者提供足够的可观测性，又不能让中心遥测系统变成安全风险或性能瓶颈。

针对同一类多租户问题，目前已有多种成熟方案。例如，Grafana Mimir 在架构中内置了多租户隔离能力，使用租户标识符限定指标查询范围，并要求通过身份验证层建立正确的租户上下文。Mimir 还提供查询前端能力，用于管理和扩展读取路径。Cortex 是多个 Prometheus 兼容托管服务所基于的项目，它采用类似的 X-Scope-OrgID 模型，在租户之间隔离指标数据。Adobe 的方案略有不同：它保留共享 Prometheus 环境，同时在外围增加 Kubernetes 感知的访问控制和基于命名空间的过滤机制。

：

🔥 热词：#adobe gpu加速 · #一块GPU可以并行计算吗 · #一块gpu显卡多少钱 · #有一个gpu占用百分百的进程 · #一打开游戏gpu占用过高 · #gpu一下跳到100又跳回来 csdn硬件加速 · #win10一打开游戏gpu就100 · #gpu一开机就满载了