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
Palo Alto application data missing from Netflow
We have been able to get Netflow data working for a Palo Alto PA-820 firewall, but we are not seeing the application data show up. Does anyone have any suggestions on next steps we could take? Here is what has been done so far: Netflow profile has been configured on the Palo Alto side and assigned to the interface, including selecting the PAN-OS Field Types to get the App-ID and User-ID (https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/monitoring/netflow-monitoring/configure-netflow-exports) nbar has been enabled on the collector: # enable netflow support for NBAR, IPV6 and Multicast fields netflow.nbar.enabled=true # enable netflow support for IPV6 fields netflow.ipv6.enabled=true Collector version is 34.003 We’re seeing everything we expect except the app & systems data on the Traffic tab for the device: Any thoughts on what we might be missing? Thank you. :-)Excessive snmp requests with a community string I am not using
I have some switches that are getting hammered by a few of my collectors and I can't figure out why. The logs on them are full of this message: snmp: ST1-CMDR: Security access violation from <Collector IP> for the community name or user name : public (813 times in 60 seconds) I don't have "public" set for this set of switches anywhere and it is coming from my collectors. I don't have any netscans for the subnet they are on. In my portal everything looks normal for these switches. I'm not sure what else to be looking at to figure this out, anyone have any thoughts? Thank you!
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.Any way to change which portal a collector is associated with?
Hi, Our company was acquired by a different company, and we both use LM. Is there any way to take a collector that's point to company1.logicmonitor.com and change it to point to company2.logicmonitor.com so all the servers get populated in the new portal? I know I can just create a new company2 collector for the company1 servers, but then I have to rediscover everything and add in all the servers again. I thought if there was an easy way to just change the existing collector to point to the new portal, it would just pop everything in nice and easy. Thanks.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!How to redirect the output of the groovy script to the collector log file using groovy script?
In my groovy script, I want to redirect the output from the groovy script into the collectors log file? What should be the groovy code, to redirect the output to the collectors log file? Can anyone help me here?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!
