You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a larger system, maintaining consistent tenant identifiers across all metrics isn't always practical. For example, some metrics might use tenant_id while others rely on page_id, depending on the reporting service. Therefore, the proxy needs to decide which label to enforce for each metric.
We currently have a working prototype that modifies vendor files. Instead of using the label parameter in the NewRoutes function, we inject the label name in the same way as the label values. As a result, the ExtractLabeler handles determining which label name to enforce.
Since we don't require the full functionality of the proxy, such as rules, silences, and alerts, which might be challenging to support, I wanted to see if you're interested in and supportive of this idea. If so, we're open to investing more effort in refining it for a potential upstream pull request for a possible direction. Anyways, we can provide a fork once it's ready.
The text was updated successfully, but these errors were encountered:
In a larger system, maintaining consistent tenant identifiers across all metrics isn't always practical. For example, some metrics might use
tenant_id
while others rely onpage_id
, depending on the reporting service. Therefore, the proxy needs to decide which label to enforce for each metric.We currently have a working prototype that modifies vendor files. Instead of using the label parameter in the
NewRoutes
function, we inject the label name in the same way as the label values. As a result, theExtractLabeler
handles determining which label name to enforce.Since we don't require the full functionality of the proxy, such as rules, silences, and alerts, which might be challenging to support, I wanted to see if you're interested in and supportive of this idea. If so, we're open to investing more effort in refining it for a potential upstream pull request for a possible direction. Anyways, we can provide a fork once it's ready.
The text was updated successfully, but these errors were encountered: