LogicMonitor 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 customJobMonitorsto 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’spublic IP addresses; If your environment does not allow the Collector to directly connect with the LogicMonitor data centers, you canconfigure 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 therange of 49152 to 65535 fordynamically 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 customJobMonitorsto 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 applicationthatis using the port. For example, SQL Server uses TCP forcommunication with clients, while the SQL Server Browserservice 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!
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/
Monitoring Ec2 instances
Hi All, I have been going through the documentation and it suggests that when we are setting up monitoring for ec2 with autoscaling we should select netscan frequency of 10 minutes. This is the minimum time we can configure and new device may take upto 15 minutes to be monitored. My question is is there a way if a new instance is launched we can bring that into monitoring less than 10 or5 minutes.PKI Password Cache monitoring?
Hello there, I am curious if monitoring can be done for this and how it would be done. Is it possible to monitor the password cache space for a PKI server? In particular, password cache for cert enrollment on Network Device Enrollment Service. By default, cert enrollment attempts are put in the cache for an hour if it is deemed incomplete and 5 attempts are allowed to be cached. You can raise this default with the PasswordMax reg key. I figured it would be helpful to monitor this to know what the key value would need to be set to or to be proactive with solving/troubleshooting issues where the cache becomes full. Perhaps a powershell script would suffice? Thanks in advance for any tips! 😄 https://social.technet.microsoft.com/wiki/contents/articles/9063.active-directory-certificate-services-ad-cs-network-device-enrollment-service-ndes.aspx#Password_and_Password_Cache
Office365 Monitoring
Hi everybody! I've been using Mike Sudings monitoring solution for a while and i've expanded it a bit to monitor more solutions in Office365. TheMonitors included Custom Domains (quantity)WHEKJJ Deleted Users(quantity)ZHADY9 Global Admins(quantity)7GGZWZ Licenses Assignable ((quantity) based on type)R46EGX Licenses Assigned(quantity) based on typeGHRNLL Licensed / Unlicesned Users(quantity)4PJZJ4 MFA Users(quantity of enabled/disabled users)WZFAWK Users and devices in Office365 Tenant(quantity) Devices if clients are joined to Azure ADPLMP22 Hope they are helping the community out
Cisco UCS monitoring doubt
Hello, Nowthat a new suite of data sources is available for the UCS stuff, we're havingsome doubts on the monitoring related with the Cisco UCS Manager & their respective components (Fabric Interconnects, etc...) I'm sure the new suite removes the needof the SNMP legacy datasources (that's great btw!!!), however, we're now kinda lost on what should we add into LM (in terms of components). I'm pretty sure in the past we had to add the UCS Manager + the Fabric Interconnect devices (to fetch some hardware related info that wasn't fetched via UCS Manager), but currently, I see the same datasources applied to the UCS & both Fabrics. I'm assumingthat we only require to monitor the actual UCS Manager from now on (everything else will be monitored under it). Specially the hardware portion of both Fabric Interconnects (at least from what I'm seeing). Is my assumption correct? Or, is there anything else we need to have in mind in terms of the Fabrics. Appreciate the clarificationguys! Regards,
