Collector Status Alerting
The settins/collectors pages show alert ahainst collectors e.g. Watchdog etc. However these alerts do not appear in the general Alerts GUI or against the collector host resource. We have some single collectors that when fail will cause all the resources underneath to alert (host Status). However I would like an alert agains the collector or its host that can be sent to ServiceNow (I do not want a Host Status alert for each resource under a single collector to raise a ticket). I simply want the alert that is generated (collector Down) in the escalation chain to be visible in the GUI with it's ServiceNow ticket. I can see it in the Integration Log(ServiceNow) with a ticket reference generated but this is time consuming and not visible to all users.
Finding the culprit for TCP_StatsCollector ConnectionsEstablished alert for Windows collectors
From the collector’s device page in the LM Portal or the collectors page, get to a debug console, then here’s your !POSH one-liner to get info about the destination device that is holding your ports captive. netstat -an | sls establish | foreach { ($_ -split "\s+")[3] } | group | sort count | select count, name -last 10 In the Netstat, a shows all, n shows IP addresses rather than solving the DNS for it. The Select-String (aliased as sls) passes only the “Established” connection entries from the netstat down the pipeline. The foreach{} splits each line ($_ is the current object being iterated by the foreach loop) on contiguous whitespace (I use this a lot!) and takes the third element (remote address:port) to pass down the pipeline It then passes Group-Object (aliased as group) which bundles identical strings and Sort-Object (aliased as sort) by the count property of the group object. The select displays grabs the calculated match count and the name properties to limit display and just shows the -last 10 of them (which are the biggest number of matched lines due to the sort previously applied. This should give you the target/s for troubleshooting further.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).
SNMP Trap Credentials on Resource Properties Enhancement
Hello LM Community! Just wanted to highlight this enhancement that has been released recently in EA Collector 34.100 to support the use of SNMP trap credentials on resource properties. When using this collector version or newer, you can add snmptrap.* properties on resource/group level for the collector to decrypt the trap messages received from monitored devices. The credentials are used in the following order: Collector first checks for the set of credential snmptrap.* in the host properties. If the snmptrap.* credentials are not defined, it looks for the set of snmp.* in the host properties. If sets for both snmptrap.* and snmp.* properties are not defined, it looks for the set eventcollector.snmptrap.* present in the agent.conf setting. More details can be found in the below articles in our documentation: SNMP Trap Monitoring: https://www.logicmonitor.com/support/logicmodules/eventsources/types-of-events/snmp-trap-monitoring EA Collector 34.100 Release Notes: https://www.logicmonitor.com/release-notes/ea-collector-34-100
Agent-based versus agentless data collection: what’s the difference?
Understanding the nuances between Agent-based vs. agentless monitoring, is key to your Monitoring Strategy. Learn more about the differences and how they apply to your security, speed, compatibility, resource usage, connecting with third-party services and overall performance. Learn More Discover how LogicMonitor can enhance your monitoring capabilities with a free 14-day trial today. LogicBlog Click here to subscribe and read more about the latest industry trends in the world of monitoring and what’s happening around LogicMonitor.How many collectors do you have?
Hello, Our Logic Monitor environment is overloaded. What is the best practices to expand? We have currenty 64 collectors “All the same size” and our internal LM Support for the collectors is requesting 52 new collectors!! They are taking the approach to create collectors all the same size for 10,000 instances. I was thinking about other routes 1. bigger collectors if possible for 30,000 instances each may be... 2. minimize the number of instances by cleaning up what is not needed but I am not sure anybody will know We have an AZURE Collector VZPOHIALGCMON01 with 82,305 instances !!! I reviewed this Collector Capacity | LogicMonitor and apparenlty we could expand another way than the one selected !!! Any thoughts on this? Thanks, DomUse AWS Unified Cloudwatch Agent to replace Logic Monitor Collector in multiple AWS accounts
Is there any way to use the AWS Unified CloudWatch Agent and Cloudwatch Logs load EC2 metrics into LogicMonitor similar to what is pulled from the LogicMonitor collector? A little background. We currently use two LogicMonitor collectors to gather Windows metrics from AWS EC2 instances and physical and virtual servers in our on-prem datacenter. This has worked well for the 100 Windows servers and network devices we are monitoring. We are moving all of our on-prem Windows applications to AWS, which requires we change the way we use AWS. Take a look at AWS Control Tower for more details Instead of one AWS account and one VPC ( network ) , we are moving every application and environment ( PROD, UAT, DEV, STAGE ) into different AWS account. No shared networking, so VPC peering or using a TGW isn't an option. This will result in about 20 new AWS accounts and up to 100 by the end of the year. Each of these accounts will have 2 to 20 EC2 Windows instances for web/application along with one EC2 or RDS based Microsoft SQL Server instance. I have no desire to pay for EC2 Windows instances for every account ( possibly hundreds ) just to run the LogicMonitor collector. The most important Windows server monitoring features we rely on in LogicMonitor boil down to - server is down ( ping loss ) - low disk space - high CPU utilization - the ability to alert on Windows Event log entries - Windows service X is not running Then tack on monitoring of an EC2 and RDS Microsoft SQL Server performance data Does LogicMonitor have any recommendations or examples on this type of configuration? Thanks in advance, Kevin Foley
