Common ConfigSource Documentation
Hello LogicMonitor community, I wanted to drop this here as it’s been something in the works for a long time. As I am sure many of your are all awareour development team has been working on and has actually released a new set of ConfigSources called “Common Configs”. These have been released into our core repository since late 2021 with support for more manufacturers and more features being added into these LogicModules throughout the last 2 years. The time has come that we have been able to get a support document around these Common Configs released with the requirements for them, optional parameters you can add to help them be successful, and thelist of all currently released modules related to this suite. https://www.logicmonitor.com/support/common-config-monitoring
Need help on PaloAlto_FW_RunningConfigXML API configsource
Currently, the sole option is to collect/view the configuration xml when a change occurs. So,IsthereawayinLMtogenerateareportusingthePaloAlto_FW_RunningConfigXMLAPIconfigsource? or Is it possible to collect the configuration backup at any specific time interval? Thanks in advance :)
Finding Cisco IOS XE CVE-2023-20198 With ConfigSources
On October 16, 2023, Cisco published a vulnerability that affects IOS XE machines running the built-in web server:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z This is tracked ashttps://nvd.nist.gov/vuln/detail/CVE-2023-20198 By adding a simple Config Check to an existing Cisco IOS ConfigSource, LogicMonitor can help people quickly identify which resources have the web server enabled. Here is an example: Name: Cisco-CSCwh87343-Check Check type: "Use Groovy Script" Groovy script: /* The built-in string variable 'config' contains the entire contents of the configuration file. The following example will trigger an alert when the configuration file contains the string "blue". if (config.contains("blue")) { return 1; } else { return 0; } */ if (config.contains("ip http")) { return 1; } else { return 0; } Then trigger this type of alert: Warning Description: "Search for presence of Cisco CSCwh87343 vulnerability" Caveats: -This will apply to all devices where the ConfigSource is used, even though all devices may not be affected by the vulnerability -This assumes usage of ConfigSources and specifically the Cisco_iOS ConfigSource Thanks to Todd Ritter for finding this CVE and Creating the ConfigSource
Tesla Motors LogicModule Suite
I previously published a datasource for Tesla Motors Battery Statistics - which presents compelling vehicle battery and charging information that is fetched from the Tesla REST API. To complement those efforts, I've written a few other Tesla Motors LogicModules that return a variety of different, but still interesting, datapoints - including a ConfigSource that displays configuration information about the vehicle itself (are the doors locked? Is the sunroof open?) The following is a list of all the Tesla Motors LogicModules now available (see the above-linked post for additional info on how this all works.) DataSource 'Battery Statistics' tracks battery and charger performance and health metrics Tesla Motors Battery Statisticspreviously posted to the Exchange but included here for sake of keeping everything together.) The datasource name isTeslaMotors_BatteryStatisticsand has lmLocatorDXLLKY. DataSource 'Climate Statistics' tracks inside and outside temperatures, as well as driver and passenger temperature settings. The datasource name isTeslaMotors_ClimateStatisticsand has lmLocatorYZRWXC. ConfigSource 'Car Configuration' collects textual configuration data, cleans it up and makes it easily readable (screenshot attached.) The configsource name isTeslaMotors_Configurationand has lmLocatorGRY9AE. DataSource 'Location Data' tracks compass heading, latitude and longitude, and power. The datasource name isTeslaMotors_LocationDataand has lmLocatorAYWYWA. DataSource 'Odometer Reading' does exactly what you might expect. The datasource name isTeslaMotors_BatteryStatisticsand has lmLocatorHHJRDWorkarounds for long ConfigSources?
I have a couple of devices where the Configis so long that the FortiOS Config shows “...Data Truncated...” in both the UI and the download. I looked in the code and so I know the limit and see that the ConfigSource is checking for a specific max size and displaying as much as it can (carving out room for the truncation message). Anyway, I’m assuming this is some UI limit, or else LM’s code would have just printed sections back to back, until done. So I’m wondering if anyone in the community has had the issue, and if anyone has a workaround? Thanks!Synthetics - add ability to update existing checks and download .side file via configsource
With synthetic transactions, currently you need to delete/recreate a check if we want to update it or change the username/password used for authentication. This causes loss of historical data and is difficult to manage. There are 2 things I would like to request that would make it easier for us to manage synthetic transactions. add ability to update an existing check. This includes updating the .side file or updating the authentication Add ability to download the .side file for an existing check via a companion Configsource. This would make it easier to resolve issues with a check and tweak it without impacting historical data.
Tips or Tweaks for controlling when a daily ConfigSource runs?
I have a config source, that really under the hood is doing some other task, a coding task, and it used to conveniently run every day at 22:47 or something like that, but because of reasons, now it runs at 10:05 every morning. This is some ancient script someone else wrote in python and it runs on a collector. I’ll probably convert it to be groovy, and have it run hourly, but only act when the hour digit on the time is 22 or something wacky. But short of that, it did have me wonder, are there any tricky ways to change when a daily config source runs? Because from what I can tell, they run at the time they were made, or I guess at the last time the collector went down because of a domain password problem :) *cough*. I could just try a meaningless edit on the ConfigSource and see if that does it. I dont think bouncing the collector service will do it because on rare occasion the service restarts at a time other than its normal time and that doesnt change CS run times. Just wondering if anyone has any tips or tricks? I’ll probably just rewrite this to run hourly but act only on a specific hour of the day. But just fishing for ideas. I really wish we could schedule ConfigSources like we can reports. Thanks!Common Config Sources vs Legacy LM Config Sources
We use LM Config and have since day 1. I’m wondering if any of you have migrated off the legacy LM Config sources and onto the “Common Config” method? What sort of gaps in data did you have? I’m sort of stuck on the idea of having to dump one for another or potentially have some that work only with legacy vs Common methods? Seems like it could be hard to manage. Do you have any challenges today using the new way?