Locked
Discussion interactions are currently paused.
Remove Port Check from Active Discovery - SQL Queries
This was borne out of a support ticket. Request #14601
I was told by the Chat Support to post it here to get more attention.
Sorry for the long read.
The Logicmonitor datasource system has been designed to be extremely flexible and versatile, allowing numerous system variables and custom variables to be used within connection strings and protocol message bodies. This gives customers the ability to monitor and correlate data across multiple hosts within their network environment to an unprecedented degree. In fact, we already use this ability today to show data collected from one system in the context of another system. The only minor issue we are having on our current and future datasources (for which we are requesting a design change) is to make active discovery query work for this situation, by disabling the TCP port check at the beginning. We understand why this was coded into the active discovery engine, and request it be modified to port test the server in the “URL†field, rather than the target host. If that’s too difficult, I request the ability to deactivate or ignore the port test with a checkbox or something.
I believe the modification I suggested above is feasible, easily implemented, and in fact makes more sense than the current design of the active discovery port validation. I understand it’s been stated that the port test is “by designâ€, but frankly I still consider it a bug that it tests the target host even though it lets you specify the URL field which can contain any server. The AD query should have the exact same freedom and functionality in the URL field as the normal datasource query. Please escalate this to the development team management. Also, please recommend any workarounds for this issue, as we have numerous database queries we want to build around this same concept.
In response to the statement that our use case “doesn’t make senseâ€, here are some other very common examples where collecting data from one system and showing it in the context of another does in fact make sense. I contend that this was in fact an intended and supported methodology within logicmonitor.
1. Virtual Hosts and Guests - Virtual Host servers often have a great number of virtual machines on them, for which many statistics are gathered within the Virtual Host management software (for example, VMware\'s vsphere). These hosts can be queried using an API, SNMP, WMI, or custom scripts, which can return a wealth of valuable performance information relating to a particular \'\'Virtual Guest\'\', typically using the guest hostname as a variable in the query. Obviously in this situation, there would be great value in querying one host (the virtual host) for information, and displaying that information in the context of another host (the virtual guest) within Logicmonitor.
2. Network Switchports - Servers are typically connected to one or more network switchports. It would be valuable to show the statistics and status for the switchport(s) that a host is connected to, under the host node itself. With Logicmonitor\'s unique datasource and variable system, a custom datasource could be created and applied to all servers, with an active discovery policy that uses SNMP to query a related switch\'s interface descriptions, or even arp and mac address tables, to identify the switchport for each server dynamically. Then of course, all the statistics for switchports related to a given server could appear under the server node in LogicMonitor.
3. Our Current Case - Many enterprise technology environments feature a database server which contains statistics and information about other hosts in the environment. For example, virtually all Oracle based application platforms such as SAP and JD Edwards, feature a scheduling system where the information about scheduled jobs across all servers in the environment is contained in the database server (or cluster). SQL queries work great in Logicmonitor to pull such scheduler data out of the database and graph them. However, in most cases, it\'s not desirable to put the graph of a given SQL query result under the SQL server itself, which would result in hundreds of graphs appearing under one Datasource, and then users would have to find the graph for the server they are looking for. Instead, it\'s much more desirable to have a query be applied to the non-database hosts in logicmonitor, and enter the database server hostname as a variable in the connection string (as we did in our datasource for which this ticket was opened).
