Dependencies or Parent/Child Relationships


Richard Ortiz
 Share

Recommended Posts

  • Administrators

As far as i'm aware, you can't manually edit ERIs. However, you can easily write a static PropertySource that statically tags those devices. You'd then also need to write the companion TopoSource to tie them together, unless you were planning on manually adding ERIs that are already referenced by an existing TopoSource, which isn't likely. They pretty much have to work in conjunction with each other.

That said, after you get the topology awareness into LM, you still need to specify your entry point, which orients the dependency tree from root to tip. Let's keep this conversation going because I think we can do what you're looking to do.

Link to comment
Share on other sites

5 minutes ago, Stuart Weenig said:

As far as i'm aware, you can't manually edit ERIs. However, you can easily write a static PropertySource that statically tags those devices. You'd then also need to write the companion TopoSource to tie them together, unless you were planning on manually adding ERIs that are already referenced by an existing TopoSource, which isn't likely. They pretty much have to work in conjunction with each other.

That said, after you get the topology awareness into LM, you still need to specify your entry point, which orients the dependency tree from root to tip. Let's keep this conversation going because I think we can do what you're looking to do.

 

You think we can do it!

What would it take to have a call with you to discuss further? We are an MSP and need this capability ...."yesterday :)" to decrease the number of tickets created by dependent devices.

 

Just for reference:

I am familiar with the TopologySources/Mapping/Root Cause Analysis....pretty slick.

I even circled back and retested...again...using these two datasets. Neat concept but not a solution for our requirements.

image.png.11cc93295efda21b41b3173b737b7deb.png

 

Link to comment
Share on other sites

1 minute ago, Todd Theoret said:

Thank you Stuart. Any chance there is a potential solution being developed which would allow....manually tagging....devices?

So this has been an issue for us a lot -- everything was tossed into the topology umbrella for alert suppression with no easy way to manually create dependencies.  There are many topologies that are simply not discoverable, like multipoint/mesh WAN topologies and really anything not handled by topology sources. 

The good news is that some kind support tech provided me a Manual_Topology module that linked various devices manually that eluded auto-discovery.  The bad news is it is awkward and leverages hardcoded device names and MAC addresses.  But, it is possible.  IMO the UI and/or API should be extended to support manual links.  It is a last resort of course, but there are common cases where it is the only resort.

Link to comment
Share on other sites

4 minutes ago, mnagel said:

So this has been an issue for us a lot -- everything was tossed into the topology umbrella for alert suppression with no easy way to manually create dependencies.  There are many topologies that are simply not discoverable, like multipoint/mesh WAN topologies and really anything not handled by topology sources. 

The good news is that some kind support tech provided me a Manual_Topology module that linked various devices manually that eluded auto-discovery.  The bad news is it is awkward and leverages hardcoded device names and MAC addresses.  But, it is possible.  IMO the UI and/or API should be extended to support manual links.  It is a last resort of course, but there are common cases where it is the only resort.

Thank you for replying!...any chance you have a sample of this Manual_Topology script populated to show the required hardcoded syntax and format?

I believe I found the module you are referencing:

image.thumb.png.5a22a814b9d7cd63455c1a17d92361d8.png

 

Link to comment
Share on other sites

  • Administrators
15 minutes ago, Todd Theoret said:

What would it take to have a call with you to discuss further? We are an MSP and need this capability ...."yesterday :)" to decrease the number of tickets created by dependent devices.

We have our monthly office hours where we are available to answer these kinds of questions. In fact, we're having one today: https://logicmonitor.zoom.us/webinar/register/7916079754259/WN_r5R0uO--SuKYk5yIH_Mbpw?_ga=2.222987995.1127647679.1614006119-851486786.1607022888

Link to comment
Share on other sites

Agree with @mnagel, not all relationships between resources are technical and discovereable using techincal data.  Some relatiosnhips are business process relationships.  Being able to manually arbitrarily relate resources would be great for us to model our business process dependencies between resources.

Link to comment
Share on other sites

  • Administrators

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.

image.png.359e4898b98594b1d65d776fe134e643.png

  • Haha 1
Link to comment
Share on other sites

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.

