VictoriaMetrics 集群多租户用量统计Per-Tenant Statistic实战指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics导读VictoriaMetrics 集群版Cluster在企业版中提供了按租户Tenant由accountID与projectID唯一标识拆分的资源用量与统计能力通过vminsert、vmselect、vmstorage三个组件暴露一组vm_tenant_*系列指标覆盖数据写入、查询延迟、活跃时间序列、磁盘占用与序列变更率Churn Rate等维度。本文以仓库文档 docs/victoriametrics/PerTenantStatistic.md 为主体结合源码与本地 Dashboard 配置完整讲解这些指标的语义、抓取配置、可视化、内部计费模型以及与vmgateway限流和vmalert告警的联动方案。读完本文你将能够为每个租户建立可观测、可计费、可告警的完整用量跟踪体系。说明Per-Tenant Statistic 属于 VictoriaMetrics 企业版能力。该能力可从官方 Releases 页面下载评估版获取 License Key 后可申请免费试用 License。一、为什么需要按租户统计VictoriaMetrics 集群天然支持多租户vminsert通过请求头如AccountID/ProjectID把数据路由到对应租户的vmstorage分片vmselect再按租户维度查询。在多组织、多团队、多客户共用一个集群的场景下运维者迫切需要回答以下问题哪个租户给存储层带来了最大的写入压力哪个租户发起了最重的查询哪个租户在内存和磁盘上开销最大各租户的时间序列变更churn是否异常可能引发性能劣化Per-Tenant Statistic 正是为回答这些问题而设计它在集群三个组件内部按租户维度维护计数器与仪表并以 Prometheus 格式暴露出来供任意抓取端采集。二、指标总览三个组件、七个核心指标按文档定义集群各组件暴露的按租户统计指标如下表组件指标名含义典型用途vminsertvm_tenant_inserted_rows_total已写入的总数据行数判断哪个租户对存储压力最大vmselectvm_tenant_select_requests_duration_ms_total查询延迟毫秒累计识别查询最重的租户vmselectvm_tenant_select_requests_total查询请求总数发现哪个租户查询量最大及其随时间的变化vmstoragevm_tenant_active_timeseries活跃时间序列数量与内存使用强相关可找出内存开销最大的租户vmstoragevm_tenant_used_tenant_bytes磁盘空间占用跟踪每个租户的磁盘用量vmstoragevm_tenant_timeseries_created_total新建时间序列总数跟踪每个租户的 churn rate识别低效使用模式指标的数据模型accountID / projectID 标签所有vm_tenant_*指标都会带上accountID与projectID两个标签从而能够按租户维度聚合。这一数据模型的底层实现在 lib/tenantmetrics/counter_map.goTenantID结构体由AccountID与ProjectID组成lib/tenantmetrics/counter_map.go#L13-L17CounterMap内部以sync.Map按TenantID维护一组metrics.Counter每个租户对应一个独立的计数器createMetricName在生成指标名时拼接标签%s{accountID%d,projectID%d}因此抓取到的每个指标天然带有租户标签lib/tenantmetrics/counter_map.go#L74-L84对于无法识别租户的多租户请求会回退到accountIDmultitenant,projectIDmultitenant的特殊标签lib/tenantmetrics/counter_map.go#L86-L96。值得注意的是vmagent也复用了同一套tenantmetrics.CounterMap机制按接入协议暴露vmagent_tenant_inserted_rows_total{type...}系列指标例如typeinflux、typedatadogv2、typeopentelemetry、typepromremotewrite等见 app/vmagent/influx/request_handler.go 与 app/vmagent/opentelemetry/request_handler.go。这说明按租户统计并非集群版专属的实现思路在单机版数据采集端同样适用。三、指标采集抓取配置这些指标与普通 Prometheus 指标一样通过/metrics端点暴露使用任意抓取端vmagent、单机版victoriametrics、Prometheus 等采集后写入时序数据库即可。文档给出了推荐的抓取配置scrape_configs: - job_name: cluster scrape_interval: 10s static_configs: - targets: [vmselect:8481,vmstorage:8482,vminsert:8480]三个目标端口分别对应集群组件的默认端口vminsert:8480—— 写入入口暴露vm_tenant_inserted_rows_totalvmselect:8481—— 查询入口暴露两个vm_tenant_select_*指标vmstorage:8482—— 存储节点暴露三个vm_tenant_*指标。存储建议与业务数据隔离文档明确建议把统计指标存入独立的时序数据库如单机版 VictoriaMetrics 或 Prometheus或至少使用与业务数据不同的租户存储以避免指标与业务时间序列发生冲突或相互干扰。两种方案任选其一复用现有集群但使用独立租户简单省事但需要保证统计租户与业务租户严格隔离运行独立的 TSDBVM single / Prometheus 等数据完全隔离推荐用于生产环境。四、可视化Grafana Dashboard 与本地 Dashboard 模板官方提供了用于可视化 Per-Tenant Statistics 的 Grafana Dashboard编号 16399包含Statistic与Billing两个核心区块Statistic 区展示各租户在写入、查询、磁盘、活跃序列等维度的分布与排行Billing 区面向计费场景按租户汇总用量数据便于换算费用。当前仓库自带与文档主题高度一致的 Dashboard 模板根目录 dashboards/clusterbytenant.json 及其副本 dashboards/vm/clusterbytenant.json。从该模板的 PromQL 表达式可以反推出官方 Dashboard 的典型查询写法例如写入速率排行sum(rate(vm_tenant_inserted_rows_total{accountID~$account, projectID~$project}[$__rate_interval])) by (accountID,projectID)活跃序列总量sum(vm_tenant_active_timeseries{accountID~$account,projectID~$project}) by(accountID,projectID)磁盘占用sum(vm_tenant_used_tenant_bytes{accountID~$account,projectID~$project}) by(accountID, projectID)24 小时新建序列sum(increase(vm_tenant_timeseries_created_total{accountID~$account, projectID~$project}[24h])) by(accountID,projectID)Top 5 异常租户topk_last(5, sum(rate(vm_tenant_inserted_rows_total{accountID~$account}[$__range])) by (accountID), accountIDother)这些表达式同时验证了文档中“所有指标均带accountID/projectID标签可by (accountID,projectID)聚合”的表述可直接参考模板按需裁剪。五、典型使用场景5.1 数据分布与异常定位通过可视化各租户当前的数据分布可以快速找出用量异常的“离群租户”outliers在集群发生故障时精确定位是哪个租户在特定时间点对数据库造成了损害理解每个租户对 VictoriaMetrics 整体负载的真实影响为容量规划提供依据。5.2 内部计费Internal Billing当把 VictoriaMetrics 作为平台提供给不同组织、团队或客户时可以基于这些租户指标构建计费体系。文档指出计费数据覆盖四个维度计费维度使用的指标写入流量vm_tenant_inserted_rows_total读取请求vm_tenant_select_requests_duration_ms_total、vm_tenant_select_requests_total磁盘占用vm_tenant_used_tenant_bytes数据分布vm_tenant_timeseries_created_total、vm_tenant_active_timeseries这四个维度组合起来即可完整估算每个租户的运行成本。应用侧可通过vmselect的/api/v1/query接口定时拉取这些指标构建独立的计费服务。文档给出了两种典型计费逻辑成本分摊法适合内部使用先核算 VictoriaMetrics 的整体运行成本再计算每个租户用量的占比按比例把总成本分摊到各组织/团队单位定价法适合对外服务定义“单位”及其单价例如 1 个单位 1k 活跃时间序列、24h 内 1k 新建序列、1GB 磁盘空间、每秒 1k 数据点等。通过/api/v1/query拉取现有用量计算每个租户消耗的单位数从而对客户计费同时也可在组织内部使用。Grafana Dashboard 的Billing区块正是为这种模式设计的可直接在其基础上查看各租户的用量账单。六、与 vmgateway 集成按租户限流vmgateway支持基于 Per-Tenant Statistics 数据实现按租户的速率限制rate limiting当某个租户的实际用量如写入行数、活跃序列数、磁盘占用等超过为其配置的限额时vmgateway可以拒绝或限制该租户的后续请求从而在网关层为多租户场景提供成本与资源的硬约束。详细的配置方式见仓库文档 docs/victoriametrics/vmgateway.md。配合本篇文章的指标体系可以形成“用量统计感知→ 网关限流控制→ 告警通知”的完整闭环。七、与 vmalert 集成按租户告警vmalert可以根据每个租户的资源用量生成告警并在限额耗尽前通知运维人员。仓库文档 docs/victoriametrics/vmalert.md 提供了完整配置说明。文档给出一个针对“高 Churn Rate 租户”的告警规则示例- alert: TooHighChurnRate expr: | ( sum(rate(vm_tenant_timeseries_created_total[5m])) by(accountID,projectID) / sum(rate(vm_tenant_inserted_rows_total[5m])) by(accountID,projectID) ) 0.1 for: 15m labels: severity: warning annotations: summary: Churn rate is more than 10% for the last 15m description: VM constantly creates new time series in the tenant: {{ $labels.accountID }}:{{ $labels.projectID }}.\n This effect is known as Churn Rate.\n High Churn Rate is tightly connected with database performance and may result in unexpected OOMs or slow queries.告警逻辑解读分子rate(vm_tenant_timeseries_created_total[5m])表示最近 5 分钟内每秒新建的时间序列数分母rate(vm_tenant_inserted_rows_total[5m])表示最近 5 分钟内每秒写入的数据行数比值超过0.1即 10%并持续 15 分钟即触发warning告警告警按accountID,projectID分组描述中动态引用{{ $labels.accountID }}:{{ $labels.projectID }}精确定位问题租户。之所以监控 churn rate 很重要是因为高 Churn Rate 与数据库性能密切相关持续新建时间序列会带来大量索引与元数据开销可能导致查询变慢甚至出现意外的 OOM。上述示例同样适用于其他资源维度——只需替换指标即可扩展出“磁盘增长过快”“活跃序列超限”等告警。八、总结与最佳实践Per-Tenant Statistic 为 VictoriaMetrics 集群的多租户运营提供了完整的数据支撑。综合文档与仓库实现落地时可遵循以下最佳实践抓取端配置按文档给出的scrape_configs抓取vminsert、vmselect、vmstorage三个组件的/metrics建议抓取间隔 10s 左右存储隔离统计指标存入独立 TSDB 或独立租户避免与业务数据混用可视化使用官方 Grafana Dashboard编号 16399或直接导入仓库自带模板 dashboards/clusterbytenant.json 快速搭建 Statistic 与 Billing 视图计费按“成本分摊”或“单位定价”两种模式设计用/api/v1/query定时采集四个计费维度指标控制与告警结合vmgateway做按租户限流结合vmalert做按租户告警形成“感知—控制—通知”闭环原理理解所有指标的租户标签由 lib/tenantmetrics/counter_map.go 中的CounterMap按accountID/projectID维度生成多租户请求会落入multitenant标签理解这一点有助于正确解读聚合结果。通过以上步骤你可以在多租户集群中精确回答“谁在用、用了多少、花销多大、是否异常”把 VictoriaMetrics 从单纯的时序数据库升级为可计量、可治理的多租户服务平台。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
VictoriaMetrics 集群多租户用量统计（Per-Tenant Statistic）实战指南
VictoriaMetrics 集群多租户用量统计Per-Tenant Statistic实战指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics导读VictoriaMetrics 集群版Cluster在企业版中提供了按租户Tenant由accountID与projectID唯一标识拆分的资源用量与统计能力通过vminsert、vmselect、vmstorage三个组件暴露一组vm_tenant_*系列指标覆盖数据写入、查询延迟、活跃时间序列、磁盘占用与序列变更率Churn Rate等维度。本文以仓库文档 docs/victoriametrics/PerTenantStatistic.md 为主体结合源码与本地 Dashboard 配置完整讲解这些指标的语义、抓取配置、可视化、内部计费模型以及与vmgateway限流和vmalert告警的联动方案。读完本文你将能够为每个租户建立可观测、可计费、可告警的完整用量跟踪体系。说明Per-Tenant Statistic 属于 VictoriaMetrics 企业版能力。该能力可从官方 Releases 页面下载评估版获取 License Key 后可申请免费试用 License。一、为什么需要按租户统计VictoriaMetrics 集群天然支持多租户vminsert通过请求头如AccountID/ProjectID把数据路由到对应租户的vmstorage分片vmselect再按租户维度查询。在多组织、多团队、多客户共用一个集群的场景下运维者迫切需要回答以下问题哪个租户给存储层带来了最大的写入压力哪个租户发起了最重的查询哪个租户在内存和磁盘上开销最大各租户的时间序列变更churn是否异常可能引发性能劣化Per-Tenant Statistic 正是为回答这些问题而设计它在集群三个组件内部按租户维度维护计数器与仪表并以 Prometheus 格式暴露出来供任意抓取端采集。二、指标总览三个组件、七个核心指标按文档定义集群各组件暴露的按租户统计指标如下表组件指标名含义典型用途vminsertvm_tenant_inserted_rows_total已写入的总数据行数判断哪个租户对存储压力最大vmselectvm_tenant_select_requests_duration_ms_total查询延迟毫秒累计识别查询最重的租户vmselectvm_tenant_select_requests_total查询请求总数发现哪个租户查询量最大及其随时间的变化vmstoragevm_tenant_active_timeseries活跃时间序列数量与内存使用强相关可找出内存开销最大的租户vmstoragevm_tenant_used_tenant_bytes磁盘空间占用跟踪每个租户的磁盘用量vmstoragevm_tenant_timeseries_created_total新建时间序列总数跟踪每个租户的 churn rate识别低效使用模式指标的数据模型accountID / projectID 标签所有vm_tenant_*指标都会带上accountID与projectID两个标签从而能够按租户维度聚合。这一数据模型的底层实现在 lib/tenantmetrics/counter_map.goTenantID结构体由AccountID与ProjectID组成lib/tenantmetrics/counter_map.go#L13-L17CounterMap内部以sync.Map按TenantID维护一组metrics.Counter每个租户对应一个独立的计数器createMetricName在生成指标名时拼接标签%s{accountID%d,projectID%d}因此抓取到的每个指标天然带有租户标签lib/tenantmetrics/counter_map.go#L74-L84对于无法识别租户的多租户请求会回退到accountIDmultitenant,projectIDmultitenant的特殊标签lib/tenantmetrics/counter_map.go#L86-L96。值得注意的是vmagent也复用了同一套tenantmetrics.CounterMap机制按接入协议暴露vmagent_tenant_inserted_rows_total{type...}系列指标例如typeinflux、typedatadogv2、typeopentelemetry、typepromremotewrite等见 app/vmagent/influx/request_handler.go 与 app/vmagent/opentelemetry/request_handler.go。这说明按租户统计并非集群版专属的实现思路在单机版数据采集端同样适用。三、指标采集抓取配置这些指标与普通 Prometheus 指标一样通过/metrics端点暴露使用任意抓取端vmagent、单机版victoriametrics、Prometheus 等采集后写入时序数据库即可。文档给出了推荐的抓取配置scrape_configs: - job_name: cluster scrape_interval: 10s static_configs: - targets: [vmselect:8481,vmstorage:8482,vminsert:8480]三个目标端口分别对应集群组件的默认端口vminsert:8480—— 写入入口暴露vm_tenant_inserted_rows_totalvmselect:8481—— 查询入口暴露两个vm_tenant_select_*指标vmstorage:8482—— 存储节点暴露三个vm_tenant_*指标。存储建议与业务数据隔离文档明确建议把统计指标存入独立的时序数据库如单机版 VictoriaMetrics 或 Prometheus或至少使用与业务数据不同的租户存储以避免指标与业务时间序列发生冲突或相互干扰。两种方案任选其一复用现有集群但使用独立租户简单省事但需要保证统计租户与业务租户严格隔离运行独立的 TSDBVM single / Prometheus 等数据完全隔离推荐用于生产环境。四、可视化Grafana Dashboard 与本地 Dashboard 模板官方提供了用于可视化 Per-Tenant Statistics 的 Grafana Dashboard编号 16399包含Statistic与Billing两个核心区块Statistic 区展示各租户在写入、查询、磁盘、活跃序列等维度的分布与排行Billing 区面向计费场景按租户汇总用量数据便于换算费用。当前仓库自带与文档主题高度一致的 Dashboard 模板根目录 dashboards/clusterbytenant.json 及其副本 dashboards/vm/clusterbytenant.json。从该模板的 PromQL 表达式可以反推出官方 Dashboard 的典型查询写法例如写入速率排行sum(rate(vm_tenant_inserted_rows_total{accountID~$account, projectID~$project}[$__rate_interval])) by (accountID,projectID)活跃序列总量sum(vm_tenant_active_timeseries{accountID~$account,projectID~$project}) by(accountID,projectID)磁盘占用sum(vm_tenant_used_tenant_bytes{accountID~$account,projectID~$project}) by(accountID, projectID)24 小时新建序列sum(increase(vm_tenant_timeseries_created_total{accountID~$account, projectID~$project}[24h])) by(accountID,projectID)Top 5 异常租户topk_last(5, sum(rate(vm_tenant_inserted_rows_total{accountID~$account}[$__range])) by (accountID), accountIDother)这些表达式同时验证了文档中“所有指标均带accountID/projectID标签可by (accountID,projectID)聚合”的表述可直接参考模板按需裁剪。五、典型使用场景5.1 数据分布与异常定位通过可视化各租户当前的数据分布可以快速找出用量异常的“离群租户”outliers在集群发生故障时精确定位是哪个租户在特定时间点对数据库造成了损害理解每个租户对 VictoriaMetrics 整体负载的真实影响为容量规划提供依据。5.2 内部计费Internal Billing当把 VictoriaMetrics 作为平台提供给不同组织、团队或客户时可以基于这些租户指标构建计费体系。文档指出计费数据覆盖四个维度计费维度使用的指标写入流量vm_tenant_inserted_rows_total读取请求vm_tenant_select_requests_duration_ms_total、vm_tenant_select_requests_total磁盘占用vm_tenant_used_tenant_bytes数据分布vm_tenant_timeseries_created_total、vm_tenant_active_timeseries这四个维度组合起来即可完整估算每个租户的运行成本。应用侧可通过vmselect的/api/v1/query接口定时拉取这些指标构建独立的计费服务。文档给出了两种典型计费逻辑成本分摊法适合内部使用先核算 VictoriaMetrics 的整体运行成本再计算每个租户用量的占比按比例把总成本分摊到各组织/团队单位定价法适合对外服务定义“单位”及其单价例如 1 个单位 1k 活跃时间序列、24h 内 1k 新建序列、1GB 磁盘空间、每秒 1k 数据点等。通过/api/v1/query拉取现有用量计算每个租户消耗的单位数从而对客户计费同时也可在组织内部使用。Grafana Dashboard 的Billing区块正是为这种模式设计的可直接在其基础上查看各租户的用量账单。六、与 vmgateway 集成按租户限流vmgateway支持基于 Per-Tenant Statistics 数据实现按租户的速率限制rate limiting当某个租户的实际用量如写入行数、活跃序列数、磁盘占用等超过为其配置的限额时vmgateway可以拒绝或限制该租户的后续请求从而在网关层为多租户场景提供成本与资源的硬约束。详细的配置方式见仓库文档 docs/victoriametrics/vmgateway.md。配合本篇文章的指标体系可以形成“用量统计感知→ 网关限流控制→ 告警通知”的完整闭环。七、与 vmalert 集成按租户告警vmalert可以根据每个租户的资源用量生成告警并在限额耗尽前通知运维人员。仓库文档 docs/victoriametrics/vmalert.md 提供了完整配置说明。文档给出一个针对“高 Churn Rate 租户”的告警规则示例- alert: TooHighChurnRate expr: | ( sum(rate(vm_tenant_timeseries_created_total[5m])) by(accountID,projectID) / sum(rate(vm_tenant_inserted_rows_total[5m])) by(accountID,projectID) ) 0.1 for: 15m labels: severity: warning annotations: summary: Churn rate is more than 10% for the last 15m description: VM constantly creates new time series in the tenant: {{ $labels.accountID }}:{{ $labels.projectID }}.\n This effect is known as Churn Rate.\n High Churn Rate is tightly connected with database performance and may result in unexpected OOMs or slow queries.告警逻辑解读分子rate(vm_tenant_timeseries_created_total[5m])表示最近 5 分钟内每秒新建的时间序列数分母rate(vm_tenant_inserted_rows_total[5m])表示最近 5 分钟内每秒写入的数据行数比值超过0.1即 10%并持续 15 分钟即触发warning告警告警按accountID,projectID分组描述中动态引用{{ $labels.accountID }}:{{ $labels.projectID }}精确定位问题租户。之所以监控 churn rate 很重要是因为高 Churn Rate 与数据库性能密切相关持续新建时间序列会带来大量索引与元数据开销可能导致查询变慢甚至出现意外的 OOM。上述示例同样适用于其他资源维度——只需替换指标即可扩展出“磁盘增长过快”“活跃序列超限”等告警。八、总结与最佳实践Per-Tenant Statistic 为 VictoriaMetrics 集群的多租户运营提供了完整的数据支撑。综合文档与仓库实现落地时可遵循以下最佳实践抓取端配置按文档给出的scrape_configs抓取vminsert、vmselect、vmstorage三个组件的/metrics建议抓取间隔 10s 左右存储隔离统计指标存入独立 TSDB 或独立租户避免与业务数据混用可视化使用官方 Grafana Dashboard编号 16399或直接导入仓库自带模板 dashboards/clusterbytenant.json 快速搭建 Statistic 与 Billing 视图计费按“成本分摊”或“单位定价”两种模式设计用/api/v1/query定时采集四个计费维度指标控制与告警结合vmgateway做按租户限流结合vmalert做按租户告警形成“感知—控制—通知”闭环原理理解所有指标的租户标签由 lib/tenantmetrics/counter_map.go 中的CounterMap按accountID/projectID维度生成多租户请求会落入multitenant标签理解这一点有助于正确解读聚合结果。通过以上步骤你可以在多租户集群中精确回答“谁在用、用了多少、花销多大、是否异常”把 VictoriaMetrics 从单纯的时序数据库升级为可计量、可治理的多租户服务平台。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
