Confused about :sum behavior on gauge metric (memory_working_set) at 1-day resolution

[Aboud1]

Hi Dynatrace Community 👋,

I'm trying to understand how the :sum aggregation works with the gauge metric builtin:kubernetes.workload.memory_working_set when using 1-day resolution in Data Explorer.

Here’s what I observed:

• For most of the day, the memory usage (working set) was steady around 92 GiB.

• At the beginning of the day, there was a spike over 210 GiB.

• I used :sum aggregation on the metric.

• Still, the final daily value shown is only ~99.6 GiB, which doesn’t make sense to me if this is a sum of all buckets during the day.

• Dynatrace used this metric query (by default - in the data explorer view):

  builtin:kubernetes.workload.memory_working_set:splitBy("dt.entity.cloud_application_namespace"😞sum

Example screenshot (attached):

You can clearly see that the values stayed stable around 90 for several hours.

---

My question:

If the metric is gauge-based, and I apply :sum at 1-day resolution, shouldn't I expect a higher number — i.e., the sum of all 5-min snapshots across 24 hours?

Or is :sum on a gauge metric just showing the last bucket value?

Appreciate any clarification 🙏

Thanks

[Aboud1 · Accepted solution]

We have the answer from internal support team 🙂

🔹 The Issue:
I was using :sum on the metric builtin:kubernetes.workload.memory_working_set (it's the default metric used by dynatrace ) expecting it to sum all values over the day. But the result (e.g., 92 GiB) seemed too low, especially when there were higher values (like 210 GiB) earlier in the day.

---

🔹 What’s Actually Happening:

1. If the metric does not support :sum aggregation natively, Dynatrace falls back to the default aggregation, which is usually :avg.

2. Then, if you're using :splitBy(...), it sums up the average values, not the original raw data.

3. So, the final number you see is not the true sum of all 5-minute snapshots — it's sum of the averages per split.

4. To get the true total usage, you need to:

   • Set your resolution to 5 minutes

   • Append :fold(sum) to the query

   Example:

   builtin:kubernetes.workload.memory_working_set:filter(...):splitBy(...):fold(sum)

---

🔹 Key Takeaway:

• The :sum aggregation at 1-day resolution can be misleading if the metric doesn't support it directly.

• If there was a spike earlier in the day (e.g., memory usage was 210 GiB and dropped to 90 GiB later), you won't notice it from the 1-day aggregated view.

• For more accurate insights, it's better to use 5-minute resolution and analyze usage over time — hour by hour.