14 Feb 2024 10:19 PM - last edited on 15 Feb 2024 08:59 AM by MaciejNeumann
I have a situation where I am trying to understand why one particular metric has so many dimensions in the "Alert preview" in Metric Events, when used with the rollup() transformation:
But starting with the beginning, the metric in question, with the specific filter used in the metric expression, has only 81 entries/combinations in the last 24 hours, when displayed in Data Explorer, in Table mode.
If I start with no rollup, I get the following in "Alert preview" in Metric Events:
Now, the first calculation that doesn't make sense to me is that 81 x 614 = 49734. So I have only 81 entries, why is this multiplied by the 614 value?
I had to try to figure out where the 614 was coming from. 614 / 81 doesn't give an integer value.
So, I started out with several metric expressions. For each the corresponding number of "metric dimension values" in Metric Events:
Now, if I do a count of how many datapoints there are in the last 24 hours, in Data Explorer, I have 78686 (BTW, last 24 hours are evolving as I write this post). The data series is sparse, with values every 5 minutes, and only when the metric has values. And yes, this metric has 38 dimensions...
Now, back to 614. While writing this, it changed to 613. 613 is prime, so it's not related to any multiplication, so now I'm not sure where it comes from.
So, I restarted calculations with only the metric, with the value above, 27269. And I found out several values, with the following factors:
So, with no common factors, these values seem to be related to the amount of datapoints that are being recorded, but once again they do not seem to have a relation.
I also tried to use limit(), but it only got more confusing to me...
So, is there any info out there on how this calculation is made, so we can setup Metric events that make sense, and that are eventually not throttled?
27 May 2024 11:24 AM
I was struggling with a bit similar issue. My selector produced 59 unique dimensions when counting them in table view. Below is the selector, it shows OS service availability in percentage format:
(builtin:osservice.availability:splitBy("dt.entity.os:service","dt.entity.host"):sort(value(auto,descending)):limit(100)/6)*100
...But the metric event definition said there are 3481 dimensions, i.e. too many. That number is 59 times 59 actually.
Then I removed the "limit(100)" definition:
(builtin:osservice.availability:splitBy("dt.entity.os:service","dt.entity.host"):sort(value(auto,descending))/6)*100
And now it works! It says 59 dimensions are there. I don't really understand how it makes sense, but removing the limit fixed it in my case. These are mysterious things sometimes...
27 May 2024 04:03 PM
In your case, removing the limit will make it the default, of 20 entries.
Not sure if limit is used in metric event, but in Data explorer, that's how it works.
27 May 2024 05:18 PM
Great point! But I believe in metric events it doesn't default to 20, or the expressions that I mentioned above would also not have issues...