Dependencies or Parent/Child Relationships

Right. We have an example of mapping this "non-discoverable" business dependency using Super Mario World level entrances/exits. We have existing objects in LM that have ERIs. Then we wrote a TopoSource to statically relate one object with another until we have a complete mapping. I can demo this during Office Hours today.

30 minutes ago, Stuart Weenig said:

Right. We have an example of mapping this "non-discoverable" business dependency using Super Mario World level entrances/exits. We have existing objects in LM that have ERIs. Then we wrote a TopoSource to statically relate one object with another until we have a complete mapping. I can demo this during Office Hours today.

Stuart...when trying to register for the zoom call....today is not an option you can select.

Dang. Probably because we already started it. Can you go here? https://logicmonitor.zoom.us/webinar/register/WN_wnDgHJ1nQhKRZDJsErE0sQ

Sorry, it just ended. You can view the replay here: 

You can also register for any of the upcoming Office Hours where you can ask your questions live.

You can find the Super Mario DS and TS that I reference by searching "Super Mario" in the Exchange Public Repository:

Just asking incase someone is in a great mood today :)/emoticons/smile@2x.png 2x" title=":)" width="20" /> ....any chance someone could provide a sample or two of a couple devices and the associated new custom properties which are required?

Are the below property names accurate...or close?  What values are required for the properties?

topo.namespace
topo.blacklist
edge_type
from_obj
to_obj
edges

An example or two would really assist...and would be so much appreciated!

Ok, this example builds everything from the ground up. First, a DataSource discovers instances and as the instances are discovered, the predef.externalResourceID and predef.externalResourceType are set. Each world in Super Mario World is created as an instance. The ERI for this instance is "Chocolate_Fortress" and the type is "SMWExit". This gets the "nodes" for your topology. Now you need to discover the "edges"/relationships between those. 

TopologySources discover the relationships/edges. In this case, the TS output looks like this. Notice that this is a JSON formatted list of edges, where each edge specifies two nodes' ERIs and the type of connection between the two nodes.

{
  "edges": [
    {
      "from": "yoshi_s_island_1",
      "to": "yoshi_s_house",
      "type": "Path"
    },
[[[OUTPUT TRUNCATED]]]
    {
      "from": "chocolate_island_3",
      "to": "chocolate_island_3",
      "type": "Normal"
    },
    {
      "from": "chocolate_island_3",
      "to": "chocolate_fortress",
      "type": "Secret"
    },
    {
      "from": "chocolate_fortress",
      "to": "chocolate_island_4",
      "type": "Normal"
    },
    {
      "from": "chocolate_island_4",
      "to": "chocolate_island_5",
      "type": "Normal"
    },
[[[OUTPUT TRUNCATED]]]
    {
      "from": "outrageous",
      "to": "funky",
      "type": "Normal"
    }
  ]
}

Does this help?

Still not clear Stuart....

1. Are the "instances" actually other device displayNames being monitored?

2. Is the datasource applied to just a single device?....possibly the device utilized as a "Entry-Point for Topology Based Dependency"?

3. Do you have an example of a "Root Cause Analysis" entry based on this manual topology configurations to support the alerting suppression for downstream devices?

Thank you for your time!

1. In this case, i'm putting instances on a map as vertices. But, it could just as well be devices themselves that are already in monitoring. To set the ERI on a device, all you need to do is create a PropertySource where the data type is set to "ERI Source" and have the PS output in the corresponding format. Each device and/or instance that you want to show up on a topology map needs to have its own ERI. 

2. The datasource, in this case, only exists to create the instances with their corresponding ERIs. You don't have to have a DataSource at all if the only vertices you want on the map are devices.

3. For RCA, you would just help LM know which is the root of the depency tree by specifying one of the vertex devices as the entry point. 

Getting closer...any chance you could provide an example of what the configs for the custom device ERI PropertySources would look like?  Thank you again.

[Ping/Host Status Only]

1.          Device1: 10.1.1.1   (RCA – Entry Point]

              a.       ERI PropertySource Example

2.          Device2: 10.1.1.2      [child to Device1]

              a.       ERI PropertySource Example

3.          Device3: 10.1.1.3      [child to Device1]

             a.       ERI PropertySource Example

The ERI PropertySources only ensure that unique identifiers are stored on the device itself. It's a prereq for actually tying devices together.  Most often the ERI has the mac address of the device. If all the devices you want to add as nodes already have a predef.externalResourceID, then you don't have to worry about the property source at all. But it is something to check.

The TopologySource is the one that maps the parents to the children. 

So, if Device1, Device2, and Device3 already have predef.externalResourceID, then all you have to worry about is the TopologySource. Let's add some fictional details to your example:

1.          Device1: 10.1.1.1   (RCA – Entry Point] 8a:72:63:5f:45:4e, LM device id: 1

2.          Device2: 10.1.1.2      [child to Device1] 1c:b0:85:0b:fc:6f, LM device id: 2

3.          Device3: 10.1.1.3      [child to Device1] 8f:05:2f:59:56:ed, LM device id: 3

You have a property source, out of the box, that likely already put the mac address as one of the ERIs on each device. If these really are ping only, then you'll need to create an ERI PropertySource (it can be done in one) to assign the mac address, or some other UUID to each device. This can be done with a PropertySource like this one.

Once all your devices have ERIs, you would then need to write a TopologySource that ties those ERIs together. The TS would only really need to run on any parents. The output would look like this in your example (assuming you used the linked ERISource):

{
  "edges": [
    {
      "type": "Depends On",
      "from": "LMID_2",
      "to": "LMID_1"
    },
    {
      "type": "Depends On",
      "from": "LMID_3",
      "to": "LMID_1"
    }
  ]
}