Search the Community

Showing results for tags 'ConfigSource'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • LogicModule Exchange
    • LM Exchange
    • LM Staff Contributions
  • Product Announcements
    • LogicMonitor Notices
  • LogicMonitor Product Q&A
    • Feature Requests
    • Ask the Community
    • From the Front

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Found 9 results

  1. Our networking team would like to generate email alerts for network device configuration changes. I would like to see the option to add text in the config DifferenceTest alerts that actually shows old vs. new configs to see what changed in the email, especially for road warriors who don't have an option to immediately log into the device or LM to drill down and manually check to see what changed. For example, we use Meraki and in the Meraki portal, and below is an example email alert that shows the old and new values of the device configuration: DeviceName / 25 was changed by John Doe ( Old value: Allowed VLANs: all New value: Allowed VLANs: 123,456,789 This would be very beneficial for auditing, troubleshooting, and security response.
  2. A while back I published some very simple ConfigSources to monitor your collector .conf files: Here's an adaptation that writes the various collected configs to a dashboard, writing each of the config outputs to a text widget. Notes: THIS IS A PROOF OF CONCEPT. No warranty is given or implied (value of your investments may go down as well as up, check with your health professional before taking this medicine, etc). Please test before deploying! As with all data within LogicMonitor (or any system), be aware of access rights of users - in this case to whatever Dashboard(s) the config data will be presented on. Be sure to configure your Roles and Users such that only users who have legitimate need to see this data can access whatever Dashboard(s) you send it to. This uses the REST API v1 to verify the target dashboard exists or create it if it doesn't, and also to create / update the text widgets. It will therefore need an API token for an account with management permission for the relevant Dashboard(s), with ID and Key values set as device properties apiaccessid.key and apiaccesskey.key. All of the API interaction is contained with a groovy checkpoint, rather than within the config collection script, so this could very simply be copied into other ConfigSources. The same logic could be used in other LogicModules, such as to write non-numeric outputs of SQL queries or any data collection methods to dashboards. While this provides no history retention as written, it will show current / most recent values. Within the script you can define the desired Dashboard path, e.g. 'Collector Configs/Groovy Check' (default as presented here), Dashboard name (hostDisplayName is the default), widget name format (hostDisplayName: wildvalue) and other initial parameters such as widget colour scheme, description, etc. This is written for REST API v1. One day I may get around to updating it for v2, for greater efficiency, but today is not that day. Tomorrow is not looking likely either. Dashboard text widgets do have a maximum character limit (65,535 characters). I don't think I've seen a collector config near to or in excess of this, so I have no idea whether a larger config from another device would be truncated or whether the widget creation would fail. Other widgets on the dashboard are unaffected by this script creating and updating widgets; likewise later manual changes to widget size, colours, etc should be respected; updates should be to the text content of the widgets only, so the target dashboard could contain other data from the device. For example, it might look a bit like this: Known issues: On the first config collection for a multi-instance ConfigSource like this, and where the target dashboard does not already exist, only one widget will be created in the dashboard. This is because all instances collect more or less simultaneously, and each determines the dashboard is not initially present. Each, therefore, attempts to create the dashboard and as soon as the first instance does so, the others will fail as they cannot create a dashboard that (now) already exists. This could be coded around with a simple delay / re-check on failure, but I haven't had time, and the second config collection will create all expected widgets without issue. Additionally, if you create the dashboard first, this issue will not occur.
  3. This one's a little bit like my ConfigSource to compare a config to a static template file: It uses similar methodology, to compare the already-gathered 'running' and 'startup' instances of any existing ConfigSource via the LogicMonitor API. It doesn't gather any configs directly from the device. Example: The Cisco_IOS ConfigSource already gathers a 'running-config' and a 'startup-config' from relevant devices. This ConfigSource calls the LM API to pull the most recent retrievals of each of these, and compares one to the other. This ConfigSource can be extended to consider any ConfigSource that includes 'running' and 'startup' config instances, and/or could be cloned/edited to consider other instance pairs if the device type names them differently (e.g. 'default' vs 'running', 'original' vs 'custom', etc). The two configs are compared line-by-line and where lines differ, these are marked and alerted on. This ConfigSource demands the presence of the DataSources_List PropertySource, as it relies on a known list of LogicModules active on a device, as the AppliesTo is based on the presence of LogicModule names in the resultant auto.activedatasources device property: As it uses the LM API, this ConfigSource also demands an API token ID and Key pair, but you'll need those for the above PropertySource anyway. That pair must have the ability to read LM Config data. v1.2.0 is published with locator: GYNA3E
  4. Hi Guys, We just implemented LMConfig and I'm trying to run a report to see what devices do not have the IOS configuration successfully downloaded. We have some legacy equipment still not Configured for SSH and TACACS accounts. so I'm trying to get out of having to manually hunting through all our devices to determine what ones need SSH configured and what ones need the TACACS account added. Even just being able to pull a report on all devices and what ones have the ConfigSources - IOS Configs field would be a big help. See attached pic for a visual Cheers and Thanks in advance Joel
  5. Configuration backups in LogicMonitor is a great feature to help you be aware of changes being made ,store version history and restore your device configurations. Newer devices are can have subscriptions that pull the latest data from the manufacturer, such as malicious IP address lists. Encrypted information may be re-hashed for added security and these are expected behaviours - NOT a config change. So you need to ignore these changes, as they are not operational changes and you do not need to be woken at 3 in the morning to see that there are some newly added malicious Ip addresses. Is there a way to ignore these updates (often multiple in a day) and simply key on the first few lines where the config version is referenced ? #config-version=whateverversioninfo #conf_file_ver=177424565748364543 #buildno=somebuildno We need to alert on line 2 and ignore every other change. As you are no doubt aware you can edit your configsource to ignore certain lines with regex.So you can add an ignore change for lines that contain builldno for example. But stipulating every line except one would be a nightmare and you never know what the lines contain all the time. So flip it on its head. Make an ignore check, select ignore lines with this regular expression and use the expression !("#conf_file_ver=").Basically this means ignore every line that does not contain #conf_file_ver= You can see in my example above I have changed the file version and it is shows and is alerted on, but I have also changed the buildno and that is ignored, also added a newline which is ignored. David
  6. The addition of configuration backups in LogicMonitor has been a great feature for our support team and really helps streamline things. If you like to be aware of people making changes and retain version history is is wonderful, but we have an issue on some of the more modern devices. Many new devices are intelligent and have subscriptions that pull the latest IPS, AV, malicious IP address lists, etc. from the manufacturer. There is also a periodic re-hashing of encrypted information for added security and these are expected behaviors - NOT a config change. We developed our own config backup using SCP for the devices so no passwords are stored in LM either, but the key here is that a login event (human or automated) causes the config version to change. The suggestion I have is simple - there needs to be a way to ignore these updates (often multiple in a day) and simply key on the first few lines where the config version is referenced - #config-version=FWF60D-5.02-FW-build742-161129:opmode=0:vdom=0:user={redacted} #conf_file_ver=17742419038372504090 #buildno=0742 That conf_file_version (line 2 above) would be the trigger and ignoring everything else would be perfect. Thoughts welcome!
  7. Antony Hawkins

    Collector ConfigSource(s)

    A couple of choices of ConfigSource to monitor the .conf files of your collectors. Note these are two versions of the same thing - you do not need both. One explicitly monitors only the four key .conf files; agent.conf, sbproxy.conf, watchdog.conf, wrapper.conf. That's done via the Active Discover script simply printing those four known filenames as instances: 76PEZ2 (v1.2) The other version has a more involved Active Discovery that lists any .conf found in the Collector config folder, with the exception of 'persistent_task.conf' as this file is continually being updated. This has the advantage that it will catch any new or renamed .conf files we add in in future: K992D7 (v1.2) The collection script of each simply reprints the content of each .conf file and alerts on changes, with a couple of exclusions for expected changes. AppliesTo = hasCategory("collector") They are grouped to appear within the 'Collector' datasource group on the devices alongside the collector-specific datasources.
  8. Kerry DeVilbiss

    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 (previously posted to the Exchange but included here for sake of keeping everything together.) The datasource name is TeslaMotors_BatteryStatistics and has lmLocator DXLLKY. DataSource 'Climate Statistics' tracks inside and outside temperatures, as well as driver and passenger temperature settings. The datasource name is TeslaMotors_ClimateStatistics and has lmLocator YZRWXC. ConfigSource 'Car Configuration' collects textual configuration data, cleans it up and makes it easily readable (screenshot attached.) The configsource name is TeslaMotors_Configuration and has lmLocator GRY9AE. DataSource 'Location Data' tracks compass heading, latitude and longitude, and power. The datasource name is TeslaMotors_LocationData and has lmLocator AYWYWA. DataSource 'Odometer Reading' does exactly what you might expect. The datasource name is TeslaMotors_BatteryStatistics and has lmLocator HHJRDJ.
  9. How do we monitor our DataSources? One of our customers asked an interesting and challenging question. He would like to know how he can track and alert changes to his customised DataSources. Well, there was no straightforward way, not until recently. This is made possible with the recent release of the ConfigSource add-on module and the publishing of the dataSource REST API. At a high-level, we can create a Groovy script ConfigSource which makes a REST API call to export a targeted DataSource to XML format, store and check for changes to the XML in ConfigSource, then send an alert when there is a change. Creating the ConfigSource:- 1. Create REST API token 2. Create an embedded groovy script ConfigSource with the following information:- Name : DS_XML Display Name : DS_XML Applies To : This ConfigSource can be applied to any device Collect Every : Up to your company policy, minimum 1 hour Multi-instance? : Check this option Enable Active Discovery : Uncheck this option Collector Attributes : Select Embedded Groovy Script Groovy Script : [... Attached Below ...] Config Check : Select Any Change (Check For: option) 3. Save the ConfigSource import org.apache.http.HttpEntity import org.apache.http.client.methods.CloseableHttpResponse import org.apache.http.client.methods.HttpGet import org.apache.http.impl.client.CloseableHttpClient import org.apache.http.impl.client.HttpClients import org.apache.http.util.EntityUtils import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.binary.Hex; //define credentials and url def accessId =hostProps.get(""); def accessKey = hostProps.get("api.access.key"); def account =hostProps.get("api.account"); def resourcePath ="/setting/datasources/##WILDVALUE##"; def url = "https://" + account + "" + "/santaba/rest" + resourcePath + "?format=xml"; // get current time epoch = System.currentTimeMillis(); //calculate signature requestVars = "GET" + epoch + resourcePath; hmac = Mac.getInstance("HmacSHA256"); secret = new SecretKeySpec(accessKey.getBytes(), "HmacSHA256"); hmac.init(secret); hmac_signed = Hex.encodeHexString(hmac.doFinal(requestVars.getBytes())); signature = hmac_signed.bytes.encodeBase64(); // HTTP Get CloseableHttpClient httpclient = HttpClients.createDefault(); httpGet = new HttpGet(url); httpGet.addHeader("Authorization" , "LMv1 " + accessId + ":" + signature + ":" + epoch); response = httpclient.execute(httpGet); responseBody = EntityUtils.toString(response.getEntity()); code = response.getStatusLine().getStatusCode(); println responseBody httpclient.close(); 4. Go to the device where the ConfigSource is applied to, define the following device properties :- : < API Token Access Id > api.access.key : < API Token Access Key > api.account : < LM Account > Adding ConfigSource Instances 1. Identify the DataSource id. You can find it in the UI by looking at the URL of the DataSource definition 2. Add ConfigSource instances by selecting 'Add Monitored Instance' from the Manage Dropdown next to the manage button for the device Name : < DataSource Name > Wildcard value : < DataSource Id > DataSource : DS_XML 3. Repeat above step 1 and 2 to add more datasource instances. Point to Note: 1. To execute a ConfigSource, you will need a minimum collector version of 22.110 2. One Datasource Id per instance 3. Differences in DataSource are viewed in XML format 4. Previous DataSource version can be restored by downloading and importing the previously compared XML from the ConfigSource history 5. Thanks and credits to David Lee (Our Jedi Master) for enhancing the original concept to a more user-friendly multi-instances ConfigSource. Screenshots of the ConfigSource result: