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
Prometheus's data model is kind of interesting. I'm not sure if tags are completely necessary.
Their definition of a "time series" is (emphasis mine):
streams of timestamped values belonging to the same metric and the same set of labeled dimensions
I wasn't sure if the "same set of labeled dimensions" meant that streams with the same set of label dimensions but different label values would map to the same time series.
More from that page...
Changing any label value, including adding or removing a label, will create a new time series.
...and...
Given a metric name and a set of labels, time series are frequently identified using this notation:
<metric name>{<label name>=<label value>, ...}
In that case, something like api_http_requests_total{method="POST", handler="/messages"} is a separate series from api_http_requests_total{method="GET", handler="/messages"}. This won't require any significant storage system format changes, because we can integrate tags right into the metric name.
The only change that's required is to make the metadata region at the end more compact, because lots of tags means lots of individual metrics, which take up RAM. We could just keep the main metric name in memory and look up tags later.
The text was updated successfully, but these errors were encountered:
Prometheus's data model is kind of interesting. I'm not sure if tags are completely necessary.
Their definition of a "time series" is (emphasis mine):
I wasn't sure if the "same set of labeled dimensions" meant that streams with the same set of label dimensions but different label values would map to the same time series.
More from that page...
...and...
In that case, something like
api_http_requests_total{method="POST", handler="/messages"}
is a separate series fromapi_http_requests_total{method="GET", handler="/messages"}
. This won't require any significant storage system format changes, because we can integrate tags right into the metric name.The only change that's required is to make the metadata region at the end more compact, because lots of tags means lots of individual metrics, which take up RAM. We could just keep the main metric name in memory and look up tags later.
The text was updated successfully, but these errors were encountered: