Top Dependencies for LogicMonitor Enterprise Implementation

Last updated on 14 April, 2021

Dependencies Overview

Successful LogicMonitor implementations have a few common customer traits: qualified and trained LM admins (“power users”), understanding of internal requirements, existing tool knowledge, anticipation of internal Change Management lead times, and awareness of dependencies that affect the speed of implementation. Prior to assessing how the technical dependencies below impact your implementation, review LogicMonitor Implementation Readiness Recommendations for Enterprise Customers.

In Professional Services, we provide consultative implementations to our largest enterprise customers. The earlier our customers are aware of their dependencies, prior to and during LogicMonitor implementation, the smoother and quicker the implementation process will go.

Know Your Dependencies

Across the many stakeholders, teams, and/or clients that will be accessing your LogicMonitor implementation, be prepared to review the following dependencies and take the appropriate steps in order to accelerate your LogicMonitor implementation and ROI:

  1. Decide your production portal. If you’ve been through a Proof of Value, it can be easy to lose track of testing and evaluation of LogicMonitor configurations that were not intended for production. Thus, you may opt to reset your portal and start fresh. Conversely, if you’re comfortable with the changes made during PoV, you may continue using this portal into production. You will want to make this decision first, before starting implementation.
  2. Compile a device inventory. You’ll need a full list of devices (IP addresses or DNS names) for import. If you can’t obtain this, you’ll need to gather the subnets where your devices reside in order to build a NetScan policy.
  3. Compile a web check and ping check inventory. If you plan to use LogicMonitor’s website monitoring features (e.g. internal/external, single-step/multi-step websites or internal/external ping-only devices), you’ll also need to gather this inventory for import.
  4. Configure your cloud accounts for LM Cloud. If you plan to monitor your cloud environments with LogicMonitor, you’ll need to go into your AWS, Azure, or GCP instance to set up roles, permissions, and credentials. Once these configurations are in place, adding your cloud accounts to LogicMonitor is a breeze.
  5. Plan your groups carefully. Before importing devices or websites, you’ll need to map out a device group and website group structure for your Resources tree, whether static or based on dynamic criteria. Be sure to consider user permissions, datapoint threshold tuning, and property inheritance as you organize your groups. You may even decide to use a NetScan CSV rather than subnet policy in order to apply device-level properties and auto-populate your dynamic groups.
  6. Obtain device credentials. This can sometimes be the most difficult task: you will need to gather current, accurate credentials for all the devices you plan to import and monitor. This means you’ll need SNMP (v2c or v3), WMI, NetApp, ESX, and other credentials—either extracted from existing tools or from the domain experts of each technology category. Read through our list of common credentials to understand what is supported in LogicMonitor and what your team needs to configure devices appropriately. You will then want to apply these credentials as group-level properties so they can be appropriately inherited by sub-devices and sub-groups.
  7. Plan and provision dedicated Collectors. Acquire enough server hardware or VM/OS licenses to handle the monitoring load required by your devices and internal web/ping checks. Ensure you have plenty of hardware and license resources available well in advance of implementation to minimize delays. Consider all of the following for your Collector architecture planning: location, type (Windows or Linux), size, grouping, and failover. Also, be sure to add your Collectors as monitored devices!
  8. Ensure Collectors have network access to LogicMonitor datacenters. The LogicMonitor Collector needs only outbound secure HTTP (TCP port 443) to our datacenters. However, be sure your security team is aware of and processes a change to allow our public DNS or IP addresses access to all Collectors (and of course end users) inside your network. And be sure to configure your Collectors to communicate through an HTTP proxy, if necessary.
  9. Ensure Collectors have network access to your devices. If you have a secured internal network (i.e. firewalls on your network between the Collector and the target devices you plan to monitor), chances are you will need to consult your security team to make changes to the infrastructure to allow the Collector to monitor devices on appropriate TCP/UDP ports. Something as simple as ICMP should not be blocked between the Collector and devices. Partially or fully blocking these ports will result in extra time spent resolving dead devices in LogicMonitor and troubleshooting missing data with the Collector Debug Facility. Be sure to plan this step well in advance to make appropriate security justifications and schedule lead times.
  10. Configure SSH for configuration file monitoring. If you’re just starting off using our configuration management capabilities or are coming from an existing tool to LogicMonitor, be sure to look through our out-of-the-box ConfigSources. Note that most of these require SSH to be configured on the specific devices you wish to manage configurations for, which means you’ll need to gather SSH credentials from the domain experts and inform your security team to allow SSH through any firewalls (TCP port 22) to your Collectors, if necessary. SSH credentials will need to be added to device groups as properties. (If the ability to monitor and alert on configuration files is not currently available in your LogicMonitor platform and you would like to learn more, reach out to your customer success manager.)
  11. Configure devices for network traffic monitoring. Enabling traffic flow monitoring (NetFlow, IPFIX, sFlow, JFlow, NBAR2) is a breeze to set up and view in LogicMonitor. Perform the following steps (for more detailed configuration instructions, see Configuring Monitoring for NetFlow):
    • Ensure enough Collector capacity is available to receive and process traffic flow data
    • Open any firewall ports required for traffic flow data to traverse the internal network to Collectors
    • Configure the layer 3 devices (firewalls, routers, switches, etc.) to send traffic flow data to the appropriate Collector(s)
  12. Configure devices for SNMP trap and Syslog monitoring. With the configuration of custom EventSources, LogicMonitor can effectively receive and alert on SNMP traps and Syslogs sent from your devices to the Collector. Similar to NetFlow, you’ll need to:
    • Ensure enough Collector capacity is available to receive and process SNMP traps and Syslogs
    • Open any firewall ports required for traffic flow data to traverse the internal network to Collectors
    • Reconfigure the appropriate devices to send SNMP traps and Syslogs to their Collector(s)
    • Configure the custom EventSource to process and alert the identified SNMP traps and Syslogs
  13. Obtain access to alerting integration destinations. Whether you’re planning to send LogicMonitor alert information to ConnectWise, Autotask, PagerDuty, ServiceNow, Slack, or other external team collaboration systems, be sure to have access to the destination URL, usernames, and passwords required for configuration. Preferably, you’ll want access to a sandbox environment before sending alerts to production. You’ll also want to bring your subject matter experts in for these toolsets once LogicMonitor configuration and testing begins.
  14. Understand your stakeholders’ dashboard and reporting requirements. Before allowing stakeholders to view dashboards and reports from LogicMonitor, it’s a good idea to first identify their requirements:
    • Who is the audience that will view monitoring information?
    • What type of information do they need to view?
    • How detailed or summarized should the information be for the audience?
    • Where will the information be viewed (e.g. end-user computers, wall-mounted TV, etc.)?
    • When will the information be viewed (e.g. frequently throughout the day, weekly, monthly, etc.)?

Anticipating your IT Ops organization’s dependencies and lead times is critical to a successful LogicMonitor implementation. If you are pursuing a rapid migration to LogicMonitor, be sure to review this list and bring any questions to your Customer Success, Technical Support, or Professional Services representatives.

In This Article