Interface properties on Dashboard tables?
Is it just me or is it just not possible to add interface properties to the table widgets? I was really excited hearing that we could now get properties listed on a table on a dashboard, but when I tried to do so, it seems that that didn't include instance properties. I've also noticed I can't select interface properties in reports either. I know I can go to the resource directly and look at the list but I don't understand why there would be a limitation on referencing these properties on the dashboard (or in a report).
Access to Group or Device properties from a text widget
I’m looking for a way to display custom properties from an arbitrary group. We have a dashboard that shows widgets from a specific client group using the group/device pulldown text widget built by @Kevin Ford :Dynamic Dashboards | Community (logicmonitor.com). I’m trying to figure out how to get to custom properties set at the group to display info about that particular client for our staff to have easy reference to. Something like ##defaultResourceGroup##/##example.property## We have our client’s groups tagged with specific contact and support links (KB, Azure Portal, etc...) that would be useful to have direct access to.
SNMP Trap Credentials on Resource Properties Enhancement
HelloLM Community! Just wanted to highlight this enhancement thathas beenreleased recentlyin EA Collector 34.100 to support the use of SNMP trap credentialson resource properties. When using this collector version or newer, you can add snmptrap.* properties on resource/group level for the collector to decryptthe trap messages receivedfrom monitored devices. The credentials are used in the following order: Collector first checks for the set of credential snmptrap.* in the host properties. If the snmptrap.* credentials are not defined, it looks for the set of snmp.* in the host properties. If sets for both snmptrap.* and snmp.* properties are not defined, it looks for the set eventcollector.snmptrap.* present in the agent.conf setting. More details can be found in the below articles in our documentation: SNMP Trap Monitoring:https://www.logicmonitor.com/support/logicmodules/eventsources/types-of-events/snmp-trap-monitoring EA Collector 34.100 Release Notes:https://www.logicmonitor.com/release-notes/ea-collector-34-100
PSA: LM wipes good known properties when unknown results occur
I have recently found that due to the excellent programming skills in the dev team that properties that have previously been autodiscovered can be wiped out when ephemeral issues produce unknown (no data) results. A good example is system.ips -- if the data has been scanned properly in the past and a blip occurs with no data, the previous values get overwritten with just the configured IP of the device. That leads to various fun side effects like NetFlow data not being matched to the device. To make things worse, the “no data” result does not set an internal flag to run a new AD scan earlier and you have to wait up to 24 hours for a regularly scheduled scan. I created a bug ticket requesting they set that flag and run a new scan as soon as possible, but was basically told to pound sand. My workaround was to use an undocumented API endpoint to trigger on specified devices so I stop losing NetFlow data and I scheduled it hourly. The “solution” I was given was to add a netflow property to hardcode the needed IP address for each device -- works, but it is a brittle fix and leads to undesirable manual property management. Beyond that, this issue affects more than NetFlow, that was just the problem that lead me to realize what was happening. Other properties routinely get messed up that could affect processing. This class of problem (replacing good data with unknown data) frequently occurs in modules as well -- for example, a lot of the Powershell configsource modules lack sufficient error checking and unknown results replace previously known good results, leading to change thrashing. Or they often forget to sort/normalize output leading to similar effects. The good news on those is they usually (eventually) listen to me. Anyone who wants to use my workaround can use this script (or at least the central logic if you prefer something other than Perl). I still lose data, but the window is smaller. https://github.com/willingminds/lmapi-scripts/blob/master/lm-actionimplement better data serialization for active discovery results
A few months ago after being told that SNMP_Network_Interfaces was the new preferred method for network interface data collection (despite it excluding SVI interfaces and using weird backward naming for the property to include all interfaces -- interface.filtering = true), we moved ahead with implementation. We found soon after that the module was corrupting interface descriptions, and a ticket raised with support resulted in the “too bad, sucks to be you” sort of response I often receive. The corruption involves stripping all hash signs from interface descriptions. This may sound harmless, but we have for years told our clients to prepend a # to an interface description to exclude it from alerting, which our automation detects and handles. The reason this happens is because the folks who came up with LM thought it would be a cool idea to use # as a field separator and this was embraced and extended by later developers. There was a solution we recommended (that was rejected) -- specify a transform string so the # becomes something else known we can match without breaking monitoring for thousands of interfaces. My request here is to work out a method to transition from the current field separator mechanism to an actual data serialization method like JSON.heads up - property corruption due to unknown results
I wanted to share this with everyone since it bit me recently. Sometimes LM will reset the value of properties like system.ips to just the single IP associated with the resource if something disrupts access to SNMP even briefly. The problem with this is it can impact other features, like Netflow binding. I am still battling this out with support but in the meantime I wrote a script to trigger AD for specified devices (had to use an undocumented endpoint) and I schedule that hourly to limit the damage in case it happens (normally AD is triggered once per day unless specific changes occur). My change logs show system.ips resetting fairly often, so the script is definitely helping. I explained to support that thwacking data due to an unknown result is a bug and no property should be changed due to that situation, but I imagine this bug will be hard to unwind. I also recommended a partial fix where AD could be triggered by a “host up” event to limit the damage, but that is a hack. Avoiding data corruption in the first place is the right fix. FWIW, the main loop of my script is below (it is in an ancient language, but the logic should be clear :)). DEVICE: for my $d (@{$devices}) { if ($DEVICES{lc $d->{displayName}}) { if ($ACTION eq "scheduleAutoDiscovery") { verbose 1, "scheduling AD for $d->{displayName}\n"; if (not $lmapi->post(path => "/device/devices/$d->{id}/scheduleAutoDiscovery")) { warn "ERROR: $ACTION failed\n"; } } else { die "ERROR: unsupported action: $ACTION\n"; } } }
Dynamic Group Custom Query Examples
Hello, so I was wondering if it was possible to create a Dynamic Device Group based on if box(es) wererunning a particular windows service ("ServiceNow"). I was looking at the Dynamic Device Group help and it only had a few examples for the custom query. Is there a full, comprehensive list of what options are available?Example the "hascategory()" function/test is listed where exactly in the help? And back to my original request can a Dynamic Device Group, group the machines that are running a particular Windows Service? I couldn't figure this out so I just went with a new Property Source definition and cloned and existing one that looked at all Windows Services on a box and tested if each one contained "ServiceNow" and then added the Category "ServiceNow" to the host. Then my DDG groups all these boxes based on "hasCategory("ServiceNowMID")" The Property Source script cloned/used: import com.santaba.agent.groovyapi.win32.WMI; //================================== def host = hostProps.get("system.hostname"); // get a list of running services def service_list = WMI.queryAll(host, "select * from win32_service"); def datacoreServices = service_list.findAll { service -> service["DISPLAYNAME"].contains("ServiceNow MID") } // Did we find any ServiceNow MID Services? if (datacoreServices.size() > 0) { println "system.categories=ServiceNowMID"; } return(0); //=== END ==== But if there is a more efficient way to do this please let me know. I think querying all the services an all isWindows() boxes is pretty expensive in terms of processing. What is a better wmi query to check for specifically a particular Windows Service that contains "xxxx" Thank you,