Kaseya Community

Altering sets deletes previous logs

  • I have been tinkering with the Monitor tab for the past couple of weeks. It has been a difficult time. One of the issues thats been bothering me is that if any counter in an SNMP Set that is being used for monitoring a device is altered, you lose all previous monitoring data for that counter across all the devices that are being monitored using that SNMP Set. I am sure we wont be right the first time itself, esp. when the SNMP Monitor sets are yet evolving from us users.

    A case in point is an inconsquential parameter : Alarm Threshold. This was earlier set to a tiny value which was leading to a flood of alerts. Hence whenever I wished to refine this toa more logical higher value, I had to lose all monitoring history.

    Also, I tried adding a few more SNMP instances for monitoring multiple interfaces of a manageable switch. Once again I lost monitoring data for all interfaces and had to start from scratch.

    I checked the SQL tables and found that it deletes old MonitorSnmpObjectGetId and inserts a new record for it with obviously a new MonitorSnmpObjectGetId (also called InstanceID in frontend javascript).

    I wonder why this was so designed, and if at all so, why does the system not retain the old monitor logs and update its MonitorSnmpObjectGetId to the new one, rather than simply putting it in a blackhole.

    I hope there will be some update here, to avoid grief.


    Legacy Forum Name: Altering sets deletes previous logs,
    Legacy Posted By Username: ninad
  • Ninad,

    You provided a clear and concise narrative of an issue that we have recognized. As some background, during the focus group meetings, we discussed the specification that if the context of the monitor set changed, we would reset the log data (counter history). As the spec. evolved, most felt that almost any change to a monitor set (alarm threshold, collection threshold, instance, etc) would alter the ‘context’; therefore we wrote the code to ‘reset’ the logs and start over again on any change. This idea carried through the Beta cycle with little concern, but as the product is being used more and more it is becoming a aggravating inconvenience to have the logs reset if the user is just changing the ‘warning percentage’ or the ‘name’.

    So, in an upcoming hot-fix (I’ll commit to having this change out to the group within two weeks) we will only be resetting the logs if the Counter, Object, Instance, SNMP Object or SNMP Instance (interface) changes during an update.

    Thanks for the feedback,


    Legacy Forum Name: Technical Issues,
    Legacy Posted By Username: CMandell
  • Just a suggestion. In the event a parameter is changed, how about a prompt asking if the log files should be reset? That would give the admin the option based onhisneeds per change.

    Legacy Forum Name: Technical Issues,
    Legacy Posted By Username: shickey
  • Good idea; a couple people brought this up inthe design review. We will make sure we give that option.


    Legacy Forum Name: Technical Issues,
    Legacy Posted By Username: CMandell