Open SpamapS opened 1 month ago
Hey @SpamapS, we can't use "count" for GC.count
because count would sum the number of times GC.count
was reported, instead of only recording the latest value.
From our metrics docs: https://docs.datadoghq.com/metrics/types/?tab=count#metric-types
Suppose you are submitting a COUNT metric, notifications.sent, from a single host running the Datadog Agent. This host emits the following values in a flush time interval: [1,1,1,2,2,2,3,3].
The Agent adds all of the values received in one time interval. Then, it submits the total number, in this case 15, as the COUNT metric’s value.
Because GC.count
will report the total number of GC cycles, we want it to be reported as a gauge.
Now, regarding the graph jumps you are seeing, these are likely caused by multiple Ruby processes with the same service name. The Runtime Metrics aggregate on a service level, no per individual process, thus causing such metrics to report inconsistent values. We are actively working on a solution as we speak.
Current behaviour
All GC.stats are reported as gauges
Expected behaviour Counters produce graphs like this:
This isn't terribly useful as a gauge, and should be reported as a count.
This is a bit tricky as some of the other stats are _count but do represent gauges.
Steps to reproduce
Just enable ruby runtime metrics and graph
runtime.ruby.gc.gc_count
orruntime.ruby.gc.major_gc_count
Environment
1.23.3
Datadog.configure ...
):3.1.5
Linux (various) & MacOS