Making the Most of LM Collectors: March Product Power Hour Recap
Overview March’s Product Power Hour zoomed in on one of the most critical components of the LM platform: the Collector. This session was all about helping you harness the full potential of LM Collectors—from deployment tips to tuning best practices. Our product experts walked through how to scale monitoring, improve data collection, and boost reliability across complex environments. With hands-on guidance, live demos, and direct answers to your questions, this session was a must-watch for any practitioner looking to level up their collector game. Key Highlights ⭐ Collector Best Practices: Practical guidance on sizing, scaling, and redundancy planning to optimize performance and ensure data continuity. ⭐ Auto-Balancing & Failover: How to configure Collectors for high availability using Auto-Balancing and Collector Groups. ⭐ Troubleshooting Tools: Demo of new collector diagnostics and log features to help quickly isolate and resolve issues. ⭐ Collector Configuration Management: Centralized tools for easier updates and streamlined deployments at scale. Q&A Q: How many devices can a Collector handle? A: Depends on specs and polling intervals—monitor CPU, memory, and poll duration for optimization. Q: Best practice for Collector failover? A: Use Collector Groups and enable Auto-Balancing for seamless failover. Q: Are there plans to enhance Collector management? A: Yes! Improvements are coming to simplify deployment and updates at scale. Q: Can we get alerts on Collector health? A: You bet. Alert on collector status, queue depth, and failures to stay ahead of issues. Customer Call-outs ⭐ “This makes managing distributed environments so much easier.” ⭐ “Collector Group auto-balancing was a game changer for us.” ⭐ “Loving the detailed diagnostics—helps our ops team move fast.” What’s Next 🚀 1H Launch Webinar April 3 - Level Up Your IT Universe Get a front-row seat to LogicMonitor’s biggest innovations of the first half of the year. This session spotlights AI-powered observability, enhanced workflows, and powerful platform upgrades. ⚡Product Power Hour April 24 – 1H Launch + Logs Leveled Up! Dive into the latest updates across Logs, AI, and LM’s observability suite in addition to fast-paced demos and real-world use cases in this log-focused edition of Product Power Hour. 🌍 Elevate Community Conferences Our flagship in-person event series is back! Connect with peers, attend expert-led sessions, and get hands-on product experience. Elevate 2025 will showcase the latest innovations in AI-powered observability, empowering enterprises to optimize their modern data centers. Dallas – April 30 Sydney – May 29 London – June 25 Pre-Elevate LM Training | LIVE Already attending Elevate? Join us in Dallas and London a day early to earn your first Logs Badge through immersive, instructor-led training and hands-on labs. Perfect for new users or anyone looking to sharpen their logging skills. Register today! Dallas – April 29 London – June 24 🍽️ User Group Dinners Connect in person with other LM users in your city over dinner and real talk. Share wins, swap stories, and grow your network - RSVP here: London – April 1 Dallas – April 29 Chicago – May 6 Nashville – May 13 💻 Virtual User Groups AMER East – June 3 AMER West – June 5 EMEA – June 10 APAC – June 12 Additional Resources If you missed any part of the session or want to revisit the content, we’ve got you covered: Review the slide deck here Want to see the full session? Watch the recording below ⬇️Best Practices for Practitioners: Collector Management and Troubleshooting
Overview The LogicMonitor Collector is a critical Software as a Service (SaaS) component designed to collect performance metrics across diverse IT infrastructures. It provides a centralized, intelligent monitoring solution to gather data from hundreds of devices without requiring individual agent installations. By encrypting and securely transmitting data via SSL, the Collector offers a flexible approach to infrastructure monitoring that adapts to complex and diverse network environments. Key Principles Implement a strategic, unified approach to infrastructure monitoring that provides comprehensive visibility across diverse environments Ensure collectors are lightweight, efficient, and have minimal performance impact on monitored resources Maintain robust security through encrypted data transmission and carefully managed credential handling Design a monitoring infrastructure that can dynamically adjust to changing network and resource landscapes Regularly review, tune, and update collector configurations to maintain optimal monitoring performance Comprehensive Collector Management Collector Placement Strategies Strategic Location Install collectors within the same network segments as monitored resources Choose servers functioning as syslog or DNS servers for optimal placement Avoid monitoring across vast internet connections, firewalls, or NAT gateways Sizing Considerations Select appropriate collector size based on expected monitoring load Consider available memory and system resources Understand collector type limitations (e.g., Windows collectors can monitor both Windows and other devices, while Linux collectors are limited to devices) Network and Security Configuration Configure unrestricted monitoring protocols (SNMP, WMI, JDBC) Implement NTP synchronization for accurate time reporting Use proxy servers if direct internet connectivity is restricted Configure firewall rules to allow necessary collector communications Collector Groups Organize collectors logically: By physical location By customer (for MSPs) By environment (development, production, etc.) Utilize Auto-Balanced Collector Groups (ABCG) for dynamic device load sharing Version Management Schedule regular updates Choose appropriate release types (MGD, GD, EA) Maintain update history for tracking changes Use downgrade option if experiencing version-specific issues Logging and Troubleshooting Log Management Adjust log levels strategically: Trace: Most verbose (use sparingly) Debug: Detailed information for troubleshooting Info: Default logging level Warn/Error: Issue-specific logging Configure log file retention in wrapper.conf Send logs to LogicMonitor support when collaborating on complex issues Troubleshooting Specific Environments Linux Collectors Check Name Service Caching Daemon (NSCD) configuration Verify SELinux settings Use getenforce or sestatus to check SELinux status Temporarily set SELinux to Permissive mode for debugging Windows Collectors Ensure service account has "Log on as a service" rights Check local security policy settings Resolve Error 1069 (logon failure) by updating user rights Advanced Techniques Credential Management Integrate with Credential Vault solutions: CyberArk Vault Delinea Vault Use dual account configurations for credential rotation Collector Debug Facility Utilize the command-line interface for remote debugging Run debug commands to troubleshoot data collection issues Performance and Optimization Regularly monitor collector performance metrics Tune collector configuration based on monitoring load Disable Standalone Script Engine (SSE) if memory is constrained Implement proper log and temporary file management Maintenance Checklist ✅ Regularly update collectors ✅ Monitor performance metrics ✅ Review collector logs ✅ Validate data collection accuracy ✅ Test failover and redundancy configurations ✅ Manage Scheduled Down Time (SDT) during maintenance windows Conclusion Successful LogicMonitor Collector management is a dynamic process that requires strategic planning, continuous optimization, and a deep understanding of your specific infrastructure needs. The key to effective monitoring lies in strategically placing collectors, configuring them appropriately, and regularly reviewing their performance and configuration. By following these best practices, organizations can create a robust, adaptable monitoring strategy that provides comprehensive visibility into their IT ecosystem. Additional Resources Management and Maintenance: Viewing Collector Events Managing Collector Logs Adding SDT to Collector Adding Collector Group Collector Version Management Integrating with Credential Vault Integrating with CyberArk Vault for Single Account Integrating with CyberArk Vault for Dual Account Troubleshooting: Troubleshooting Linux Collectors Troubleshooting Windows Collectors Collector Debug Facility Restarting CollectorBest Practices for Practitioners: Collector Installation and Configuration
Overview The LogicMonitor Collector is a Software as a Service (SaaS) that collects the data required for IT infrastructure monitoring in the LM Envision platform. Installed on Linux and/or Windows servers, it gathers performance metrics from selected devices across an organization's IT stack, whether it’s on-prem, off-prem, or in the cloud, using standard monitoring protocols. Unlike traditional monitoring approaches, a single Collector can monitor hundreds of devices without requiring individual agent installations on each resource. The Collector's core strength lies in its proprietary built-in intelligence that automatically recognizes device types and applies pre-configured Modules that define precise monitoring parameters specified to that device or platform. By encrypting collected data and transmitting it securely to LogicMonitor's servers via SSL, the Collector provides a flexible and centralized approach to infrastructure monitoring. This unique design allows organizations to strategically place Collectors within their network, enabling comprehensive performance visibility while minimizing monitoring overhead and complexity, with its monitoring capacity adapting to the device or service complex resources and specific metrics being collected. Key Principles LogicMonitor Collector deployment is guided by principles of efficiency, scalability, and intelligent monitoring: Centralized SaaS monitoring through strategic collector placement Simplified device discovery and metric collection Minimal performance impact on monitored resources Secure, encrypted data transmission Using the LogicMonitor Collector Recommended for: Complex IT infrastructures with multiple network segments Organizations requiring comprehensive, centralized monitoring Environments with diverse device types and monitoring requirements Not recommended for: Extremely small environments with few devices Networks with strict segmentation preventing central data collection Environments with severe network connectivity limitations Recommended Installation Best Practices Collector Placement and Sizing Install collectors close to or within the same network segments as monitored resources Choose servers that function as syslog or DNS servers for optimal placement Select the appropriate collector size based on the expected monitoring load Consider memory and system resources when sizing collectors Avoid monitoring resources across vast internet connections, firewalls, or through NAT gateways Keep in mind Windows collectors can monitor BOTH window and Linux devices while Linux collectors can only monitor Linux devices Recommended Disk Space New installation: ~500 MiB Logs: Up to 800 MiB Temporary files: <1500 MiB Report cache: <500 MiB NetFlow (if enabled): Up to 30 GiB Total recommended: <3.5 GiB (without NetFlow) Network and Security Configuration Ensure outgoing HTTPS (port 443) connectivity to LogicMonitor servers Configure unrestricted monitoring protocol (ex: SNMP, WMI, JDBC) Use proxy servers if direct internet connectivity is restricted Implement NTP synchronization for accurate time reporting Configure firewall rules to allow necessary collector communications Windows Collector Installation Recommended installation methods: Interactive Install Shield Wizard PowerShell silent installation Can be downloaded direct or bootstrap via CDN Service account considerations: For monitoring Windows systems in the same domain: Use domain account with local admin permissions For monitoring systems in different domains: Use local administrator account Ensure "Log on as a service" permissions are granted Linux Collector Installation Prerequisites: Bourne shell sudo package installed (for non-root installations) vim-common package (for xxd binary in newer versions) Recommended installation user: Default logicmonitor user Use executable permissions and install via binary Container Deployment Supported Kubernetes services: Microsoft Azure Kubernetes Service (AKS) Amazon Elastic Kubernetes Service (EKS) Google Kubernetes Service (GKS) Limitations: Full package installation only Linux-based collectors cannot monitor Windows WMI Performance and Optimization Monitor collector performance metrics regularly Tune collector size and configuration based on monitoring load Disable Standalone Script Engine (SSE) if memory is constrained Implement proper log and temporary file management Use container deployments for Kubernetes environments Best Practices Checklist ✅ Select strategically located servers for collector installation ✅ Choose the appropriate collector size based on expected monitoring load ✅ Configure reliable network connectivity and firewall rules ✅ Use non-root users for Linux collector installations ✅ Implement NTP time synchronization ✅ Monitor collector performance metrics ✅ Regularly update collectors to the latest stable versions ✅ Set collector “Down” notification chains for proper collector down alerting Monitoring and Validation Verify collector connection in LogicMonitor portal after installation Monitor collector CPU utilization, disk usage, and performance metrics Periodically review collector logs for potential issues Validate data collection accuracy and completeness Utilize and test collector failover and redundancy configurations Conclusion LogicMonitor Collectors provide a powerful, flexible approach to infrastructure monitoring, enabling organizations to gain comprehensive visibility with minimal operational overhead. By following best practices in placement, configuration, and ongoing management, IT teams can create a robust monitoring strategy that adapts to evolving infrastructure needs. Successful collector deployment requires careful planning, ongoing optimization, and a thorough understanding of your specific infrastructure requirements. Regularly reviewing and adjusting your monitoring approach will ensure continued effectiveness and performance. Additional Resources Collector Capacity Collector Versions Adding Collector Installing Collectors in Silent Mode Installing the Collector in a Container Configuring WinRM for Windows Collector agent.conf Collector Settings Collector Script Caching
Issues with Switching Non-Admin Domain Account on a Windows Collector
I have configured a non-admin domain user that I would like to use as my collector account and am receiving an error once running the command ".\Windows_NonAdmin_Config -add -UserName domain\domainUser". The response: GetSecurityDescriptor failed: At C:\Program Files\LogicMonitor\Agent\bin\Windows_NonAdmin_Config.ps1:571 char:13 + throw "GetSecurityDescriptor failed: $($output.ReturnValu ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (GetSecurityDescriptor failed: :String) [], RuntimeException + FullyQualifiedErrorId : GetSecurityDescriptor failed: The log files are below: Set-WmiNamespaceSecurity call with add operation ERROR - GetSecurityDescriptor failed: I have previously ran the Non-admin file Windows_NonAdmin_Config.ps1 from C:\Program Files\Logicmonitor\agent\bin\ from the DC and it only ran through the first 3 phases before completing w/o errors. I added WMI permissioned from WMI Control (Windows Server Monitoring and Principle of Least Privilege | LogicMonitor) on the DC and the Windows device running the collector. I would appreciate guidance on the necessary settings for a domain user to replace the current system account on the collector, enabling it to serve as a WMI data collection account for the domain.LogicMonitor Collector Ports to be used while monitoring end-user devices
Review a full list of protocols and ports required for monitoring User Activity. This post will provide information regarding the ports, protocols, use case & configuration settings if required that is been used in general, with respect to LM platform. Using the " <port>/<protocol> " format is a common and standardized way to indicate network ports along with the associated protocols. This format helps provide a clear and concise representation of the port and protocol being discussed below : Inbound communication : Port Protocol Use Case Configuration Setting 162 UDP SNMP traps received from target devices eventcollector.snmptrap.address 514 UDP Syslog messages received from target devices eventcollector.syslog.port 2055 UDP NetFlow data received from target devices netflow.ports 6343 UDP sFlow data received from target devices netflow.sflow.ports 7214 HTTP/ Proprietary Communication from custom JobMonitors to Collector service httpd.port 2056 UDP JFlow data received from target devices Outbound communication : Port Protocol Use Case Configuration Setting 443 HTTP/TLS Communication between the Collector and the LogicMonitor data center (port 443 must be permitted to access LogicMonitor’s public IP addresses; If your environment does not allow the Collector to directly connect with the LogicMonitor data centers, you can configure the Collector to communicate through a proxy.) N/A Other non-privileged SNMP, WMI, HTTP, SSH, JMX, etc. Communication between Collector and target resources assigned for monitoring N/A Internal communication : Port Protocol Use Case Configuration Setting 7211 Proprietary Communication between Watchdog and Collector services to OS Proxy service (sbwinproxy/sblinuxproxy) sbproxy.port 7212 Proprietary Communication from Watchdog service to Collector service agent.status.port 7213 Proprietary Communication from Collector service to Watchdog service watchdog.status.port 15003 Proprietary Communication between Collector service and its service wrapper N/A 15004 Proprietary Communication between Collector service and its service wrapper N/A Destination Ports : Port Protocol Use Case 135 TCP Port 135 is used for DCOM's initial communication and RPC (Remote Procedure Call) endpoint mapping.. DCOM often uses higher port numbers in the range of 49152 to 65535 for dynamically allocated ports 22 TCP TCP for SSH connections 80 UDP NetFlow data received from target devices 443 UDP sFlow data received from target devices 25 HTTP/ Proprietary Communication from custom JobMonitors to Collector service 161 UDP JFlow data received from target devices 1433 TCP/UDP TCP for Microsoft SQL 1434 TCP/UDP The protocol used by port 1434 depends on the application that is using the port. For example, SQL Server uses TCP for communication with clients, while the SQL Server Browser service uses UDP 1521 TCP/UDP TCP/UDP to listen for database connections from Oracle clients 3306 TCP/UDP TCP/UDP for MySQL 5432 TCP TCP for PostgreSQL 123 NTP Connection from the library to an external NTP server. 445 TCP Server Message Block (SMB) protocol over TCP/IP LM Collector's monitoring protocols support a number of other monitoring protocols that can be incorporated into this list based on your preferences. Our LM collector supports a number of different monitoring protocols, so we can add to this list as necessary. Hopefully, through these details shared above, we will be able to understand what ports/protocols are used in LM platform. Thanks!Fixing misconfigured Auto-Balanced Collector assignments
I’ve seen this issue pop up a lot in support so I figured this post may help some folks out. I just came across a ticket the other day so it’s fresh on my mind! In order for Auto-Balanced Collector Groups (ABCG) to work properly, i.e. balance and failover, you have to make sure that the Collector Group is set to the ABCG and (and this is the important part) the Preferred Collector is set to “Auto Balance”. If it is set to an actual Collector ID, then it won’t get the benefits of the ABCG. You want this, not that: Ok, so that’s cool but now the real question is how do you fix this? There’s not really a good way to surface in the portal all devices where this is misconfigured. It’s not a system property so a report or AppliesTo query won’t help here… Fortunately, not all hope is lost! You can use the ✨API✨ When you GET a Resource/device, you will get back some JSON and what you want is for the autoBalancedCollectorGroupId field to equal the preferredCollectorGroupId field. If “Preferred Collector” is not “Auto Balance” and set to a ID, then autoBalancedCollectorGroupId will be 0 . Breaking it down step by step: First, get a list of all ABCG IDs https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Collector%20Groups/getCollectorGroupList /setting/collector/groups?filter=autoBalance:true Then, with any given ABCG ID, you can filter a device list for all devices where there’s this mismatch https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Devices/getDeviceList /device/devices?filter=autoBalancedCollectorGroupId:0,preferredCollectorGroupId:11 (where 11 is the ID of a ABCG) And now for each device returned, make a PATCH so that autoBalancedCollectorGroupId is now set to preferredCollectorGroupId https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Devices/patchDevice Here’s a link to the full script, written in Python for you to check out. I’ll also add it below in a comment since this is already getting long. Do you have a better, easier, or more efficient way of doing this? I’d love to hear about it!Monitor DFS Share(windows server) using LM Collector!!
Greetings to all members of the LM community. Hope you all are doing great! Our community blog in this section, discusses on how to monitor DFS share in LM & general recommendations to follow for our LM collector to monitor the share path in today's community blog: Configuring DFS share on Windows server : This DFS share service is dependent on two parameters to establish communication with the target server, shown below, as you can see from the target server: With these two parameters, domain name and IP are used to configure communication with DFS for the purpose of LM data collection. In my test environment, I've created a Stand-alone Namespace that has the following permissions on the local path: In addition to defining the local path permissions for a DFS share, you also have the option to edit the permission for the local path of the shared folder at the time of creating the share path : Pre-requiste/Permissions required : As well as permission, there may be other things the LM collector needs before it can access remote DFS shares : Network Discovery: Enabling network discovery helps the monitoring tool discover and enumerate devices, including network shares, on the network. This can be useful when setting up data collection for resources in remote domains. Firewall and Network Configuration: Ensure that the necessary ports and protocols are open in the firewall between your monitoring tool and the remote domain. Network discovery and access to DFS shares often require specific ports and protocols to be allowed through firewalls. Namespace Path: When specifying the DFS share path in your monitoring tool, use the DFS namespace path (e.g., [ \\(domain/IP).com\dfs] rather than the direct server path. This ensures that the tool can access the share through the DFS namespace. Trust Relationships and Permissions: Ensure that trust relationships between domains are correctly established to allow access. Additionally, configure permissions on the DFS shares and namespace to grant access to the monitoring tool's credentials. It's important to note that the exact steps and configurations may vary depending on your specific network setup, DFS version, and domain structure. Additionally, working with your organization's IT administrators and domain administrators is essential to ensure proper setup and access to DFS resources in remote domains. Monitoring DFS share on LM portal : In the course of testing on the windows server with role-based or feature installation for DFS service, it' is set to discovered or acknowledge the information for DFSR monitoring in LM, when an IP address or domain name(FQDN) is known or defined under shared path as shown below. Edit the necessary configurations for each UNC path you are adding as a monitored instance. These configurations are detailed in the following sections. Under Resource → Add Other Monitoring you can configure DFS path under section “UNC Paths” Updating DFS share path in LM Monitors the accessibility of a UNC path from an collector agent. May be a directory or file path required on LM portal to be defined. Discovery of DFS path in LM Once you finalise the above instructions from the target DFS server, you can monitor a UNC share, whether a domain DFS share or otherwise, using the UNC Monitor DataSource. This DataSource will do a directory listing on the given UNC share and report success or failure. The UNC Monitor DataSource will monitor the accessibility of the UNC path from the collector monitoring this device. Once you have added the DFS share to be monitored, LogicMonitor will begin monitoring the share and will generate alerts if there are any problems. Link for more references: https://www.logicmonitor.com/support/devices/device-datasources-instances/monitoring-web-pages-processes-services-and-unc-paths#:~:text=to%20get%20output.-,UNC%20Paths,-To%20monitor%20a https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dfsn-access-failures Keep Learning & Keep Exploring with LM !!!!!! Interested in learning more about features of your LogicMonitor portal? Check our some of our webinars in our community!https://www.logicmonitor.com/live-training-webinars Sign up for self guided training by clicking the "Training" link at the top right of your portal. Check out our Academy resources!https://www.logicmonitor.com/academy/LM Community Newsletter - August 2023
LM Community Spotlight LM Customer of the Month Matt Whitney Meet Matt Whitney! LM Community customer of the month! Matt is a TechOps Administrator at CDI and acts as an LM subject matter expert for CDI's customers and internal engineers. If there is something CDI needs done that is not provided out-of-the-box by LM, Matt can script out custom solutions, such as LogicModules for custom monitoring or API-based reporting. What do you love most about being a member of the LM community? One great thing about the community is that you can see the different ways other people use the product. If I am trying to do something out-of-the-box in LM (custom monitoring/automations/etc) then the forums are the first place I look to get ideas and see how others have solved for similar things. Also if I notice an issue/bug there is likely already discussion about it in the forums, if not then the forums are a great place to get visibility on issues! LM Employee of the Month Patrick Rouse Meet Patrick Rouse! LM Community Employee of the month! Patrick is a Sr. Product Manager joined LogicMonitor January 2022. Patrick is responsible for IT Infrastructure Monitoring (Modules), and passionate about cloud-managed networking. What do you love most about being a member of the LM community? “I love hearing feedback (good or bad) and ideas from our customers!” Top Content Exciting news regarding the LogicMonitor Inner Circle! Read about our new Customer Engagement Platform Summer Launch Modernizing Monitoring: LogicMonitor’s Latest Innovations Product Discussions New VMware modules dropped Accessing the LogicMonitor REST API with Postman and LMv1 API Token Authentication Tech Talk LogicMonitor Collector Ports to be used while monitoring end-user devices LM News Introducing Enhanced Dashboards and Settings in the New UI Open Beta Process New UI eLearning Courses Available in LM Academy Dashboards UIv4 is available starting August 23! New Settings Beta! New Resources UI Datapoint Analysis now available! API v3 usage & migration Enhanced API v3 Experience with Delta on device\device endpoint Experience the new API v3 LogicBots Bytesize Humor Meet Bob! He is a Rhodes Scholar and regularly enjoys wine tasting, truffle hunting, and holidays in Spain. He restores vintage cars for fun and strangely, his shirts don't wrinkle. He hikes the PCT Annually during his unplugged, and catches up on the Hard Core History podcast. Bob’s is such a fungi, he loves Truffle hunting with his friend Lagotto! 
Migrate your Linux collectors to non-root by Sept 30!
Hello All, Thank you for supporting LogicMonitor's efforts to ensure Collector Security. With your help, we have been able to transition ~7,000 collectors to non-privileged users out of the 10,000 linux collectors currently live in customer environments. Per our last email on this topic, we had shared a deadline of June 30, 2023 for customers to migrate their collectors from root to non-root users. Due to customer requests needing more time, we have now extended the deadline to September 30, 2023, allowing for more time to test the non-root migration scripts and migrate linux collectors. We appreciate your support in helping us achieve our goal of running all collectors using non-privileged credentials. ACTION REQUIRED: Migrate any collectors which are running under root users to non-privileged users For more details, please refer to: https://www.logicmonitor.com/support/migrating-collector-from-root-to-non-root-user If your current collector installation process uses the root user to install linux collectors, please start using non-privileged user For more details, please refer to: https://www.logicmonitor.com/support/collectors/collector-installation/installing-collectors#Linux-collector. TIMELINE: Migrate your current linux collector install base to non-privileged users as soon as possible, however no later than September 30, 2023. Your current collectors will not be affected by this change, only new installs will not be installed as root. Thank you for your prompt attention to this matter. If you have any questions, please contact Logicmonitor Support or contact your Customer Success Manager (CSM) Is there a reason why this will not work in your environment? Would you still like to run a linux collector as root? Let us know in the comments Thank you!Upgrade your Collectors to MGD 33.006 before October 03, 2023!
Each year LogicMonitor rolls out the minimum required version (the MGD) for all collectors. It is the most mature version containing the gist of all the enhancements and fixes we’ve added throughout the year. To achieve uniformity, the MGD becomes the base version for all future releases. As we approach the time for the MGD automatic upgrade, we would like to inform you that the GD Collector 33.006 will be designated as the MGD Collector 33.006. This means that all collectors must be upgraded to GD Collector 33.006 or higher. Note: If it is absolutely necessary, we may release security patches. In such scenarios, the MGD version 33.006 will be incremented, and we will keep you informed. Schedule for MGD 33.006: MGD 33.006 Rollout: August 29, 2023 Voluntary upgrade time period: Anytime before October 3, 2023 Automatic upgrade Scheduled: October 3, 2023 at 5:30 am PST Please note that it is critical to upgrade to the new MGD version! On October 03, 2023, any collectors still using a version below MGD will not be able to communicate with the LogicMonitor platform. This is due to the improvements made to the authentication mechanism of the LogicMonitor platform. Actions Required: Look for the MGD rollout notification email from LogicMonitor on August 29, 2023 Upgrade your collectors to GD 33.006 to avoid loss of communication Thank you for your prompt attention to this matter. If you have any questions, please contact LogicMonitor Support or contact your Customer Success Manager (CSM).
