Avoiding duplicate instances
Hi Throwing something out there for advice. There are a number of datasources that are subject to duplication of instance because you cannot safely turn on the automatically delete as legitimate instances may go down for longer than 30 days. This appears to be due to them being very dependent on the instancename, so if this is something the customer has the ability to change then it creates another instance during Active Discovery. My question is if anyone has an ideas on a complex datapoint (or some other means) that can detect that this instance has matching property to another instance. This could be say auto.device.mac_address or even the Instance Value as these always match between the duplicate instances. This is really bugging me now so I really need to find a proactive way to address them. The real downside is that you lose the historical data when it is actually the same device. What the ideal would be is if you could merge instance or at least delete the new and rename the old one to the new ones name so its not discovered again.UIv4 instances when there are none?
Perhaps I just wasn't paying attention previously, but does the new UI show everything has an instance even when it's not a multi-instance DataSource now? Is that a recent change? It automatically jumps to the "instance" when you click on the DataSource entry so not really causing an issue but kinda threw me for a loop when I thought a DataSource I was working on was somehow creating instances when it shouldn't. Seems kinda odd and perhaps confusing when training on what instances are if everything looks like it has one.Dynamic Instance Group Alert Tuning
This is not an advertisement by any means, just offering to help anyone who struggles with this as well. As an MSP,we have struggled with how to handle alert tuning in bulk with it comes to things like Interfaces (instances). Some of the interfaces you want to alarm as critical, some you want as error and others you don't care about at all. LM provided a partial fix for that with their Groovy based "Status" alarm based on the interface description, but it didn't take it far enough. We started creating manual interface groups called "Critical" and performing Alert Tuning on that "parent" only to find out that it doesn't work as interfaces move in and out of it. I was beyond disappointed, but it said it right at the top of the page:Changes made to Alerting or Thresholds will only affect existing instances currently in this Instance Group. Instances added later will not be subject to the changes. Anyway, long story short we finally decided to write our own application to do it and built it in Azure. We built it to handle multiple data sources so we could group other instances (like VMware vDisks) and do the same bulk changes. It was written to be a data source in your environment, so that you can apply it to whatever devices you want and just call out to the API with the device name. If you have any interest in using it, let me know. There are costs associated as Azure bills based on usage, but it is pretty small for us (< $200/mo). Trust me, I wish LM solved this without having to write the app!
