Advisor
ProfessorWhile this is not directly related to your feature request, I am interesting in your design setup as you mentioned it above (and perhaps I should start a new thread). I know that LM does lean you towards placing all the devices in one place and really focusing on using dynamic groups, but I wonder how well that works in an MSP situation. The designs I’ve used in LM (also as an MSP), done years ago though, have the same per-customer root folders/groups but devices are static within those customers groups. Actually it’s also broken down by technology groups within the customer group (like network, server, etc). This allowed for using the staticgroups property for customer separation in dynamic groups. It also made it easier to determine the “owner” of the device if your MSP organization has a lot of people involved in monitoring. I do wonder how adding devices outside of the customer group and/or technology sub-groups works for others and what benefits it may have. I can see having devices with multiple roles in multiple groups being useful.
Also a few other things. Code from DataSources and PropertySources are always run from the collector itself. For some MSPs this may mean the code is running on collector servers you don’t fully control or are owned by your customers. So if you use API keys in this code, I always worry about it being potentially leaked to the customer. So you may want to be careful not to use a global API key that work across multiple customers. Same applies if you do some of the API hacky tricks with Dashboards if your not careful. And those might leak to the end user using the dashboard. It may help either having per-customer keys and/or using them on collector servers you have.
Also as far as I know there is no MSP version of the LM portal at a technical level (perhaps for licensing and contracts). You eventually run into various things where the design doesn’t seem to account for MSP situations, but generally you can get around them.
