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
When agent stat data is serialized to be persisted in hbase, the agent startTimestamp is ignored.
For snapshot data that do not require any previous state (such as heap usage, cpu usage, etc), this is fine.
However, if data requires some previous value to make sense of itself , the agent startTimestamp can be useful in giving more context.
For example, full garbage collection (GC) count and time are collected as ever-increasing values since the jvm startup time. To calculate how many GCs have occurred, and how long those GCs took in a particular time interval, we must compare them with values from the previous time interval. Add sampling into the mix and the situation becomes worse.
Let's take a look at the following example,
When the sampling interval is 5 seconds (no sampling), the graph would show 2 GC counts at 10:10. This is correct if the JVM was restarted at 10:10, but if it was a packet loss, it would have been incorrect.
When the sampling interval is 10 seconds, the graph would show nothing as both the GC count at 10:00, and the GC count at 10:10 are 2 when in fact, the graph should have shown 2 GC counts at 10:10.
Adding agent startTimestamp when calculating these values would allow for a more accurate presentation of data.
(This change will only take effect for stat data stored in AgentStatV2)
The text was updated successfully, but these errors were encountered:
Description
When agent stat data is serialized to be persisted in hbase, the agent startTimestamp is ignored.
For snapshot data that do not require any previous state (such as heap usage, cpu usage, etc), this is fine.
However, if data requires some previous value to make sense of itself , the agent startTimestamp can be useful in giving more context.
For example, full garbage collection (GC) count and time are collected as ever-increasing values since the jvm startup time. To calculate how many GCs have occurred, and how long those GCs took in a particular time interval, we must compare them with values from the previous time interval. Add sampling into the mix and the situation becomes worse.
Let's take a look at the following example,
When the sampling interval is 5 seconds (no sampling), the graph would show 2 GC counts at 10:10. This is correct if the JVM was restarted at 10:10, but if it was a packet loss, it would have been incorrect.
When the sampling interval is 10 seconds, the graph would show nothing as both the GC count at 10:00, and the GC count at 10:10 are 2 when in fact, the graph should have shown 2 GC counts at 10:10.
Adding agent startTimestamp when calculating these values would allow for a more accurate presentation of data.
(This change will only take effect for stat data stored in
AgentStatV2
)The text was updated successfully, but these errors were encountered: