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 ForumBest 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
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 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.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 page indicates that you cannot apply AutoProperties to cloud devices unless monitoring is enabled via a local Collector. Could this requirement be relaxed?
