Forum Discussion

mnagel's avatar
mnagel
Icon for Professor rankProfessor
6 years ago

SDT "groups"

We have clients who have planned maintenance on specific locations requiring SDT.  This should be easy, but in fact is not at all easy and in fact is very error prone due to the level of manual effort required to think through what all is impacted by a "site" outage.  Each different element requires a different approach to setting downtime.  For example, we recently had a location maintenance notice and had to think through all of the following:

   * resources at the location (reasonably easy due to using location-based device groups, even though using those completely breaks the RBAC security model)
   * websites used to monitor that location (internal and external)
   * collectors at the location
   * we are not using the new service feature yet at this client, but that would be yet another SDT requirement

It would be far simpler and less error-prone if all of these could be scheduled for downtime at one time based on the fact that they are impacted by the location maintenance.  I was thinking one option would be an SDT group that could contain all element types, then that group could easily be scheduled in one fell swoop.

  • Unfortunately it has gotten no attention (or it has, it has been silent) and our clients (and us) are continually frustrated by missing things for simple "I want to set this location in downtime" when the concept of location spans many different elements, including resources, websites and collectors.  As mentioned, an API script can be written, but this is not something we can give to clients.

  • Hello,

    Any progress or update here still? We are going thru the headache of managing SDT's and I cannot believe there is no way to specify days of the week in one rule? I have to create 5 different Weekly Rules for each day that I need to define. 

    Also why is there no way to duplicate SDT's or apply to many different Machines/Devices and also Instance Level objects. (example processes or Windows Services). This is severely lacking in functionality.

  • Any thoughts on this?  I really hate telling clients stuff like... "ok, here's what you do -- first navigate to resources and add SDT for all your hosts at the site.  now, also go to the firewall external check and maybe website external checks and add SDT there.  and also go the internal cross-site ping checks and add SDT there. oh yeah and you also need to add SDT to the collector" and such.  Very clunky and error-prone.  I should be able to setup an SDT group spanning all monitoring types representing a logical unit (like a site) and tell then to just set SDT for that logical unit.  Again, constantly having to perform manual tasks like this creates pain and opportunities for error -- please make the computer do the job it excels at for us.

  • You could probably do it via the API, but that doesn't help you inside the portal. We're looking in to doing this using ServiceNow and attaching the ServiceNow location to all possible UI areas (Resource, Websites, Collectors, Services).

  • This is a serious headache for us as well, we need the ability to set Mass select/administer SDT as the current either at an overall group or individual device/instance level is far too restrictive/labourious.

    I have Feature Requested through our CSM '+' for the following that would certainly improve/help with the various patching/maintenance scenarios across WAN, Hybrid, Application, Azure/AWS environments, as well as make customer/service desk users lives easier for those that do not know or want to jump through API - prep/upload - (post) verify in LM resource views that actions applied; keeping these bulk action within the LogicMonitor UI would keep the process streamlined.

    1 - At Group & Datasource level, 'SDT' tab - checkbox's alongside 'Device'/'datapoint' instances so that multiples of devices/datapoints can be selected and added to SDT at the same time without having to do all or each individually, (Think along the lines of the 'Instances' tab already under resources but with the ability to select/apply SDT)

     

    2 - Ability to submit/apply SDT by selecting 'Properties' (custom, system, auto) - this again would give more flexibility to either create custom properties for specific instance scenarios or use properties that apply across multiple instances/groups, allowing for bulk administration for 'Resources' & 'Websites' 

     

     here's hoping the idea or variation gets traction

     

  • A couple of thoughts that may help.... Have you tried utilizing device properties to create dynamic groups? Ex. In our MSP model we have different clients assigned to resource groups, within their resource groups we make properties for location, type, etc. Then we also set a 'level property'. This would allow us to create a dynamic group with a query like join(system.staticgroups,",") =~  "ClientGroup1/ClientGroup2" && hasCategory("MicrosoftDomainController") || priority.level =~ "P1" 

     

    Have you also tried the mapping process and using the alert roll up? We cannot find a use case to work for us (yet) but, it seems like it may be good here. 

  • 3 minutes ago, JSmith said:

    A couple of thoughts that may help.... Have you tried utilizing device properties to create dynamic groups? Ex. In our MSP model we have different clients assigned to resource groups, within their resource groups we make properties for location, type, etc. Then we also set a 'level property'. This would allow us to create a dynamic group with a query like join(system.staticgroups,",") =~  "ClientGroup1/ClientGroup2" && hasCategory("MicrosoftDomainController") || priority.level =~ "P1" 

     

    Have you also tried the mapping process and using the alert roll up? We cannot find a use case to work for us (yet) but, it seems like it may be good here. 

     

    We use groups extensively to manage resource downtime (I have a different F/R in regarding that as we cannot simultaneously grant access to the group for contents management without also exposing the group itself to damage).  The problem here is cross-type SDT.  Consider that a site outage may involve resources down, cross-site website checks down and collectors down, perhaps others. We need to in one fell swoop be able to mark all related elements in SDT without having to track them down through all the dark corners of the UI.  As someone noted, this could be handled by an API script, but that is not something we can easily provide to clients.

  • Anonymous's avatar
    Anonymous

    Given: what I'm about to say below doesn't build this feature into the GUI. I've heard rumors that after the UIv4 refresh, websites and services will all live in the tree together with other resources, making it possible to do SDT for the whole group in two steps (collector object sdt would still be an additional step).

    Something like this: https://github.com/sweenig/lm_scripted_control yeah? Currently this is being used by a customer by their change management system to automatically put device into and take devices out of SDT. Their thought was the system controlling their change tickets should be the one in control of SDT. So, they use these scripts, called from their CM system. Wouldn't appear to be too difficult to add in website and collector SDT into the scripts (feel free to fork and submit a pull request).