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. TheSelect-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 passdown 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.
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 ourinternal 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 | LogicMonitorand apparenlty we could expand another way than the one selected !!! Any thoughts on this? Thanks, Dom