Allow devices to be dependent on one another. If a router goes down, the switch behind it will most likely go down or have an error as well.

I have customers who really need this feature, and they are quite upset to learn the throttling stand-in could cause loss of knowledge about the actual root cause. This thread has been open since 2013. Exactly where on the roadmap is this? Mark

I'm happy to say this is on our road map. I don't know much - in terms of how we'll configure it, the visuals, user experience, or timeline - but it will be one of the larger projects we focus on this year. Keep the requests coming - especially any specifics in terms of which problems a feature like this may solve! Hi Annie, this is good news... From my point of view: It would be nice to create dependencies between targets across servers of other objects like routers, switches etc. Example: An application is running on server A where it's database is on server B. If we have a critical (or fatal) alert on the database, i would like to see that this will also impact the application object. Same thing when there is a critical alert on a server, this is most likely to impact anything that is running on this server. Or, if I take it to a network level: If a router is going down, it will for sure impact all servers connected to this router (which will impact anything on these servers or depending on these) In case this happens I would expect a target to get in a specified state (i.e. "related warning" or "related error"). Sending out alerts (for the childs) on this would not always be required as long as the original alert (i.e. networkswitch went down) is cleary indicating the impact based on the child relations. Or just an alert which refers to the original issue. Kind regards, Jeroen

I'm happy to say this is on our road map. I don't know much - in terms of how we'll configure it, the visuals, user experience, or timeline - but it will be one of the larger projects we focus on this year. Keep the requests coming - especially any specifics in terms of which problems a feature like this may solve! This is great news. From my part, I would like to see 1. Automatic network topology discovery, i.e., Logicmonitor would automatically scan the network and discover how devices are connected together and with what protocols. The information is partly there by just running nmap between every host. 2. Decent visualisation of the network topology, where you can zoom in on different parts of the network and navigate to a device's datssource easily 3. Decent management from the network topology visualisation, where you can click/search servers and say things like "everything connected to this machine by one node is now going into scheduled down time". I'm thinking regular expression matching would be really powerful in combination with this.

If this does not exist THIS IS A REQUIREMENT!!!!!! I have 100's of alerts at this point in time that can be triggered if something goes down in a key system. How is it that this monitoring system does not have this feature as of yet? for Managed Service Providers having the ability to squelch alarms when parent systems and or services go down is a de facto standard.

On 5/15/2017 at 7:58 PM, Annie Dunham said: There is definitely movement. We opted to solve the problem of drawing network and service maps first, as visualizing these relationships is step one. That is underway, and dependencies are slotted to follow. Dependencies (manual, if needed) are more important than any automation. ...especially if it means waiting 6 more months while the complex automated dependency mapping is done. Please, just get us dependencies. Multiple "parents" is necessary, as well. (e.g., a VM is dependent on the Host on which it runs, the storage on which it resides, storage switches, upstream switches, etc.

Dependencies or Parent/Child Relationships

Matt631
5 years ago
These Exchange codes dont work anymore. Getting an error about it being a private repo, Was this data-source pulled?
Todd_Theoret
Neophyte
4 years ago
Just following up to see what progress has been made and possible ETA for a solution to manage the "Parent/Child Relationships Alerting Suppression"....for use on all devices being monitored....and not using the Mapping option.

Please advise.

Thank you!
Anonymous
4 years ago

On 2/22/2021 at 2:00 PM, Todd Theoret said:

solution to manage the "Parent/Child Relationships Alerting Suppression"....for use on all devices being monitored....and not using the Mapping option.

This is not possible without Topology awareness.
Todd_Theoret
Neophyte
4 years ago

2 hours ago, Stuart Weenig said:

This is not possible without Topology awareness.

Thank you Stuart. Any chance there is a potential solution being developed which would allow....manually tagging....devices?
Anonymous
4 years ago
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.
Todd_Theoret
Neophyte
4 years ago

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.
mnagel
Professor
4 years ago

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.
Todd_Theoret
Neophyte
4 years ago

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:
Anonymous
4 years ago

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
Mosh
Professor
4 years ago
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.