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
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.
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
The text was updated successfully, but these errors were encountered: