Persie
LM ChampionJoined 3 years ago
User Profile
LM Champion
User Widgets
Contributions
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 on how 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 server with 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/572Views15likes0CommentsSample Webcheck via Groovy Scripts to test-out!!!
In LM tool, you can choose to manually add your request and response Groovy scripts directly into the text boxes found under both of these Script tabs or, as shown next, you can choose to first complete the fields under the Settings tab (e.g. HTTP Version, Method, Follow redirect, Authentication Required, Headers, HTTP Response Format, etc.) and then click the Generate Script from Settings button to have LogicMonitor auto-generate request and response scripts based on those settigs. The latter option produces a basic template for your Groovy scripts. (For more information on completing the fields found under the Settings tab for both the HTTP request and response, see Adding a Web Check). So with LM platform tool, you can also auto-generate request and response scripts script as shown in above screenshot. Now here is an sample script to providing a code snippet in Groovy that's using the Santaba HTTP library to make an HTTP GET request to a specified URL (in this case, "https://www.google.com") and retrieve headers from the response. Additionally, it appears to set basic authentication credentials for the request. The script here is just for reference, to test the scripted HTTP responses.This code block here is the part which makes the http get to google Here's a breakdown of your code: import com.santaba.agent.groovyapi.http.*; // Instantiate an http client object for the target system httpClient = HTTP.open(); // Set basic authentication credentials httpClient.setAuthentication("myusername", "mypassword"); // Specify the URL url = "https://www.google.com"; // Perform an HTTP GET request def getResponse = httpClient.get(url); // Get headers from the response headers = httpClient.getHeaders(); // Close the http client httpClient.close(); Alternatively you can leverage the LM tool to monitored the Few things to note for the code here : The code appears to be setting basic authentication credentials ( myusername and mypassword ), but it's important to note that sending credentials in plaintext might not be secure. Consider using HTTPS and more secure authentication methods if available. The code is making an HTTP GET request to the specified URL ( "https://www.google.com" ) and storing the response in the getResponse variable. After the request, the code retrieves headers from the response using httpClient.getHeaders() and stores them in the headers variable. Finally, the HTTP client is closed using httpClient.close() . Link for more references : https://www.logicmonitor.com/support/services/adding-managing-services/executing-internal-web-checks-via-groovy-scripts Example Request Script Commands 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/323Views20likes0CommentsLogicMonitor 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!7.4KViews38likes1CommentWebsite monitoring with Zscaler client in LM
To monitor website access via Zscaler using LogicMonitor, you can set up web checks to verify if the websites are accessible and responsive. LogicMonitor's web checks allow you to periodically test the availability and performance of websites from different geographic locations. Here's how you can set up monitoring for website access via Zscaler: Pre-requisite You will need to have introduced the Zscaler client to the LM Collector Server placed in the network environment where Zscaler is used for communication to access the Internet via websites. Zscaler reference doc for more information : https://help.zscaler.com/zia/skipping-inspection-traffic-specific-urls-or-cloud-apps https://help.zscaler.com/zia/whitelisting-urls Our Collectors gather information from your infrastructure, encrypt it, and deliver it to the LogicMonitor Service through an outbound TLS-encrypted connection, where it is stored, processed and presented back to users through a web interface. Every LogicMonitor customer has a DNS record of [customername].logicmonitor.com. This record resolves to two or more public IP addresses at any given time. Because these IP addresses can and do change over time, it’s imperative that your network’s firewall(s) permit access to all of our public IP addresses For more information about these IP addresses you may refer to the following article - https://www.logicmonitor.com/support/about-logicmonitor/overview/logicmonitor-public-ip-addresses-dns-names We recommend whitelisting *.logicmonitor.com for your network. In addition, you will need outbound TCP port 443 and port 80 access. Port 80 is only used if one attempts to access LogicMonitor via a non-secure http address. This will initially reach port 80 and then be redirected to port 443 for encryption. In order to use our Remote Session functionality, you will also need RDP or SSH on port 443. Create Web-Checks in LogicMonitor: Log in to your LogicMonitor account. Navigate to Settings > Alerts > Web Checks. Click on Add Web Check to create a new web check: https://www.logicmonitor.com/support/services/adding-managing-services/adding-a-web-service Configure LM Web-Check Parameters: Enter the URL of the website you want to monitor. Choose the check frequency (how often the website is checked). Select the geographic locations from which the checks will be performed. You can choose locations that are relevant to your customer's usage of Zscaler. Set up alert thresholds for response time, HTTP status codes, or other relevant metrics: https://www.logicmonitor.com/support/services/adding-managing-services/adding-a-web-service#:~:text=will%20be%20sent.-,Configuring%20URL%20Request%20and%20Response%20Settings,-For%20every%20Web Test to perform on Zscaler client environment: To simulate website access through Zscaler, you might need to set up LogicMonitor to perform web checks from the customer's network. This could involve configuring LogicMonitor collectors within the customer's network environment. Response Time and Status Code Monitoring: Monitor the response time and HTTP status codes returned by the website. This helps you identify slow or unavailable websites. Alerting and Notifications: Set up alert thresholds based on your customer's requirements. For example, you can configure LogicMonitor to trigger alerts if the response time exceeds a certain threshold or if specific HTTP status codes are returned : https://www.logicmonitor.com/support/services/about-services/services-alerts Custom Scripting (Optional): If Zscaler adds specific headers or modifies responses, you might need to customize your web checks accordingly. LogicMonitor supports custom scripting for advanced monitoring scenarios. Remember that setting up web checks from within your customer's network environment might require coordination with their IT team, as well as consideration of security and compliance policies. Additionally, LogicMonitor's capabilities might evolve over time, so refer to their documentation or support resources for the most up-to-date guidance on web checks and monitoring configurations.477Views15likes0Comments