ProfessorWe saw similar issues with Hyper-V metrics, might be a similar root cause -- see comments from our ticket below. We have found this problem in general with LM since we started working with it -- lack of data collection is silently ignored as a rule. You can find various ways to deal with it, and LM tries to add meta-methods like troubleshooter datasources, but the overall system for this is very fragile. The right fix would be to allow for longer term analysis of data and to make 'unknown' be a first-class alert option like critical, warning and error. You could then write one rule for all datapoints looking for (say) 1 hour of unknown results and be done with it. Both of those features would have much more benefit beyond this use case. Suffice to say, I filed both of those years ago as feature requests and you can guess how that went :). Our next best solution is to analyze dashboards for widget problems. You will notice that when a graph widget has no data, LM says that in the display. We struggled for a bit with how to get that data and I finally did figure it out. Now our backup script has a "check" option that scans a bunch of things for problems, including widgets. So we know within a day if something has stopped reporting. Could be faster if we schedule checks more often, but a day is far better than "when you happen to see it broken during a client review meeting."
Mark
The collector GD31.003 now has the fix and you can update your collector to the v.31.003. Please test and let us know if the issue is fixed for you.
https://www.logicmonitor.com/support/gd-collector-31-003
Fixes
Issues were reported for batch script data collection due to multiple or no periods in the formation of instance name and datapoint name. For example, in the datasource the key value pair has multiple periods – keyvalue(##WILDVALUE##.storage.totalsize.filesystem) and therefore it failed.
We have fixed this issue. A datapoint now will not fail even if it has multiple periods or no periods.