Best Practices for Practitioners: Modules Installation and Collection
Overview LogicMonitor LogicModules are powerful templates that define how resources in your IT stack are monitored. By providing a centralized library of monitoring capabilities, these modules enable organizations to efficiently collect, alert on, and configure data from various resources regardless of location, continuously expanding monitoring capabilities through regular updates and community contributions. Key Principles Modules offer extensive customization options, allowing organizations to tailor monitoring to their specific infrastructure and requirements. The Module Toolbox provides a single, organized interface for managing and tracking module installations, updates, and configurations. Available or Optional Community-contributed modules undergo rigorous security reviews to ensure they do not compromise system integrity. Regular module updates and the ability to modify or create custom modules support evolving monitoring needs. Installation of Modules Pre-Installation Planning Environment Assessment: Review your monitoring requirements and infrastructure needs Identify dependencies between modules and packages Verify system requirements and compatibility Permission Verification: Ensure users have the required permissions: "View" and "Manage" rights for Exchange "View" and "Manage" rights for My Module Toolbox Validate Access Group assignments if applicable Installation Process Single Module Installation: Navigate to Modules > Exchange Use search and filtering to locate desired modules Review module details and documentation Select "Install" directly from the Modules table or details panel Verify successful installation in My Module Toolbox Package Installation: Evaluate all modules within the package Choose between full package or selective module installation For selective installation: Open package details panel Select specific modules needed Install modules individually Conflict Resolution: Address naming conflicts when detected Carefully consider before forcing installation over existing modules Document any forced installations for future reference Post-Installation Steps Validation: Verify modules appear in My Module Toolbox Check module status indicators Test module functionality in your environment Documentation: Record installed modules and versions Document any custom configurations Note any skipped updates or modifications Core Best Practices and Recommended Strategies Module Management Regular Updates: Consistently check for and apply module updates to ensure you have the latest monitoring capabilities and security patches. Verify changes prior to updating modules to ensure no potential loss of historic data when making changes to AppliesTo, datapoints, or active discovery Review skipped updates periodically to ensure you're not missing critical improvements. Selective Installation: Install only the modules relevant to your infrastructure to minimize complexity. When installing packages, choose specific modules that align with your monitoring requirements. Version Control: Maintain a clear record of module versions and changes. Use version notes and commit messages to document modifications. Customization and Development Custom Module Creation: Develop custom modules for unique monitoring needs, focusing initially on PropertySource, AppliesTo Function, or SNMP SysOID Maps. Ensure custom modules are well-documented and follow security best practices. Careful Customization: When modifying existing modules, understand that changes will mark the module as "Customized". Keep track of customizations to facilitate future updates and troubleshooting. Security and Access Management Access Control: Utilize Access Groups to manage module visibility and permissions. Assign roles with appropriate permissions for module management. Community Module Evaluation: Thoroughly review community-contributed modules before installation. Rely on modules with "Official" support when possible. Performance and Optimization Filtering and Organization: Utilize module filtering capabilities to efficiently manage large module collections. Create and save custom views for quick access to relevant modules. Module Usage Monitoring: Regularly review module use status to identify and remove unused or redundant modules. Optimize your module toolbox for performance and clarity. Best Practices Checklist ✅ Review module updates monthly ✅ Install only necessary modules ✅ Document all module customizations ✅ Perform security reviews of community modules ✅ Utilize Access Groups for permission management ✅ Create saved views for efficient module management ✅ Periodically clean up unused modules ✅ Maintain a consistent naming convention for custom modules ✅ Keep track of module version histories ✅ Validate module compatibility with your infrastructure Conclusion Effectively managing LogicMonitor Modules requires a strategic approach that balances flexibility, security, and performance. By following these best practices, organizations can create a robust, efficient monitoring environment that adapts to changing infrastructure needs while maintaining system integrity and performance. Additional Resources Modules Overview Modules Installation Custom Module Creation Tokens Available in LogicModule Alert Messages Deprecated LogicModules Community LM Exchange/Module Forum
New VMware modules dropped
Did anybody else notice the ~44 new and ~5 updated modules around VMware dropping in the last hour or so? Does anyone know how to implement these new modules? Since there was talk of making the instances into resources I don’t want to just bring them in without knowing how it’s going to mess with my device list (which is tightly bound to billing for us).
When Will My Module Toolbox Work Properly?
So we recently received a banner in one of our portals stating that in a future release the LogicModules section will no longer be available. This concerns us greatly as I noticed something after I just had a new portal spun up. I logged in, went to the Modules section in the new UI and told it to show me all of our outdated items. Nothing shows up. I then went into the Exchange, told it to show me all of the Installed and Update Available. Nothing shows. I also checked for anything Official that isn’t installed, and nothing shows up.So I naturally go the legacy route, load up DataSources, and tell it to look at the repository. Lo and behold, I have 85 DataSources. Some are new, some are updated. We were told at one point that the Modules/Toolbox/Exchange area look at a different repository, so we gave the benefit of the doubt and checked one of the new modules and an updated module, and both were 3 months old and not showing up in the new UI. Stu brought up some concerns as well inUpdates to modules showing in repo but not modules toolbox | Community (logicmonitor.com), but I didn’t want to necro post with a slightly different issue.Typo in several modules fixed
FYI, LM pushed out a bunch of modules containing a typo in one of the tokens in the alert message. ##DESCRIPTION## isn’t a valid token and ##DSIDESCRIPTION## should be used instead. This has been corrected in the following modules: Aruba_ClearPass_AccessAuthorization Aruba_ClearPass_DiskMemoryUsage Aruba_ClearPass_NetworkTraffic Aruba_ClearPass_PolicyServer Aruba_ClearPass_ProtocolStats AWS_ElasticTranscoder CiscoSLA_jitter- Logstash_ConfigReload_Stats NetApp_7mode_SnapshotScheduler OpenGear SerialPort VMware_ESXi_HardwareHealthSensor VMware_vCenterAppliance_Backup VMware_VCSA_BackupInstances Whois_TTL_ExpiryParity? What is that?
So, this is happening at some point. Today, given the release of several updates to modules, I decided to abandon my really good workflow and the coolest tool LM never built in favor of the modules toolbox. Sigh. There’s no option that I can find to “show associated devices”, which in the old UI showed a list of devices with their associated instances. You could even filter to only show those devices that had instances. There was a CSV download option. It was great because you could tell the difference between a module applying to 500 devices that have instances and applying to 500 devices that didn’t have any instances. It’s the difference between impact and no impact. Later, I needed to clone at propertysource. The existing one was fine, just needed to add some stuff for a different purpose. Guess what there is no button for in the module toolbox? Cloning a module. On the plus side, there is now a “use status” column for display and filtering. That helps a ton. This isn’t a parity issue, but there’s a new “deprecated” indicator for those modules that have been deprecated. You know what you can’t find without going somewhere else? Which module replaces it. I really, really hope the old ship doesn’t get scuttled before the new ship can even float.AutoProperties for Cloud resources
I need to be able to create AutoProperties on Cloud Resources, which don’t require interacting with the Cloud Resource itself. This pageindicates that you cannot apply AutoProperties to cloud devices unless monitoring is enabled via a local Collector. Could this requirement be relaxed?Updates to modules showing in repo but not modules toolbox
Why would this be? There were 5 updates to aws_billing_* modules today, but they only show up when i use the traditional repo update option. No combination of filters could show those in the module toolbox, except by clearing all filters and just searching by name. Even then, once found by name, they showed already up to date. In addition, when trying to make a filter to show them, i was frustrated (once again) that the filters are filtering by values we cannot see: The “Customized” field isn’t displayable on the table at all, or if it is, it’s displayed as an icon in the status column. However, the dropdown for the filter is not an icon, it’s text. The status column shows an icon, but the filter values are text. Which icon corresponds to which text? For these 5 modules, the “Support” column was blank, even though these modules come from LM so should be “official”? How can you filter by “Support” == null? It’s all very Duolingo: make mistakes and wander your way through until you figure it out?Alerts coming from seemingly one DS when they actually come from multiple
I’ve already opened a case with support to see if anyone knows anything on their side, but figured I’d ask here/make others aware: When looking at some of my alerts this morning, I noticed that when Ifiltered by "LogicModule == VMWare VM Snapshots", some alerts were from datapoints called"AgeInHours" and some were from datapoints called "age_hours". I wondered what the difference was between these two datapoints and why one DS would have two different datapoints (with alert generating thresholds) with names so similar. Turns out even though the alert page shows all these alerts coming from the "VMware VM Snapshots" DS, they are in fact coming from multiple DataSources: VMware_vCenter_VMSnapshots and VMware_vSphere_VMsnapshots. Those two DSs happen to share the same display name. I get why they do, but filtering by display name (which isn't guaranteed to be unique) isn't always desirable. I get why it could be handy, but the alerts page (and header graph) give a false impression that these belong to a single logicmodule, when in fact they don't. This will be a big problem when I'm trying to tune thresholds for these. I'll tune the thresholds, but some of the alerts will be unchanged, despite me thinking I've modified the thresholds. If anyone knows: How can I filter for just one LogicModule or the other without including alerts from both (without explicitly defining a datapoint filter)? How can I make the header graph show how many are from each DS?
