dotnet-monitor
dotnet-monitor copied to clipboard
dotnet
The ability to specify different `EventCounterIntervalSec` values on a per provider basis
Background and Motivation
Currently you are required to use the same EventCounterIntervalSec global and on each of the providers.
Proposed Feature
It'd be nice to be able to specify different EventCounterIntervalSec values for the providers. I might have a provider that I don't care to track as closely as another, but still want to receive counter information. This could help reduce the amount of data being collected and potentially reduce the number of dropped events, etc.
This is a very reasonable feature, but we have to make sure we don't regress https://github.com/dotnet/dotnet-monitor/issues/923. I.e. once an interval for a provider is established in one scenario such as Prometheus, it must be the same for all other scenarios such as live metrics, triggers, and actions.
@wiktork So, there'd be no way to split this and have different intervals for different streams? ie, one interval for the trace call and another for the live metrics?
@wiktork So, there'd be no way to split this and have different intervals for different streams? ie, one interval for the trace call and another for the live metrics?
This is controlled at the runtime level. Having multiple overlapping sessions causes the runtime to use the lowest specified interval. For traces, this will work fine (although may produce confusing results). For prometheus/live metrics we discard any metrics that do not use the originally specified interval.
Allowing users to specify different intervals for each scenario but then ignoring them anyway when sessions overlap is likely to cause a lot of confusion. It still makes sense to specify them on a per provider basis though.
@wiktork So, there'd be no way to split this and have different intervals for different streams? ie, one interval for the trace call and another for the live metrics?
This is controlled at the runtime level. Having multiple overlapping sessions causes the runtime to use the lowest specified interval. For traces, this will work fine (although may produce confusing results). For prometheus/live metrics we discard any metrics that do not use the originally specified interval.
Allowing users to specify different intervals for each scenario but then ignoring them anyway when sessions overlap is likely to cause a lot of confusion. It still makes sense to specify them on a per provider basis though.
I think the ask here is to allow specifying these per provider so that all collection mechanism are not artificially locked into the same interval. For example, if the user turns off default metrics (e.g. --metrics false), then it's conceivable to allow different intervals for each provider so long as they are not actively used in any trace (or it needs to specify the same exact interval). I don't think tracking the interval per provider would be much effort: entry for each provider with the interval value (and maybe the active session count if we want to allow changing the interval if it's not in use).
I think the ask here is to allow specifying these per provider so that all collection mechanism are not artificially locked into the same interval. For example, if the user turns off default metrics (e.g.
--metrics false), then it's conceivable to allow different intervals for each provider so long as they are not actively used in any trace (or it needs to specify the same exact interval). I don't think tracking the interval per provider would be much effort: entry for each provider with the interval value (and maybe the active session count if we want to allow changing the interval if it's not in use).
Agreed. I just want to make sure that the limitations of this configuration are well understood. For example, collecting prom metrics on a particular provider at a lower interval also implies that traces, triggers, and live metrics will collect that provider at a lower interval.
It might be nice to create some documentation around this and the limitations. After talking to @jander-msft previous this was my understanding as well. It was more of a hope that that wasn't the case :)
Being able to specify it at the event provider level would be very helpful.