Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,10 @@ public static bool TryGetCounterPayload(this TraceEvent traceEvent, CounterFilte
{
HandleCounterRate(traceEvent, filter, sessionId, out payload);
}
else if (traceEvent.EventName == "UpDownCounterRateValuePublished")
{
HandleCounterRate(traceEvent, filter, sessionId, out payload);
}
else if (traceEvent.EventName == "TimeSeriesLimitReached")
{
HandleTimeSeriesLimitReached(traceEvent, sessionId, out payload);
Expand Down
4 changes: 4 additions & 0 deletions src/Tools/dotnet-counters/CounterMonitor.cs
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,10 @@ private void DynamicAllMonitor(TraceEvent obj)
{
HandleCounterRate(obj);
}
else if (obj.EventName == "UpDownCounterRateValuePublished")
{
HandleCounterRate(obj);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HandleCounterRate

do we expect this will work fine with updowncounter? I mean with values that increase and decrease?

@noahfalk

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I expect functionally it will work, however thinking about it and talking it over with James Newton-King recently I'm not so sure it is the behavior users are going to want. I feel bad because I reviewed the earlier change to MetricsEventSource and ideally I would have spotted it at that earlier point rather than now. Definitely my bad :(

Although Counter and UpDownCounter officially only differ in whether they promise monotonicity, in practice I think the reason most people care is because Counter tends to keep going up and the rate of change is very relevant whereas UpDownCounter tends to stay in a fixed range and the absolute value is more important. For example a common use of UpDownCounter would be measuring the size of a cache or a queue. Users probably care much more that their queue has 1200 items in it rather than that it has 14 items less than it did 10 seconds ago.

So ideally my current goal would be to do:

  1. Report the absolute value in addition to the rate of change in MetricsEventSource for Counters, ObservableCounter, UpDownCounter, and ObservableUpDownCounter
  2. Make UpDownCounters + ObservableUpDownCounter report absolute value rather than rate-of-change in the tools

@kkeirstead - I know this is probably coming as a bit of a surprise, very sorry about that! If you felt you had the time to tackle those changes that would be awesome but if not we can chat and figure out another plan.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, no problem - I can look into doing that. In the meantime I'll close this PR so it's not sitting here stale, and I'll open an updated one after making the other changes in MetricsEventSource

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! 👍

}
else if (obj.EventName == "TimeSeriesLimitReached")
{
HandleTimeSeriesLimitReached(obj);
Expand Down