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!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.Palo Alto application data missing from Netflow
We havebeen 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) nbarhas 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 & systemsdata on the Traffic tab for the device: Any thoughts on what we might be missing? Thank you. :-)
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.Host Status errors corrected by logging into Collector server.
Every night we receive “Host Status” messages on several servers on one collector. You cannot “!ping” to those servers from the Collector’s debug console. However, you can ping those servers that Logic Monitor reports as down. If I log into the collector, the Host Staus messages clear (only login, do not open anything). This is what is baffling us. Has anyone seen anything like this? Thank you very much for your help.