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).Best Practices for Practitioners: Module Configuration
Overview LogicModules, or Modules, are fundamental building blocks used in LM Envision that enable comprehensive monitoring, data collection, and system configuration management across your devices in your IT stack. This guide consolidates best practices for configuring the different types of Modules, including DataSources, PropertySources, ConfigSources, EventSources, LogSources, TopologySources, and JobMonitors. Following these guidelines ensures optimal performance, maintainability, and effectiveness of your monitoring setup. Key Principles Maintain consistent device naming conventions across all Modules to ensure clarity and ease of management Implement precise AppliesTo scripting logic to target the correct resources and avoid unnecessary monitoring Provide comprehensive documentation in descriptions and technical notes to support future maintenance Configure appropriate collection intervals based on the criticality and nature of monitored data Implement proper access control through Resource Group level access control to maintain security and compliance Test thoroughly before deployment using built-in IDE testing capabilities Configuration Best Practices Naming and Organization Use descriptive, standardized naming patterns (e.g., Vendor_Product_Monitor for DataSources) Avoid spaces in unique identifier names to prevent potential system issues Create meaningful resource labels that clearly indicate the module's purpose Group related modules logically while maintaining the visibility of primary instrumentation Use proper capitalization and consistent formatting in all naming elements Documentation and Metadata Include clear, concise descriptions that explain what the module monitors Document all technical requirements and dependencies in technical notes Specify required credentials, permissions, or system configurations Maintain version notes when committing changes Include relevant links to vendor documentation or additional resources Configuration Management Set appropriate collection intervals based on data criticality and system impact Configure meaningful alert thresholds and transition intervals Implement precise AppliesTo scripting to target specific resources Use property substitution instead of hardcoded values where possible Maintain clear alert messages with actionable information or customize alert messaging with pertinent information Data Collection Validate data types and ranges to prevent spurious alerts Implement appropriate error handling and timeout settings Use standardized data collection methods based on the target system Configure proper encoding and parsing options for log collection Implement efficient filtering to reduce unnecessary data collection Access Control Assign appropriate Access Groups to control module visibility and management Maintain at least one Access Group per module Review and update access permissions regularly Consider role-based access requirements when configuring new modules Document access control decisions and requirements Testing and Validation Use built-in testing capabilities before deployment Verify resource targeting through AppliesTo testing Validate data collection scripts and filters Verify access control settings work as intended Use script testing tools to validate complex logic before deployment Test alert thresholds and notification configurations Verify access control settings work as intended Best Practices Checklist Initial Setup ✅ Choose the appropriate module type based on monitoring requirements ✅ Follow standardized naming conventions ✅ Configure meaningful resource labels ✅ Set appropriate Module group membership (or leave ungrouped if no grouping exists) ✅ Document purpose and requirements Configuration ✅ Set appropriate collection intervals ✅ Test and configure accurate AppliesTo criteria ✅ Set up proper access controls ✅ Configure data collection parameters ✅ Set up appropriate filters and thresholds Documentation ✅ Complete all required description fields ✅ Add detailed technical notes ✅ Document dependencies and requirements ✅ Include relevant examples and use cases ✅ Add version notes for changes Testing ✅ Test AppliesTo scripting to verify correct resource targeting ✅ Validate data collection ✅ Verify alert configurations ✅ Test access controls ✅ Validate filters and thresholds Maintenance ✅ Review and update regularly ✅ Monitor for performance impacts ✅ Update documentation as needed ✅ Verify access controls remain appropriate ✅ Maintain version history Conclusion Effective Module configuration is crucial for maintaining a robust monitoring environment. By following these best practices, organizations can ensure their LM Envision implementation remains scalable, maintainable, and effective. Regular review and updates of these configurations, combined with proper documentation and testing, will help maintain the health and efficiency of your monitoring system. Remember to adapt these practices to your specific needs while maintaining the core principles of clarity, efficiency, and security. Additional Resources DataSources Configuration PropertySource Configuration AppliesTo Function Configuration SNMP SysOID Map Configuration JobMonitor Configuration Examples of JobMonitor Monitoring ConfigSource Configuration TopologySource Configuration EventSource Configuration LogSource Overview Modules Management Access Groups for Modules
My Module Toolbox Pro-Tips
As a Customer Success Manager here at LM, I wanted to share a few key features found in our new Module Toolbox that have made keeping LogicModules up to date easier than ever! Search functionality Upon opening your Module Toolbox (found among your tabs under the Reports tab), you will notice there is a search bar in the top left. This will allow you to search for any specific modules instead of spending time combing through looking for the one you need! Multiple filters You can now filter modules you’re searching for by type (datasource, eventsource, configsource, etc.) as well as by customized, skipped updates, author, group, status and report! Bulk updating You now have the ability to update your modules in bulk (-given that you don’t have any customizations on the modules you have selected). This is going to save time when it comes to keeping your modules up to date, rather than having to update them one by one. If you have customized modules, simply select the filter for “customized” and select “no”. From there you can select all and update. ba-da-boom! Customization preservations This is one that so many of our customers have been asking for. When updating a customized module, again, select the filter for “customized” and select “yes”. From there you will click the update button (depicted as an up arrow inside a circle) on the module you’d like to update. Review any changes made to the module in the diff viewer, click final review and then you will see a “Preservations” option on the right hand side which allows you to preserve customizations made to that particular module. You can currently preserve settings for Active Discovery filters, AppliesTo, Collection Interval, Discovery Interval, Display Name, and Group. No more updating the module to only have to go back in and rewrite all your customizations! Happy updating! :)
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 in Updates 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.
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?Parity? 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.Finding VMware's most recent vulnerability
I woke up this morning to an email pointing me to this: https://www.vmware.com/security/advisories/VMSA-2021-0002.html My boss - Can LM tell us which ones need attention? We’d like to notify our customers proactively. Me - Sure! Oh wait, I only have version info for the ESX servers. I’ll have to build out something to grab the vCenter versions. So, I built a custom property source. AppliesTo: system.virtualization =~ "VMware ESX vcenter" && (vcsa.user || esx.user) && (vcsa.pass || esx.pass) Then the script looks like this: /******************************************************************************* * © 2023 Aqueduct Technologies Inc. * * External Resources: * - https://developer.vmware.com/apis/vsphere-automation/v7.0U1/appliance/rest/appliance/system/version/get/ * ******************************************************************************/ import groovy.json.JsonSlurper user = hostProps.get("vcsa.user")?: hostProps.get("esx.user") pass = hostProps.get("vcsa.pass")?: hostProps.get("esx.pass") host = hostProps.get("system.hostname") session_endpoint = "/rest/com/vmware/cis/session" //endpoint for establishing an ssl session vsphere_version_endpoint = "/rest/appliance/system/version" //endpoint for determining vsphere version jSlurp = new JsonSlurper() globalHeaders = [:] genSessionId()//get session ID for future API requests try{ def resp = httpRequest(vsphere_version_endpoint) if (!resp) {return 1} println("auto.vcenter.version=${resp.version}") } finally{deleteSessionId()} return 0 def genSessionId(){ String auth = "Basic " + "$user:$pass".getBytes().encodeBase64().toString() def headers = ["Authorization": (auth)] def resp = httpRequest(session_endpoint, headers, 'POST') globalHeaders.put('Cookie', "vmware-api-session-id=${resp as String}") } def deleteSessionId(){ httpRequest(session_endpoint, [:], 'DELETE') } def httpRequest(def endpoint, Map<String, String> headers = [:], def method = 'GET', String query = null){ URI _uri = new URI('https', null, host, 443, endpoint, query, null) def _session = _uri.toURL().openConnection() _session.setRequestMethod(method) (headers + globalHeaders).each { k, v -> _session.setRequestProperty(k, v) } def response = _session.getInputStream().getText() _session.disconnect() return (response) ? jSlurp.parseText(response).value : null } If you don’t have one under /Devices by Type, create a dynamic group for ESX hosts and another dynamic group for vCenter. We called ours “VMware Hosts” (AppliesTo system.virtualization =~ "VMware ESX host") and “VMware vCenters” (AppliesTo system.virtualization =~ "VMware ESX vcenter") respectively. Then create a Resource Inventory report where the Resource Group is “Devices by Type/VMware*”. Add the system.virtualization, auto.vcenter.version, and system.version properties and run it. Voila, you now know the version numbers of your ESX and vCenter resources and you can compare that to the versions in the VMware Advisory.
