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
Modules for Citrix Cloud/DaaS/VAD monitoring
Hi, here are some modules to monitor Citrix DaaS/VAD via the Citrix Monitor API. These might be helpful with mixture of DaaS and on-prem VAD environments as the same modules can be used for both. Setup details are in the module notes, see the CitrixDaaS_Token notes for the Citrix Cloud API setup. I have made the .xml export of each module available on Github, they can be downloaded from here: https://github.com/chrisred/logicmonitor-citrixdaas The modules are: CitrixDaaS_ApplicationUsage.xml CitrixDaaS_ConnectionFailures.xml CitrixDaaS_DeliveryGroups.xml CitrixDaaS_LogonPerformace.xml CitrixDaaS_Machines.xml CitrixDaaS_Token.xml I'll try to keep an eye on this post for any questions.Modules for Zerto monitoring
Hi, here are some modules to monitor Zerto via their API. Appliances (ZVM/ZCM) and the Zerto Analytics portal are supported. I have made the .xml export of each module available on Github, they can be downloaded from here: https://github.com/chrisred/logicmonitor-zerto The modules are: ZertoAnalytics_Alerts.xml ZertoAnalytics_Datastores.xml ZertoAnalytics_Sites.xml ZertoAnalytics_Token.xml ZertoAnalytics_VPGs.xml ZertoAppliance_Alerts.xml ZertoAppliance_Datastores.xml ZertoAppliance_PeerSites.xml ZertoAppliance_Token.xml ZertoAppliance_VPGs.xml ZertoAppliance_VRAs.xml I'll try to keep an eye on this post for any questions.
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.SSL_Certificates DS v1.7 discovery issues
I pulled this version of the DS into my sandbox and tested on a few devices. The discovery task fails catastrophically. Can anyone else confirm? At any rate, be careful when LM changes something so fundamental as the discovery script is such a radical way. I’m in favor of the change (pulling props from the certificate instead of generic labels), but sometimes bad updates get published.April LM Community Contest. Who can build the best pollen/allergen monitoring DS?
April 2023 Code Champ Contest The goal is to create a reliable and accurate module that can help individuals with allergies avoid exposure to high levels of pollen and allergens and manage their symptoms more effectively. The winner will be determined by the Most Likes, so whether you are participating or not, be sure to 👍🏻 your favorite post! 🏅🏅🏅 Prizes: 🏅🏅🏅 Choice of LM Community T-shirt or Hat and a Code Champ Badge 🏆 for your profile! (LM employees may participate however the winner will be chosen from non-employees) 
Module Update Differences Report
I mentioned on the webinar today that I’d post an example output from my diff script. I’m not going to attach it here, so I’ll link to it instead. It’s an HTML page and it’s an older version of the script output, but opening it in your browser (use incognito if you’re worried) will show the list of modules whether they’re UpdatedNotInUse, UpdatedInUse, or New. Clicking on the blocks under a module (red=there’s a difference, green=there’s no difference) will show the existing vs. new versions. To generate this report, all I need is a RO set of credentials with view access to modules (I think). I use this as my checklist of updates to address. I have the history and existing definition on there (Old JSON) because I like to know if my version is out of date because LM changed an LM setting or if they changed something I had customized. And the old JSON is on there in case I need to revert (which I haven’t had to yet).
