6 Replies Latest reply on Dec 3, 2010 10:07 AM by Karlo.Zatylny

    How Dependencies Work

    chris.lapoint

      To handle dependencies, we're introducing a new status called "unreachable" in this version.   This means if you've configured your alerts when things go "down", they won't trigger when objects are set to the new "unreachable" status.

      There are two types of dependencies:    

      • Implicit dependency:  E.g. When server is "down", don't alert on applications on this node.  Mark them "unreachable" to avoid redundant alerts.  This happens automatically without any configuration or work on your part.
      • Explicit dependency:   E.g. When WAN link is "down", don't alert on all nodes behind this WAN link.   Mark them "unreachable" to avoid redundant alerts.  This happens by manually configuring a dependency relationship. 

      You can test dependencies on nodes, interfaces, and volumes now in NPM Beta 2.   When APM Beta 2 is available, you'll be able to test applications and monitors.  

      More details on how this will work:

      • Implicit dependencies
        • NPM (volumes, interfaces)
          • When setting volume status to unknown, Node status will be checked. If Node status is down or unreachable, volume status will be changed to "unreachable".
          • When setting interface status to unknown, Node status will be checked. If Node status is down or unreachable, interface status will be changed to "unreachable".
        • APM (applications, monitors)
          • When setting application/monitor to down or unknown, Node status will be checked. If Node status is down or unreachable, application and monitor status will be changed to "unreachable"
        • IPSLA (operations)
          • [need to wait for SP1 avail] When setting operation status to unknown, Node status will be checked. If Node status at either end of the operation is down or unreachable, operation status will be changed to "unreachable".  NOTE: We will not make any changes to operation status when setting to down since for IPSLA this means we CAN poll the results, but the operation itself could not collect data.
      • Explicit dependencies
        • NPM (nodes)
          • When setting status on node to down or unknown, check for membership in a dependency relationship.  If the dependency indicates the app or monitor should be "unreachable", set the status to "unreachable".
        • APM (applications, monitors)
          • When setting status on application/monitor to down or unknown, check for membership in a dependency relationship (would be part of Group that is a child). If the dependency indicates the app or monitor should be ‘unreachable’, set the status to ‘unreachable’.
        • IPSLA (operations)
          • [need to wait for SP1 avail] When setting status on an operation status to unknown, check for membership in a dependency relationship (would be part of a Group that is a child). If the dependency indicates the operation should be unreachable, set the operation status to unreachable.  NOTE: We will not make any changes to operation status when setting to down since for IPSLA this means we CAN poll the results, but the operation itself could not collect data.
        • Re: How Dependencies Work
          byrona

          Chris

          Do you have mock-up's or a demo that you will be able to show.  I think I follow how this will work but not 100% sure.  I guess what I am trying to say is that I am a slow learner that prefer's pictures.  = )

          I have really been looking forward to the dependency work you guys are doing as I miss the functionality that I have had with software in the past.

          • Re: How Dependencies Work
            jspanitz

            Chris - what we think would be invaluable here are some reports - out of box - that will show the implicit and explicit dependencies and the resources assigned to them.

            The explicit report is probably the most critical, as this is the manually created type and will be the most confusing.  The report would look something like this:

            • Dependency Group A

              • Master (For lack of a better term) Group XXX
                • Cisco_sw1
                • Cisco_sw2
              • Child (For lack of a better term) Group YYY
                • Server 1
                • Server 2
                • Server 3
                • etc, etc.

            Does that make sense?

              • Re: How Dependencies Work
                Karlo.Zatylny

                Hi,

                That makes sense, but what would you expect to see if your dependency child or parent was a group that contained many levels of nested Groups?  Would you just expect to see one level deep?  All the objects from all the nested groups listed in a flat list?  Or a hierarchical view of the nested groups and their members?

                Not promising anything, just gathering expectations :)

                Thanks