我们很高兴地宣布Grafana Enterprise Metrics (GEM)1.5的发布。虽然这个版本包含了大量的增强功能和错误修复，但我们想深入探讨两个特别令人兴奋的功能：每个租户的使用指标和一个用于查询的通配符租户。
GEM对于试图在其公司提供Prometheus-as-a-service服务的可观察性团队来说，最重要的一点是它对多租户的原生支持。这使得可观察性团队可以运行一个GEM集群来支持多个团队，但让每个团队都能体验到拥有一个专门的度量数据库。因为每个团队都被分配了自己的租户，他们的数据和查询是相互隔离的。经营者还可以对每个租户设置限制，以确保集群的资源在用户之间公平共享。
鉴于许多GEM运营商对多租户的依赖程度很高，我们知道了解每个租户的系统使用情况对他们很有价值。相对于TenantB，TenantA有多少个活动系列？相对于租户C来说，租户B有多少次查询？在租户直接映射到开发团队的组织中，回答这些问题可以使可观察性团队确定谁在发送最多指标，编写最多警报和记录规则，以及运行最大量的查询。当需要分配成本或确定谁的使用量失控时，这一点很重要。
那么，我们做了什么？在GEM 1.4中，我们利用我们所做的开发来实现自我监控，我们在GEM中为每个租户的使用和限制设置增加了遥测指标。然后，GEM自己收集这些指标，并将它们写入其专门的系统监控租户，然后可以像其他时间序列一样通过PromQL进行查询。
为了使这些信息更容易被使用，我们创建了一套预建的仪表板，这些仪表板会随着GEM插件自动安装。观察力团队可以从显示所有租户的概览仪表板开始，然后深入到他们感兴趣的任何租户的更详细的视图。
仪表板还显示了租户的使用情况与它的限制的关系。GEM的操作人员现在可以很容易地发现那些超出其限制的租户，并决定是否增加这些限制或与团队合作以减少他们的使用。
我们建议为每个租户设置使用限制，以避免任何一个租户导致GEM瘫痪的风险。出于这个原因，每个租户的使用仪表板也会突出显示未设置限制的租户，这样GEM管理员就可以回去正确配置它们。
用于查询的通配符租户名称
GEM的admin-api允许用户创建访问策略，对多个租户授予读取权限。例如，你可以创建一个读取访问策略，让你读取Tenant1、Tenant2和Tenant3的指标。
当查询GEM时，你使用user 字段来指定你想读取的这些租户中的哪个。如果你想查询Tenant1，把user 设为Tenant1 。如果你想查询Tenant1和Tenant2，使用管道（|）字符，把user 设为Tenant1|Tenant2 。如果你想一次性查询所有三个租户，把user 设为Tenant1|Tenant2|Tenant3 。
虽然这在我上面的简单例子中工作得很好，但你可以看到，当你想查询一大批租户时，这就开始变得很痛苦。即使租户的数量较少，如果你忘记或拼错了你可以访问的特定租户的名字，你也会有问题。
因此，在GEM 1.5中，我们借助通配符（）字符，着手减轻了一些这种痛苦*。在你的查询中，将user 字段设置为*，GEM就会针对你的读权限策略给予你的所有租户运行查询，而不必明确列举它们。在上面的例子中，笨重的Tenant1|Tenant2|Tenant3 字符串被替换成一个字符（*）：
之前：
curl -u “TeamA|TeamB|TeamC|TeamD:$API_TOKEN” ''
之后：
curl -u “*:$API_TOKEN” 'http://enterprise-metrics/api/v1/query?query=up&time=2015-07-01T20:10:51.781Z'
这是一个很小的变化，但对用户来说是一个非常好的生活质量改进。当与GEM现有的创建通配符阅读访问策略的能力结合使用时，它释放了一个特别强大的用例。通配符阅读访问策略允许用户在GEM集群中查询任何租户。为用户字段指定一个* ，为通配符读取访问策略指定一个密码，GEM将针对集群中的所有租户运行你的查询。通过这种方法，你可以保证始终获得集群中所有租户的数据，而不必在GEM中添加或删除租户时更新user 。
注意：虽然通配符的功能非常强大，但如果使用不当也会非常危险。你最终可能会运行大量的查询，这可能会使你的集群崩溃，或者泄露对你打算保密的数据的访问。慎重地使用它们
有了这个警告，我鼓励你去看看GEM 1.5，并亲自测试一下这些新功能
