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
Enable the config item for a counter that has no associated instances ("RDMA Activity", for example) on the server. the same applies to others.
Expected behavior:
Telegraf collects data from the many other counters that are valid, and do return data.
Actual behavior:
Telegraf logs an error similar to:
"E! [telegraf] Error running agent: error while getting value for counter \RDMA Activity(*)\RDMA Completion Queue Errors: No data to return."
and returns no other data.
Additional info:
Telegraf 1.8 does not behave like this - it sends for other counters.
As new to the windows agent, wanted to verify that this is a bug, and not expected (i.e. is the windows agent by design, supposed to return nothing as soon as a single input object has no data - guessing not).
The reason that we need this "fix" is because in large environments, it is a nightmare trying to change the local config on each server whenever there are no instances active (of any particular perf counter) goes away - for example, when admins are doing maintenance / playing with new features etc, they still want to be getting data from other counters.
The error is being returned from here (within the Gather func in win_perf_counters.go), two different places depending upon whether wildcardexpansion used or not:
if !isKnownCounterDataError(err) {
return fmt.Errorf("error while getting value for counter %s: %v", metric.counterPath, err)
}
and a fix would be to simply do this:
func isKnownCounterDataError(err error) bool {
if pdhErr, ok := err.(*PdhError); ok && (pdhErr.ErrorCode == PDH_INVALID_DATA ||
pdhErr.ErrorCode == PDH_CALC_NEGATIVE_VALUE ||
pdhErr.ErrorCode == PDH_CSTATUS_INVALID_DATA ||
pdhErr.ErrorCode == PDH_NO_DATA) { -------> this line here
return true
}
return false
}
obviously, this assumes that I am right about what's going on, and if the fix results in desired behaviour. If not, perhaps adding a global config flag that tells the agent to have this behaviour when desired (keep collecting and sending data for other other counters that do return data).
The text was updated successfully, but these errors were encountered:
Relevant telegraf.conf:
System info:
telegraf > 1.8, windows 2016, Hyper-V
Steps to reproduce:
Enable the config item for a counter that has no associated instances ("RDMA Activity", for example) on the server. the same applies to others.
Expected behavior:
Telegraf collects data from the many other counters that are valid, and do return data.
Actual behavior:
Telegraf logs an error similar to:
"E! [telegraf] Error running agent: error while getting value for counter \RDMA Activity(*)\RDMA Completion Queue Errors: No data to return."
and returns no other data.
Additional info:
Telegraf 1.8 does not behave like this - it sends for other counters.
As new to the windows agent, wanted to verify that this is a bug, and not expected (i.e. is the windows agent by design, supposed to return nothing as soon as a single input object has no data - guessing not).
The reason that we need this "fix" is because in large environments, it is a nightmare trying to change the local config on each server whenever there are no instances active (of any particular perf counter) goes away - for example, when admins are doing maintenance / playing with new features etc, they still want to be getting data from other counters.
The error is being returned from here (within the Gather func in win_perf_counters.go), two different places depending upon whether wildcardexpansion used or not:
and a fix would be to simply do this:
obviously, this assumes that I am right about what's going on, and if the fix results in desired behaviour. If not, perhaps adding a global config flag that tells the agent to have this behaviour when desired (keep collecting and sending data for other other counters that do return data).
The text was updated successfully, but these errors were encountered: