Currently statsd puts a suffix for every aggregated timer metric to indicate the aggregation type of it, for example: .P99, .Median, etc. For the metric id in m3 format, the indexer would parse the suffix and add a timerType tag in the metadata for the metric so the metric could be looked up by querying specific timerType.
In m3aggregator, we are doing the same thing for timer aggregations, but since we support custom aggregation functions for counters and gauges now, so we need a way to differentiate the aggregation type for each id, we are following these rules:
- For the default aggregation type (Sum for Counter, Last for Gauge) we are not adding the suffix to keep the id the same with the existing ones so that all the existing user queries can continue to work.
- For other aggregation types applied on Counter and Gauge, since these aggregations were not done in the old statsd aggregation tier, so we will be creating new ids for them, using the same way that statsd did for timers, by adding a suffix(.sum, .count, .stdev, etc) in the end of the id. Then the indexer will also parse the suffix and add aggregationType tag accordingly.
This is the way we do it for now, but an alternative solution is to not add the aggregation type to the suffix of m3 format metrics and instead adding it as a tag in the id. That way we can get rid of the suffix for all the metrics in m3 format.
e.g:
instead of: m3+users-online+service:test-service,type:gauge.upper
we can do: m3+users-online+aggregationType:upper,service:test-service,type:gauge
This change could be done in the new agg tier or be done in indexers/ingesters. But since this would require changing the existing timer ids in m3 format, it will make query shadow compare harder. We will revisit this issue in a later time.
Currently statsd puts a suffix for every aggregated timer metric to indicate the aggregation type of it, for example: .P99, .Median, etc. For the metric id in m3 format, the indexer would parse the suffix and add a timerType tag in the metadata for the metric so the metric could be looked up by querying specific timerType.
In m3aggregator, we are doing the same thing for timer aggregations, but since we support custom aggregation functions for counters and gauges now, so we need a way to differentiate the aggregation type for each id, we are following these rules:
This is the way we do it for now, but an alternative solution is to not add the aggregation type to the suffix of m3 format metrics and instead adding it as a tag in the id. That way we can get rid of the suffix for all the metrics in m3 format.
e.g:
instead of: m3+users-online+service:test-service,type:gauge.upper
we can do: m3+users-online+aggregationType:upper,service:test-service,type:gauge
This change could be done in the new agg tier or be done in indexers/ingesters. But since this would require changing the existing timer ids in m3 format, it will make query shadow compare harder. We will revisit this issue in a later time.