VictoriaMetrics / VictoriaMetrics

VictoriaMetrics: fast, cost-effective monitoring solution and time series database
https://victoriametrics.com/
Apache License 2.0
12.12k stars 1.2k forks source link

vminsert: multitenant url should have option to retain tenant labels #5647

Open hagen1778 opened 8 months ago

hagen1778 commented 8 months ago

Is your feature request related to a problem? Please describe

A clustered version of VictoriaMetrics supports multitenancy via labels. It expects that user will send a payload of the following form:

http_requests_total{path="/foo",vm_account_id="42"} 12
http_requests_total{path="/bar",vm_account_id="7",vm_project_id="9"} 34

Then the http_requests_total{path="/foo"} 12 would be stored in the tenant accountID=42, projectID=0, while the http_requests_total{path="/bar"} 34 would be stored in the tenant accountID=7, projectID=9.

However, removing vm_account_id/vm_project_id may not suite all cases. For example, if user would like to get global view across all tenants via promxy or other proxy it would be convenient to retain mentioned labels, so responses from multiple tenants were distinguishable. See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1434#issuecomment-1895321710

Retaining tenant labels would also simplify multitenancy in vmalert.

Describe the solution you'd like

It would be nice to make insert/multitenant API to accept optional GET param keep_tenant_labels=<bool>. When set to true, this param will instruct vminsert to retain vm_account_id/vm_project_id on ingestion.

hagen1778 commented 8 months ago

cc @zekker6

zekker6 commented 6 months ago

@hagen1778 It seems to me like a better approach would be to add an optional GET param to vmselect instead. This param would enforce adding tenant labels to the series. This way it won't be required to store tenant info twice(both as prefix and in labels), but this will increase load on vmselect as it will be required to append artificial labels. Wdyt?