image.png.359e4898b98594b1d65d776fe134e643.png

 

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

Link to comment
Share on other sites

  • Administrators

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:

image.thumb.png.e9e17fcc17dbd9468e4e6ee966a25150.png

Link to comment
Share on other sites

  • 1 month later...

Just asking incase someone is in a great mood today :) ....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!

Link to comment
Share on other sites

  • Administrators

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. 

image.thumb.png.b2016a93c94c2554526625d8a676cfe8.png

 

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?

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

  • Administrators

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. 

image.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Administrators

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"
    }
  ]
}

 

Link to comment
Share on other sites

We are staring at the fishline Stuart. Hopefully last question and an example:

1. (example): write a TopologySource that ties those ERIs together:  Any chance you could provide the TS configurations utilized to actually build the dependencies?

Thank you again Stuart.

 

 

Link to comment
Share on other sites

  • Administrators

Sure. Normally the TS discovers the relationships by querying the device and asking "who is your neighbor" or something along those lines. For VMWare, the TS talks to the vCenter server to get the relationships. This is why ERIs are needed. When you talk to a system that knows about the nodes on the map, that system may have its own way of identifying those objects. The ERIs previously added serve as the multiple ways that third party systems might refer to those objects. Some, like the cam table in a router, refer to neighbors using MAC addresses. Some, like vCenter, may use a FQDN or some other ID. As long as the third party system responds with relationships between objects, and refers to those objects using an ERI that is on the device, the relationship can be mapped in LM. 

Think of it this way, if I (as a TopologySource) am telling you that Bob (parent) has 3 sons, Andy (child), Stuart (child), and John (child), then you would need to make sure you know who those four people are, especially if you only know those four people by email address. You would need an external resource identifier (ERI) that maps Bob to Bob's email, Andy to Andy's email, etc.  That way, when I tell you about Bob's children, you can know who I'm talking about, definitively. 

So, for a TS, you have two options: 1) query some system that knows which parents have which children or 2) manually hard code the relationship in the code. #1 is not likely an option, so you'll probably have to do #2, but let's discuss it anyway:

If you have some system that identifies parental relationships to children, we have to make sure the ERIs we've set on each device in LM match the IDs that the system will use to identify the devices. So, if your third party system identifies things by FQDN, you'll need to write an ERISource that adds FQDN as an ERI. If your third party system identifies things by IP address, you'll need to write an ERISource that adds the IP address(es) as ERI(s).

Then, it's just a matter of writing the TS that asks the system to list out the relationships. Your script would contact the system, make the request, then format the output. The output would be in this format:

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

You may want to parse through the data and make the relationship bidirectional, adding "Supports" relationships from the parent nodes to the children nodes, but it's not strictly required.

 

If you're going to hard code the relationships in the code, it's just a simple print statement, outputting the mapping shown above. It might be a much longer print statement in your case.

Link to comment
Share on other sites

  • Administrators
println('{"edges":[{"type":"Depends On","from":"LMID_2","to":"LMID_1"},{"type":"Depends On","from":"LMID_3","to":"LMID_1"}]}')

There are alternative ways, but this is the most straightforward. One alternative way is to build a Groovy map (similar to a Python dictionary) containing the entries. Then convert the Groovy map to json and print it out.

Link to comment
Share on other sites

I take it ERIs are exact matches. Is there any way to use regex for the "to" side?

For exampke, where I have a resource with ERI "ABC001-START", I want it to have edges with any other resource where the ERI matches regex ABC001-OTHER.*.  

    {
      "type": "Depends On",
      "from": "ABC001-START",
      "to": "ABC001-OTHER.*"
    },
Link to comment
Share on other sites

6 hours ago, Stuart Weenig said:

No way to wildcard either side as far as i'm aware.

I suspected not, but thought I'd ask anyway 🙂

In my use case the "ABC001-OTHER..." resources are typically sequentially numbered, e.g."ABC001-OTHER01", "ABC001-OTHER02", "ABC001-OTHER03", etc. so I can work around it by simply using a loop in the code to generate entries in the edges collection for resources that may not yet exist, but if they came into existence then they would fall into place.  

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share