Hi Dojo,
I've sure any admin, every now and then, has faced some connectivity issues with one or more elements in the DMS - this is extremely common when the monitoring overlay is getting built and of course, when this happens, we can experience some gaps in the trends, as no data was retrieved during the specific timeframe:
However, I've started to notice this also for test elements that weren't necessarily in timeout - the first interpretation given was to assume some data was missing - but how is DataMiner determining if a gap needs to be added in the trending? Is it based on sampling rate of real-time or avg_data?
Any steer will be helpful
Hi Alberto,
Gaps in trending can be caused by multiple things, like element or DataMiner restarts, but in this case it looks like the protocol is setting the parameter value to an exception value "N/A", the reason for this would need to be investigated in the driver logic.
But in this case it is definitely not a regular Element time-out, the value of the metric as Matthijs rightfully pointed out is explicitly set by the driver to the value N/A, which is a so-called exception value (i.e. the value is an analog metric ranging from 0 to the Max value with a certain step size, but under some specific conditions (as defined in the driver logic) the value is set to N/A (i.e. a discrete value that can be labelled as anything, in this case N/A). So one would have to look into the driver and see when and under which conditions this exception value is attributed to this metric.
Thank you all – so in the case where an exception value (e.g. N/A) is present,
shall we always expect a gap in the trended graph?
I’m used to gaps if a timeout is present, it makes perfect sense: what I was trying to establish is indeed what’s the default graph in presence of exception values.
If the data-set is containing the “N/A” exception value I would have expected (perhaps wrongly) a continuous line in the graph (to distinguish from a timeout).
When the parameter is also monitored, severities are reported in the axis – could some orange-zebra (dashed orange) lining be added if the element is in timeout opposed to when the exception value is defined as a possible one in the protocol?
In addition, might be interesting to look for timeout events on this element.