IIS SMTP 6.0 Sensor Reports inaccurate results

Dear Scott,

Sorry, we can not reproduce this issue. Does this happen after sensor creation only or even if you pause and resume the sensor. Does this also happen after you edit some of the sensor settings?

Best Regards

I've still not received any other input on this issue, although I'm quite sure I responded to the above post. Just in case I did not... This happens, seemingly, only after the SMTP services is restarted on the SMTP server that is being monitored. Pausing or unpausing the sensor doesn't seem to have any bearing on it.

Just wondering if anyone ever had a chance to look into this. Just to clarify... What we are looking for is a way to track total messages sent and received on an SMTP relay. This sensor seems like it could be very useful except that it spikes into the millions when we reset the SMTP service. Of course, we could set a spike filter, but this means that the results would be inaccurate since some valid values would be filtered out with the invalid values. On a broader note, it would be very useful on many different sensors and sensor type to maintain a "running total" that does not get reset when services restart or when other events take place. Would this be difficult to implement?

Dear Scott,

I'm sorry for the late reply, I'm afraid right now, we unfortunately have no solution in this case. We can't reproduce the issue here in our lab, and don't have the according logging capabilities in PRTG for all sensor types for several scans (this is considered, but not yet fixedly planned).

I'm sorry, right now, the spike filter seems the only work-around.

Best Regards.

This is a very late reply to this post, but what about the possibility of a "running total" in PRTG? Using the example of the SMTP sensors, it would be helpful to track the Total (for all time) messages sent and received. The issue with SMTP (and with other services and values that we track) is that the count resets when the service resets. It would be extremely helpful if you could see a "Running Total" for a particular channel on a sensor. Is this possible? If not, is it something that could potentially be added in a future update?

Again I'm sorry that's also not possible, but as well not very likely going to be implemented to be honest.

Torsten,

Thanks for the response and setting realistic expectations.

Will it make any diffference if I elaborate on the scope of our request? We would like to add that this requested 'calculation' should be available for all hit's related sensors and possibly others. Without the ability to track a running total I can only guess at a means of getting to where we want to be with a means to calculate things like hits/ day, hit/s week, or hits/ year.

Alternatively, is it possible to accurately calculate the same hits/time-period from the 'rolled up' averages presented in PRTG (10day 100day, etc)? Because we don't know exactly how PRTG calculates the averages during roll up, it's difficult t know if we can use them for other calculations. Does PRTG consistenly avg all samples from a time period when rolling up or does it only take one sample when rolling them up? From observation, it appears to take all samples, but can you explain how it's affected by filtered spikes?

Thx and you're welcome to reply to me directly. Thx.

Sorry, for the late reply Travis, PRTG does use all values in a certain period above which an average is calculated. That applies for reports, historic data calculations and of course the 'normal' graphs in PRTGs interface. However, if a spike filter is used, those values 'excluded' by the spike filter will also not be accounted for the averaging.