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?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. :-)
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!
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.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 onhow 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 serverwith 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/