Adobe工程师介绍了一种开源方案，让团队能在多租户Kubernetes环境中自助访问自己的Prometheus指标，同时不暴露其他团队共享的数据。该设计尤其针对大量使用GPU的环境，因为团队需要查看GPU利用率和功耗，以了解昂贵的加速器资源是否得到实际利用。

问题直观却难以安全解决。一个中心化Prometheus实例可能包含来自数千个命名空间的指标，不适合向租户开放不受限制的访问；允许每个团队执行查询可能暴露其他团队数据，大量用户查询共享存储也可能导致性能问题和“吵闹邻居”问题。Adobe的解决方案是在用户与中心Prometheus之间放置一个能识别租户的代理，并可选择为每个租户提供规模较小的独立Prometheus实例。

该架构采用现有Kubernetes和CNCF技术，而非引入新的指标平台。请求先经过NGINX和kube-rbac-proxy完成身份验证和授权，再到达多租户Prometheus代理；代理识别租户、发现可用后端，并将查询范围限制在该租户的命名空间内。关键组件prom-label-proxy会修改传入的PromQL查询，强制添加命名空间约束，在查询到达Prometheus之前应用限制，防止租户构造访问其他命名空间的查询。

平台还引入名为MetricAccess的Kubernetes自定义资源，允许团队用准确的指标名称、正则表达式或PromQL选择器声明所需指标，既提供自助机制，又将底层数据采集和访问控制保留在平台团队手中。对于需要自有仪表板和告警的团队，设计可定期通过remote write将筛选后的指标写入租户专属Prometheus实例；启用metricIsolation后只采集该租户自己的时间序列，示例配置中某租户存储的时间序列数量从超过1万条减少到约300条。

眼下最直接的使用场景是GPU可见性。作者提到，他们曾发现一块GPU尽管已分配并处于通电状态，利用率却连续11天保持为零。借助GPU利用率、帧缓冲区内存、功耗和请求速率等指标，团队可以识别闲置GPU、消耗电力却无对应应用流量的GPU，或工作负载有流量但GPU资源仍未充分利用的情况。该架构并非GPU专用，其底层模式是一套围绕身份验证、查询隔离、受控指标访问及可选租户专属存储构建的租户可观测性层。