Dependencies or Parent/Child Relationships
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.
Richard_Ortiz
Posted 13 years ago·Last reply 5 years ago
99 comments
Todd_Theoret
·5 years agoStuart....I wanted to thank you again for your guidance....and patience... with this manual mapping. I was able to get the functionality to work on a small scale.
Thank you!
LM User
·5 years agoExactly what I'd do.
Mosh
·5 years agoI 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.
LM User
·5 years agoNo way to wildcard either side as far as i'm aware.
Mosh
·5 years agoI 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.*.
LM User
·5 years agoThere 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.
Todd_Theoret
·5 years agoWhat would the TS code be which generated the output above?......please.
LM User
·5 years agoSure. 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:
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.
Todd_Theoret
·5 years agoWe 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.
LM User
·5 years agoThe 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):
Todd_Theoret
·5 years agoGetting 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
LM User
·5 years ago1. 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.
Todd_Theoret
·5 years agoStill 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!
LM User
·5 years agoOk, 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.
Does this help?
Todd_Theoret
·5 years agoJust 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!
LM User
·5 years agoSorry, it just ended. You can view the replay here:
/topic/7124-2021-02-24-us-office-hours/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:
LM User
·5 years agoDang. Probably because we already started it. Can you go here? https://logicmonitor.zoom.us/webinar/register/WN_wnDgHJ1nQhKRZDJsErE0sQ
Todd_Theoret
·5 years agoStuart...when trying to register for the zoom call....today is not an option you can select.
LM User
·5 years agoRight. 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.
Mosh
·5 years agoAgree 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.
LM User
·5 years agoWe 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
Todd_Theoret
·5 years agoThank 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:
mnagel
·5 years agoSo 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
·5 years agoYou 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.
LM User
·5 years agoAs 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
·5 years agoThank you Stuart. Any chance there is a potential solution being developed which would allow....manually tagging....devices?
LM User
·5 years agoThis is not possible without Topology awareness.
Todd_Theoret
·5 years agoJust 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!
Matt631
·6 years agoThese Exchange codes dont work anymore. Getting an error about it being a private repo, Was this data-source pulled?
ntw2
·7 years agoChris_Sternberg
·7 years agoThe Alert Dependency project currently in beta makes use of automatically discovered Topology mapping relationships and is not directly related to the SDT_Dependent_Devices and SDT_Assign_Primary_For_Dependencies datasources.
Is the issue that the automatic SDT no longer being placed on the child resources that have the depends_on property to the is_primary_device parent resource?
ntw2
·7 years ago@Chris Sternberg Was there a regression in a recent LM release which broke the dependencies feature that you developed? Our dependencies were working until a few weeks ago.
Chris_Sternberg
·7 years ago@chendricks @Mosh
I emailed you both separately to setup a call on the Alert Dependency project. Look forward to hearing from you!
Mosh
·7 years agoI'm interested too please.
chendricks
·7 years ago@Chris Sternberg, yes please, let's have a call.
Chris_Sternberg
·7 years ago@chendricks There have been no updates to this datasource to include services. I am working on the Alert Dependency project based on Topology which does provide for service dependencies. Let me know if you are interested in learning more and we can setup a call to discuss the details of this project.
chendricks
·7 years ago@Chris SternbergWas service dependencies added to this? We really have a need for it.
Mosh
·7 years agoThanks @Michael Fisher
If the alert suppression is part of the core platform that is good news.
Michael_Fisher
·7 years ago@Mosh
The majority of our Topology offering will be core to our platform. However, aspects of Topology, such as advanced overlays, widgets, saved maps, etc, are features that are subject to be billable items in a broader LM AI platform that we are actively working on.
Stay tuned for the launch email I will be sending out soon which will contain more info on this subject.
Best,
Michael
Mosh
·7 years agoThanks @Chris Sternberg
Will the topology module be a licensed module or included as part of a forthcoming update?
Chris_Sternberg
·7 years agoHi @Mosh
Alert suppression based on dependencies relies on topology, so provided that we are able to discover the connections between the routers and devices that are dependent on them for connectivity, then we would be able to enable it for the network devices in those groups. You won't manually define which device groups are parents and which are children, but identify the core entry-point devices, in your case this would appear to be the routers, and any discovered device connections to those routers would be categorized into a dependent parent/child hierarchy. Meaning that if you have a core router connected to a firewall which is connected to a switch which is connected to a server, where each connection is an additional step removed from the core router, each device would serve as a parent for the next device in this hierarchy. So this means that if a router goes down then all alerts for the child firewall/switch/server devices would be identified as dependents, but also if just the switch went down then the alerts for the server would be identified as dependent to the switch going down.
The current phase for topology is focused on CDP and LLDP discovery protocols so those would need to be supported by the devices in question. At this time the alert dependency functionality with use of SDT that I described in my previous post is only available for NG portals, but since you have a sandbox let me know if you'd like to get your hands on it for testing as I would love to get your feedback.
Also, I want to clarify some points around the term alert "suppression". While we have started with the use of SDT as the best tool we currently have to suppress alert notifications, we are not looking to prevent or disable alerts for dependent resources. Instead we want to identify or tag dependent alerts so that you can configure how you view them within LM and route them externally for notification. The goal is to provide an "area of effect" for an alert storm and categorize the alerts based on their role as root or dependent causes. It would then be up to the user whether dependent alerts should be shown in various widgets, and if notifications for dependent alerts should be routed for notification. Ultimately, alerts for root/originating causes and their dependents would be displayed as such in the Alerts page.
I would love to get your feedback on the functionality we have so far and where we're headed so please let me know if you have additional input and whether you'd be interested in testing the functionality as it stands now in your sandbox portal.
Thank you,
Chris
Mosh
·7 years agoHi @Chris Sternberg
We organise each countries network CIs (configuration items) into groups by firewalls, routers, switches and wireless (see attached image). What we need to be able to do is somehow say that if any CI under the Routers group and subgroups is down (ping loss and host status), then alerts should be suppressed for the Firewalls, Switches and Wireless groups and sub-groups.
Will what you are proposing enable us to do this?
Chris_Sternberg
·7 years agoHi Everyone! Chris Sternberg here and I'm the PM working on the Alert Dependency & Suppression project.
We are working on an algorithm for alert dependency based on resource "reachability" using the relationships established by topology and would appreciate any input you have to offer. There are two primary issues we are trying to address: 1. facilitate root cause analysis by identifying the resource alerts that initiated an alert incident 2. prevent alert noise by suppressing routing for non-actionable/dependent alerts (we are starting out with SDT but are researching an alert dependency tagging approach and configuration to use instead of SDT)
The first step in the process is the addition of an entry-point property that selects a resource as a parent for all connected resources. Using the topology relationships any connected resource can then be identified as a dependent as well as the number of steps it is removed from the entry-point. When the algorithm runs, if a critical PingLossPercent alert exists (i.e. is the resource reachable) on any dependent resource it checks its connected resources that are one step closer to the entry point (i.e. its upstream neighbor/parent as opposed to the "umbrella" parent entry-point), and if any of those are also in a critical PingLossPercent state, we determine its state is dependent and the resource is placed into SDT. The process continues up the chain until there are no other parent devices that are in a critical "reachability" alert state, or the entry-point resource is reached. That last resource in a critical state is identified as the root/originating cause and any neighbor/parent along the chain that was one step closer to the entry point is identified as a direct cause. For any alerts placed into SDT by the auto-SDT applied to the resource, the originating cause and direct cause are recorded in an SDT note.
High level logic flow:
This approach is reactive in that an alert has to exist for a child as well as for a parent in order for the child to be suppressed/placed into auto-SDT. The datasource approach discussed in the posts above is more proactive in that all dependents are placed into SDT based on a parent being in a critical alert state. Neither approach is 100% effective in preventing alerts on dependents in part since there is no guarantee that a parent will be in an alert state before a child is in an alert state. The algorithm is more reactive and only SDT's resources actually in alert, and in turn facilitates root cause analysis by identifying an originating cause to the alert incident. The datasource is more proactive and suppresses child alerts via SDT preventing additional notifications.
As mentioned we are researching a method whereby we tag alerts for both parent and child resources with metadata to identify cause and dependents. We would allow for routing configuration for alert notifications based on the alert dependency tag metadata.
A main issue for the suppression of alert notifications for dependent or non-actionable alerts is timing since instances are not all polled in the same interval nor are they polled based on dependency. In order to try and prevent routing for as many dependent non-actionable alerts as possible we are considering an option to delay routing for resources that are part of a parent/child dependency chain. The notifications could be delayed until we have identified cause and dependent alerts to be routed based on user configuration. Critical alerts for which routing is suppressed based on dependency, could be routed later should the critical alert remain active once a parent resource is no longer down.
Questions for feedback:
1. What do you think of an approach that would delay routing for a short amount of time (TBD) in order to allot enough time for an alert dependency incident to get into full swing and allow the dependency algorithm to tag alerts with relevant cause and dependent metadata? This metadata would be used to determine what notifications should be routed and which should be suppressed.
2. When a critical “reachability” alert occurs for resource(s) in a dependency chain, should other alerts that occurred X #number seconds/minutes prior to the first “reachability” alert also be considered part of the alert dependency incident?
3. In your experience, how quickly does an alert dependency incident fully manifest itself in LM? Meaning from the first parent device going down, to the last dependent going down as well, how long does this typically take? Of course this can depend on what types of resources are involved so any input in that area and whether timing falls in range of (A) Less than 1 min (B) 1-3 mins (C) 3-5 mins (D) more than 5 mins, would be helpful.
4. We are starting with Ping | PingLossPercent datapoint. What other datapoints are you using as indicators of resource or instance “reachability”?
I greatly appreciate any feedback and additional questions!
Thank you,
Chris
ntw2
·7 years ago@Steve Francis Thank you for this, Steve! Can website ping checks be used as primary devices/values for 'depends_on'?
mnagel
·7 years agoNever mind -- I waded through the docs more thoroughly and found the section about defining the API credentials.
mnagel
·7 years ago@Steve FrancisI finally got around to deploying and testing this, but it is not going well. I tried a poll now on the Assign DS and I get "Fail to get the script result - sseId:0 NullPointerException: Cannot invoke method getBytes() on null object". Is this being impacted by the v2 API changes?
Keimond
·8 years agoPlease include "Grouping" too :)/emoticons/smile@2x.png 2x" title=":)" width="20"> We just got flooded with a bunch of pages last night because a server went down which caused instances from several datasources to go down.. OUCH! It would be great to group instances so that if one goes down.. that group pages and says hey something is wrong with this server.. then we can log in and go check.. rather than getting flooded by everything.
Same idea with grouping of servers... I could call a group "HKG POP"... a server goes down that I have put in that group.. or any instance alerts a critical.. just that one group pages and says hey a critcal event has happened in the HKG POP.... and if other servers go down... it's not going to page again if it already has and hasn't been resolved. ( I can see a few gotchas in there.. but with enough configuration choices.. the company can decide how they want to handle situations )
/topic/1475-alert-triage-ie-grouping-alert-reduction?do=embed" style="height:221px;max-width:502px;">Keimond
·8 years agoDefinitely a step in the right direction for LM.. now we just need to be able to use this for stuff that goes down but doesn't have an SDT lol... I assume the same logic can be applied but that involves deeper changes than data sources :)/emoticons/smile@2x.png 2x" title=":)" width="20">
I may have missed it but if it hasn't been requested, besides host dependencies, we should have service dependencies. There should also be multiple dependencies.
* Host 03 depends on Host01
* Host 04 depends on Host01 AND/OR Host02
-- (and) don't alert Host04(and services) if Host01 and/or Host02 are down.
-- ( or) don't alert on Host04 if just Host01 or Host02 are down.
* Service07 depends on Service05
* Service10 depends on Service05
* Service08 depends on Service01 AND/OR Service02
-- (and) don't alert on service 08 if Serviec01 and/or Service02 are down.
-- ( or) don't alert on service08 if just Service01 or Service02 are down.
and the list could go on with multiple scenarios...
* Service09 depends on Host 01
* Service12 depends on Host 01 AND/OR Host02
* Host03 depends on Serivce04
* Host03 depends on Service02 AND/OR Service06
pperreault
·8 years agoHas using an empty value for the depends_on property been tested to have negative results? My testing shows no ill effect. Adding this property at the group level obviously speeds deployment. However if the primary device is within the group I don't want to make it dependent on itself. Adding the depends_on property to the primary device with an empty value seems to resolve this.
Joe_Flowers
·8 years agoWorking beautifully now!
Steve_Francis
·8 years agoPublished, locator 24KKNG
Updated the documentation article above. Please let me know if there are any other issues.
Joe_Flowers
·8 years ago@Steve Francis thank you sir! Please do let us know when the update has been published. :)/emoticons/smile@2x.png 2x" title=":)" width="20">
Steve_Francis
·8 years agoYep - I made a mistake in the device filtering, so it was only finding dependents that had the depends_on set directly on the device, not those that were inheriting it via groups (although I was sure I tested that...)
Anyway, I've found the error, and fixed it, and will publish tomorrow after a bit more testing.
Sorry about that..
Joe_Flowers
·8 years agoHmm... This doesn't seem to be working for me. It appears to be; up until the point an alert fires.
I've set a group that has the depends_on property set. Then have placed all relevant devices into said group (same upstream device). Everything appears to be working as expected. I see all devices in the group have inherited the depends_on property. And when I look at the primary device, it has indeed got the is_primary_device = true property set. However, when I kick off a test alert for PingLossPercent on the primary device, none of the dependent devices are put into SDT.
Upon investigation I found that the is_primary_device property was removed from the primary device. And, with the test alert still active, when I poll now from one of the dependent devices, I see it get recreated briefly but then disappear again. Once the alert clears, I am able to poll now from a dependent device and see the is_primary_device property get recreated.
???
Parth_Dave
·8 years ago+ 1 for adding services support from me as well
Bryan_Fehl
·8 years agoThank you sir, that would help us out tremendously.
Steve_Francis
·8 years agoOK, I can extend this to support Services... I've got a few other things I'm in the middle of, so it may be a week or two...
Bryan_Fehl
·8 years agoThis is great! I'm testing this now in our environment.
One thing that would be useful for us is allowing us to suppress alerts when DNS resolution is failing to a particular device. For example, we have a tunnel between two locations, and several monitors on the other side of the DNS server. If DNS resolution breaks, all monitors using hostnames are going to break. It would be nice to only be alerted once for the DNS problem, not the individual devices that are having DNS problems.
Edit: Oh shoot i just noticed this doesn't support services currently. That is mostly what we'd use this for. Our use-case is that we have a large number of URL monitors that are monitoring from the location of users, to systems running the cloud. When we have a DNS problem, we get hundreds of alerts all at once for the same issue, which is obviously not ideal. We would definitely need this to support service monitors.
Steve_Francis
·8 years agoAS it's currently written, it doesn't support Services as either the dependent or primary. (It could be made to support that, with some extra scripting. Let me know if that's important.)
And yes, you can set the depends_on property at the group level (and then override on devices, if needed.)
Parth_Dave
·8 years agoThis is awesome. Do these datasources allow a Service to be a parent for bunch of dependent devices and vice versa?
Can we set the depends_on property at the group level?
Steve_Francis
·8 years agoSo this set of datasources doesn't directly know anything about connections.
It requires the user to set the depends_on property.
If A is in Alert, and B depends on A (via the property), then B and all its interfaces will be in SDT.
Don
·8 years agoGreat. Not sure if assumed, but if we put node A into SDT, then the connecting interfaces NOT on this device, but connected to, would also go into SDT?
Steve_Francis
·8 years agoYes - it puts the whole device into SDT - so all interfaces, etc.
Don
·8 years agoSafe to assume this stitched relationship would also trickle into putting a node into SDT and having their uplinks (if switches...) also inherit SDT from parent?
Ray_Scholl
·8 years agoThat was it - I have added both datasources (I did refresh this page). Thanks Steve!
Steve_Francis
·8 years agoThat looks like you are using the old locator code (as the new one is not v1.0.0).
Can you try with locator JZ62NH?
That should be what the above article shows -maybe there was some caching....
Ray_Scholl
·8 years agoNo, not so much (same error) - unless I need to logout/login
Steve_Francis
·8 years agoFixed -these are now importable.
(Note that the locators changed - I edited the article above to the current ones. There was a slight improvement to using the globally unique displayname as the host reference in the depends_on property - the above article also reflects that...)
Steve_Francis
·8 years agoHuh - thought I put that through the review already... Let me fix that today..
Ray_Scholl
·8 years agoThis will surely help a lot of customers, thank you for that. You cannot add this at the moment - the import throws an error - any idea when it will be available (or similar functionality)?
503 : This LogicModule is currently undergoing security review. It will be available for import only after our engineers have validated the scripted elements.
Steve_Francis
·8 years agoAgree - this has taken way too long to get into the product officially. (It is in the works, but as Mike said, is at least 6 months away. We're working on improving our processes and efficiencies, too...)
In the interim, these two datasources available from the registry with these locators can achieve dependencies on a device level. Feedback appreciated!
SDT_Dependent_Devices: locator 24KKNG
SDT_Assign_Primary_For_Dependencies: locator NFTHXG
Creating Device Dependencies
With these two datasources, LogicMonitor supports device dependencies in order to help reduce alert noise.
Dependent devices have a primary device. When the primary device reports a specific kind of alert (by default, a ping alert, but this is configurable), then the dependent devices are placed in scheduled downtime. This means that if the dependent devices report alerts, they will not be escalated.
Dependent devices will be placed in Scheduled Downtime for 30 minutes at a time. If the primary device is still in alert, the Scheduled Downtime will be refreshed for another 30 minutes, before the existing Scheduled Downtime period expires. Note: when the alerts clear on the primary device, the dependent devices will remain in Scheduled Downtime for the remainder of the existing 30 minute period - this is to allow circuits to re-establish, and alerts to clear, etc.
Configuring Device Dependencies
Ensure your account has the SDT_Dependent_Devices and SDT_Assign_Primary_For_Dependencies datasources. Import them from the registry using the above locators if necessary.
You will need a LogicMonitor API token for a user that has rights to manage the primary and dependent devices. Create two properties on the root level of your LogicMonitor account: logicmonitor.access.id and logicmonitor.access.key, and set their values to the API token’s ID and Key, respectively.
To create a dependency on device A, so that devices B and C will be automatically placed in scheduled downtime when device A is in alert:
Navigate to device A, and determine the device’s displayname as entered in LogicMonitor. Note: this is not the IP/DNS name, but the value of the name field when managing the device.
e.g. in the below screen shot, the relevant name is ESXi1 - Dell iDRAC8
Now simply navigate to devices B and C in LogicMonitor, and add the property depends_on to each device, and set it to the value of the displayName of device A.
That’s it.
Within 30 minutes of the first device set to have device A as a primary device, LogicMonitor will configure itself so that if device A has an alert on the ping datasource, it will place all dependent devices into scheduled downtime for 30 minutes, as described above. (Note: You can cause the reconfiguration to happen immediately if you run Poll Now for the SDT_Assign_Primary_For_Dependencies datasource on one of the dependent devices.)
Once the primary device is in an alert that matches the alert conditions (any Ping alert, by default), it will SDT the dependent devices. You will see a property created on the primary device: dependents_sdtd - that contains a list of the devices that were most recently placed in SDT by the dependency action. There will also be another property, dependents_sdt_until that contains the epoch time in which the last set SDT will expire. If the alert condition still exists 5 minutes before the expiration of the SDT, a new SDT will be created.
Note that devices that are primary for one set of devices can themselves be dependent on other devices. ( e.g. a remote server can be dependent on a brach office router, but that router may be dependent on a VPN router.)
If a dependent device has a depends_on property that is set to a device that does not exist, a warning alert will be raised on that dependent device. (Similarly, there will be warning if the authentication credentials are not set correctly.)
Optional - changing the alert conditions for the primary device to trigger dependencies
By default, primary devices will trigger SDT for dependent devices if the primary device is in any ping alert (either packet loss or latency) of any level. You can change the conditions that trigger the dependency action by setting the property primaryalert on the primary device.
This property can be set to any valid filter supported by the LogicMonitor REST API call that returns alerts for a device.
The property is appended to the API query filter=resourceTemplateName:
Thus the simple case is to simply set the property primaryalert to another datasource's Displayed As field (not name), to act on alerts about that datasource.
Setting property primaryalert to this value
will suppress dependent devices’ alerts when the primary has this alert:
HTTPS-
any alerts about the HTTPS- datasource.
HTTPS-,instanceName:HTTPS-443
alerts on the 443 instance of the HTTPS- datasource
HTTPS-,instanceName:HTTPS-443,dataPointName:CantConnect
alerts on the datapoint CantConnect, on the 443 instance of the HTTPS- datasource.
HTTPS-,instanceName:HTTPS-443,dataPointName:CantConnect,severity:4|3
also require that the alerts are of level Error (3) or Critical (4).
For details of alert fields that can be used in filtering, see https://www.logicmonitor.com/support/rest-api-developers-guide/alerts/about-the-alerts-resource/
Removing Dependencies
The dependency configuration will be automatically removed once there are no devices that have the depends_on property pointing at a primary device - but not until the primary device alerts next. (You can manually remove the properties is_primary_device, dependents_sdt_until and dependents_sdtd to immediately remove the dependency datasource).
Feedback appreciated.
mnagel
·8 years ago@Mosh I had not considered building myself, but as you say that, I think I could put together at least a rudimentary solution using the API. To be effective, however, it would need to either poll very frequently or be triggered by alerts (and this would still be leaky). Will have to mock something up as the current situation is unbearable for us, let alone our clients who receive alerts from the system...
Mosh
·8 years agoWhat features are being targeted for Q2 2018? Would be good to some idea so we know if it'll be worth waiting or to build something ourselves now.
mnagel
·8 years agoI 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
Mike_Suding
·8 years agoThanks for your feedback and use cases - keep'em coming. Dependencies is currently under active research with a release planned in Q3 of 2018.
Jesse_Benoit
·8 years agoIt is to read this is on roadmap. Thank you! LM is awesome!
Mosh
·9 years agoAgree with LJ, automating the discovery of relationships between groups and devices is less of a priority for me than being able to manually define the relationships. Automated relationship discovery is fine at the technical layer (device to device) but it won't discover the business level relationships between components, so it's far more important that we can define the business impacting relationships between objects.
jamiemurphyit
·9 years agoPlease Please give an update and roadmap around this. I really dont care if its automatic or manual work. I NEED to be able to set parent and child relationships on devices ASAP
LJ_Bryson
·9 years agoAnother aspect that is often missed: If the parent is checked every 60 seconds, and the child goes offline, check the parent-path prior to alerting on the child. I believe that Nagios works this way, but Zabbix does not (and it is a problem in Zabbix).
Also, with respect to multiple parent dependencies, this is primarily for alerting -- not for monitoring. In other words, if a router goes down, only alert on the router (not the 300 hosts behind it). But, still show the 300 hosts as offline/unavailable (perhaps gray, not red?).
Finally, device dependencies alone are not the end -- service dependencies are needed. ie:
if host X is not pingable, then don't alert on the 30 other checks (including web checks) that are running on that host -- perhaps bundle the dependent alerts in the same 1 email as "affected dependent services." Likewise, one MySQL goes down with 10 apache instances pointing at it for some web app -- alert on the DB, and include the list of other affected httpds in the same alert (with most critical first).
This would be even more powerful than Nagios.
LJ_Bryson
·9 years agoDependencies (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.
LJ_Bryson
·9 years agoPlease, need ETA. Thanks.
mnagel
·9 years agoAny update on an ETA on this? It is one of various missing features that drives my potential clients to alternate solutions and it is very annoying to get a storm of alarms when only one real thing is wrong.
Thanks,
Mark
Mosh
·9 years agoAs a long time user of Operations Center (formerly Managed Objects), this is the one thing I miss the most. I've yet to encounter another solution that had the object relationship capabilities of Manage Objects. Still, I don't need that level of sophistication at the moment, but any kind of dependency relationship between objects will go a long way to solving one of my biggest problems right now.
Annie_Dunham
·9 years agoThere 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.
KeithC
·9 years agoGlad to hear this is on the road map! This is a really important feature for us as well. With the amount of objects we're monitoring it's important we know whether a network device at a location is down, or the gateway/MPLS to the entire location is down and at a glance that's not obvious. Cleaner alerting on this is very important to us.
Would love an update to see if this has moved any closer on the road map since last year.
Miguel_DeCamps
·9 years agoIf 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.
jamiemurphyit
·10 years agoAgree with Clement. Nmap can help but also checking for CDP neighbours on devices or just set from gui.
A device can also have multiple parents. aka a core switch connected to two firewalls. if one goes down monitoring should not but both down = all hosts below affected.
At a minimum make this feature as a manually configurable feature ASAP with a longer term goal of automating it!
Clement_Law
·10 years agoThis is great news. From my part, I would like to see
Jeroen_Gouma
·10 years agoHi 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
Annie_Dunham
·10 years agoI'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!
Jeroen_Gouma
·10 years agoThis would be very welcome
SchuylerC
·10 years agoI would love to see this feature. As it is now one issue can create dozens of alerts and can make it difficult to troubleshoot.
Josh_Selinger
·10 years agoAlso looking for this feature.
Clement_Law
·10 years agoYou have no idea how restrictive not having this feature is. How can someone hope to properly monitor their systems when the monitor has no proper hierarchical dependencies?
Michael_Horwath
·10 years agoAs I used to tease before: Nagios can do this.. :)/emoticons/smile@2x.png 2x" title=":)" width="20">
Ryan_B
·10 years agoThis would be extremely valuable! If a server is not able to be pinged for instance, if it could be set to suppress all other alerts for the device until it became accessible would greatly reduce alert spam. Serversalive and others as mentioned have this capability. Is their an official feature request form that can be submitted to from customers?
Thanks.
L_Benton
·10 years agoThis is something that I miss from Solarwinds so I'd love to see this in LogicMonitor as well.
Bruce_Berger
·11 years agoI vote yes also
George_Bica
·11 years agoI upvote this,and suggest the same for web services.