You can restart a collector from the LogicMonitor platform or from the collector host. When the collector is up and running, you can restart the collector from the LogicMonitor platform. If the collector is down or dead, you have to restart it from the collector host.

Restarting from LogicMonitor Portal

To restart a collector from the LogicMonitor platform:

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the collector that you want to restart.  
3. Select the More option and then select Restart Collector.
   
   A message confirming the restart is displayed.
4. Select Confirm. The collector restart begins.

Restarting from Collector Host

To restart a collector on a Windows host, use the Services control panel to restart the following services:

• LogicMonitor Collector
• LogicMonitor Collector Watchdog

To restart a collector on a Linux host, run the following commands:

To restart a collector from the LogicMonitor platform:

1. Stop LogicMonitor: /usr/local/logicmonitor/agent/bin/sbshutdown
2. Start the Watchdog service which may be run from init.d or systemd.
   • From init.d – /etc/init.d/logicmonitor-watchdog start
   • From systemd – systemctl start logicmonitor-watchdog

Collectors have the ability to cache collector data to disk. This enables collectors to store data in your environment during periods where your collector is unable to deliver data to your LogicMonitor account (example, as a result of network issues). Once your collector reaches your account again, the buffered data is communicated to our servers, eliminating any gaps in data you would have otherwise seen. By default, collector caching is enabled and configured to cache up to 30 minutes of data.

You can disable/enable collector caching by setting the reporter.persistent.enable property in the agent.conf file to false/true, respectively. By default, the property is set to true.

You can change the time the collector can cache data for by changing the value of the reporter.persistent.expire property in the agent.conf file. By default, the property is set to 30, which corresponds to up to 30 minutes of cached data. The value should not be set to any value greater than 1440 minutes, which corresponds to 24 hours (collectors restart every 24 hours and caching cannot continue after a restart).

Disk Space

The amount of disk space necessary on the collector server depends on how heavily the collector is loaded, and how long the data is cached. The following are estimates of disk space usage for various collectors, assuming 50 instances per device, an average collection interval of 2 minutes and 30 minutes of cached data:

Storing Cached Data

The cached data is stored in the /usr/local/logicmonitor/agent/bin/queues/data directory. This path may change if you did not install the collector in the default /usr/local/logicmonitor directory.

Discarding Cached Data

If the collector continues to cache data after the limit configured in reporter.persistent.expire (30 minutes by default), the oldest data will be discarded.

The amount of data that a Collector can handle depends on the Collector’s configuration and resources. You can monitor the data collection load and performance of your Collector to minimize disruption and notify when a collector is down. See Monitoring your Collectors.

If you have a large environment, and are experiencing alerts on the Unavailable Task Rate datasource of your Collectors, you may need to tune your Collector to increase its monitoring capacity.

Device Capacity Limits

The following table describes the capacity of collectors in different sizes. It is measured in requests per second (RPS) (except for Syslog, which is measured in events per second (EPS).

The capacity also depends on the number of instances that need to be discovered for each monitored device. For example, if each device is a load balancer with 10,000 instances, collector capacity will be lower. If each device is a switch with hundreds of interfaces, collector capacity may be lower because it is limited by discovery.

Collector Memory Requirements in a VM

Part of a Collector’s system memory allocation is devoted to Standalone Script Engine (SSE), which is enabled by default and used to execute script DataSources (Groovy scripts).

In general, the SSE requires half of the amount of memory allotted to the JVM. The memory requirements are not shared, rather the SSE requirement is in addition to the JVM memory requirements. If the Collector does not have this memory available, the SSE will not start and you will see “Can’t find the SSE Collector Group” in the Collector Status dialog. The Collector will work without the SSE, but Groovy scripts will be executed from the Agent instead of the SSE.

If the Collector is executed in a VM, this safeguard can be overridden because the OS indicates there is free memory. This burst memory capacity in VMs can increase memory use above the system memory requirements listed previously. Although this can happen for Collector of any size, it is far more likely to happen to small Collectors.

To disable SSE and prevent additional memory use, edit the Collector’s agent.conf:

• If the configuration setting reads groovy.script.runner=sse, change it to groovy.script.runner=agent.
• If the previous setting is not present, update the following setting: collector.script.asynchronous=false.

For more information, see Editing the Collector configuration files.

NetFlow Capacity

The following table describes the capacity of NetFlow collectors across different sizes and OS platforms. It is measured in flows per second (FPS).

Adjusting Collector Size

You can adjust the collector size from the LogicMonitor portal, especially for performance tuning and increasing the collector capacity after installing it.

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the collector whose size you want to adjust.  
3. Select the More option and then select Collector Configuration.
   
   On the Collector Configuration page, the Agent Config settings are displayed.
4. Select the collector size from the dropdown menu.
   
5. Select Save and Restart. LogicMonitor automatically verifies if your host has enough memory to support the new collector size.

If you are manually changing the collector’s config parameters, LogicMonitor runs a validity check after you select Save and Restart to ensure that no errors were made in the new configuration. If errors are detected, the missing/duplicated lines are displayed so that they can be corrected.

Small Collector

Medium Collector

Large Collector

XL Collector

XXL Collector

Minimum Recommended Disk Space

Although the Collector operates in memory, operations such as caching require available disk space on its host. The exact amount of required storage varies and depends on factors such as Collector size, configuration, NetFlow usage, number of Collector logs, and so on.

These are examples of required disk space based on these factors:

• A brand new install Collector will use about 500MiB.
• At most, Collector logs will use 800MiB.
• Temporary files (ie. upgrade files) will use less than 1500MiB.
• Report cache data will use less than 500MiB by default (this figure represents 30 minutes of cached data for a Large Collector)
• If using NetFlow the disk usage is less than 30GiB.

In total, this means Collector disk usage will be less than 3.5GiB without NetFlow and up to 33.5GiB with NetFlow enabled.

You can control the behavior of LogicMonitor collectors using configuration files. Configuration files are located in the collector’s installation directory at the following default file path:

• Linux – /usr/local/logicmonitor/agent/conf
• Windows – C:\Program Files (x86)\LogicMonitor\Agent\conf

You can view and update the settings in the collector configuration files on a per-collector basis on the LogicMonitor user interface.

It is recommended that you use the LogicMonitor user interface to update the settings in the collector configuration files instead of editing the files manually. You can manually modify the local collector configuration files at your own risk.

Editing Collector Configuration

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the collector you want to configure.  
3. Select the More option and then select Collector Configuration.
   
   On the Collector Configuration page, settings under the Agent Config tab are displayed. You can select the WatchDog Config, Wrapper Config, Sbproxy Config, and Website Config tabs to access more settings.
   
4. Manually edit the settings.
5. Select Save and Restart to restart the collector and apply the changes.

Typically, collector events include errors related to data collection tasks and the stopping/starting/restarting of the collector services.  You can look through these events to debug your collector issues.

To view collector events, follow these steps:

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the collector whose events you want to view.  
3. Select the More option and then select Collector Events.
   
   All the events associated with the selected collector are displayed on the Collector Events page.
   
   You can select a date/time range to view the events.

Grouping your collectors into logical units can streamline account management, simplify end user permission settings, improve efficiency, and more. LogicMonitor supports two types of collector groups:

• Standard collector groups
• Auto-balanced collector groups (ABCG)

Standard Collector Groups

Standard collector groups primarily assist with collector organization. For example, you can to organize collectors into groups based on any of the following shared characteristics:

• Physical location – If you have infrastructure across multiple data centers or offices, grouping collectors based on their locations can simplify assigning collectors throughout your account (e.g. when devices are added).
• Customer – If you’re an MSP, grouping collectors by customer can make it easier to quickly find a particular collector, and additionally simplifies the collectors page display when you have a large number of collectors in your account.
• Environment – You may want to group collectors based on whether they are in a development, QA, production, or other environment. This will enable you to set user role permissions per group, to ensure that your team members have the appropriate access.

Auto-balanced Collector Groups

Auto-Balanced Collector Groups (ABCGs) provide functionality beyond organization. The collectors in an ABCG share device load, allowing for dynamic device balancing, scaling, and failover.

Adding Collector Group

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the Add Collector Options dropdown.
3. Select Add Collector Group.
   
4. Toggle the Auto Balanced Collector Group option to enable auto balancing for the collector group. Auto-balancing allows you to share device load among a group of collectors.
   
5. Enter a name and description of your new collector group.
6. Define the key and value pair to add properties on your collector that can then be tokenized in collector-related alert messages. This is particularly useful for routing collector down, failover, and failback alerts through an external ticketing system.
   For example, your team in Austin is responsible for a specific subset of collectors. To ensure the Austin team is properly notified in the event one of their collectors goes down, you can assign these collectors a custom property. Once assigned, the property can be tokenized (##team##), and used to route alerts to the proper team via your organization’s ticketing system. The token is substituted with the property value at the time of generation so that the alert or integration delivery can include dynamic information.
7. If you designated your new group as an Auto-Balanced Collector Group, the Rebalance Threshold – Instance Count option is displayed. You can adjust the threshold instance count.

Moving a Collector to Collector Group

Collectors are assigned to collector groups at the time collectors are added. As your LogicMonitor deployment evolves over time, it is likely you’ll want to move collectors among groups to suit new organizational needs, create auto-balanced groups, and so on. To move collectors from one collector group to another, navigate to Settings > Collectors. From the Collectors page, either:

• To move collectors in bulk – Select the checkbox on the table header to select all the collectors and select Actions > Move selected items to Group and then confirm your action.
  
• To move a single collector – Select the Manage icon of the collector you want to move and then select a new group in the Collector Group field.
  

Moving Collectors Between Standard and ABCG

Collectors function very differently depending upon whether they are members of a standard collector group or an Auto-Balanced Collector Group (ABCG). Collectors in a standard group operate independently of one another and each manually designates a static failover collector. Collectors in an ABCG dynamically fail over to other collectors in the ABCG, thus requiring no manually designated failover collector. This becomes an important distinction when moving collectors between these two collector group types. You must consider the following points:

• Moving from standard collector group to ABCG. When moving a collector out of a standard collector group to an ABCG, note the following:
  • The collector’s Failover Collector designation will be discarded. ABCGs employ a dynamic rebalancing algorithm upon collector failover; they don’t rely upon a one-to-one manual failover designations between collectors.
  • There are several characteristics collectors belonging to the same ABCG must share.
  • You decide whether the devices currently monitored by the collector should be immediately enabled for auto balancing. Upon moving, you’ll be presented with the Do not auto balance monitored devices option. This option, when selected, leaves the devices assigned to their current collector, allowing you to manually enable the devices on a case-by-case basis for participation in auto balancing.
• Moving from ABCG to standard collector group. When moving a collector out of an ABCG to a standard collector group, it’s important to remember that the collector has no failover designation. You’ll need to open its settings and assign one from the Failover Collector field.

Managing Collector Groups

You can edit or delete collector groups from the collectors page.

1. On the Collectors page, select the collector group that you want to edit or delete.
2. Select the Manage icon.
   
   The Manage Collector Group page is displayed.
   
   After updating, save the changes.
   To delete the collector group, select Delete.

LogicMonitor Collector monitors your infrastructure and collects data defined by LogicModules for each resource in that location. You do not need to install Collector on every device, instead one Collector on a server can be used to monitor all the resources in that location. See About the LogicMonitor Collector.

Installing Collector in a Container

LogicMonitor also supports installing and running Collector in a Docker container. Installation of a containerized Collector does not support all install options. For example, you can only run the full installation, not the bootstrap, and you will need to run the Collector process as root. See Installing the Collector in a Container.

Installation Settings

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the Add Collector Options dropdown.
3. Select Add Collector.

Follow the steps given on the Add Collector page to complete and verify the collector installation.

Selecting Device to Install Collector

The first step in adding a Collector is deciding which device will host the Collector.

For each location of your infrastructure, we recommend that you install a Collector on a Windows or Linux server that is physically close to or on the same network as the resources it will monitor. Most often, Collectors are installed on machines that function as syslog servers or DNS servers.

To ensure reliability, the Collector should not communicate across the internet to poll resources in another datacenter, through firewalls or network address translation (NAT) gateways.

Collector Server Requirements

The following table lists general requirements for choosing a server to host the Collector.

Monitoring Collector Performance

We recommend that you select the Monitor the Device on which the collector is installed checkbox. This will allow you to keep track of the CPU utilization, disk usage and other metrics to ensure that the Collector is running and keeping up with its data collection load. See Monitoring Your Collectors.

You may also assign the Collector device into a Device Group. If you leave the device “Ungrouped”, LogicMonitor will automatically add it to the dynamic group “Collectors”. See Device Groups Overview.

Selecting Collector

The next step in adding a Collector is specifying the type, version, and the monitoring capacity (size) for the Collector you will install onto your server. You may also assign the new Collector to a Collector Group.

Selecting Collector Type

Select the appropriate Collector download file for your server: Linux or Windows. For both Windows and Linux, we support only 64-bit Operating System. The type of Collector you choose to install depends on the resources it will monitor. For example, to collect data from Windows devices, you need to install the Collector on a Windows server.

Selecting Collector Version

Select from the available General Release and Early Release Collectors.

You can always change the version by uninstalling and installing a new Collector.

Selecting Collector Size

The Collector size refers to the monitoring capacity for the Collector. The number of resources that a Collector can monitor depends on the data collection method that it uses (such as SNMP, JDBC, WMI, and so on). See Collector Capacity.

You can choose from four available Collector sizes:

Assigning Collector Group

You may assign the new Collector to an existing Collector Group or create a new group. Collector Groups pool your Collectors based on their physical locations, defined environments (QA, Development, or Production), or if you are an MSP customer and streamlines the configuration and management of multiple Collectors. See Collector Groups.

Downloading and Installing Collector

This step provides options for you to download the installer file for the collector you selected.

Selecting Installer Package

You have to choose between two installer packages:

• Bootstrap – It downloads a smaller installation package (~500kB) for a faster install using the LogicMonitor CDN.
• Full Package – It downloads the installation package which is approximately 200MB.

Installing Windows Collector

Starting with EA Collector 37.100, the default installation method for Windows collector will use a non-admin user logicmonitor as the new collector service user. This user is automatically created with all the necessary permissions.

1. Download the installer file directly to your Windows server or use one of the download command options.
   For Windows, we provide options to download and install using PowerShell or a URL. Click on the option to copy the download command to your clipboard and then run it on your server.
2. After downloading, open it to start the Install Shield Wizard.

The Install Shield Wizard will extract the binary and prompt you for credentials. These credentials will correspond to the account that the Collector will run under, which may be Local System or a domain account with local administrator permissions.

• If this Collector is not monitoring other Windows systems, run the service as Local System.
• If this Collector is monitoring other Windows systems in the same domain, run the service as a domain account with local administrator permissions.
• If this Collector is monitoring other Windows systems and they are not part of the same domain, run the service as a local administrator and connect to each resource with local administrator credentials. You may choose to set up the password so that it doesn’t expire, to reduce authentication issues between the Collector and its monitored resources. See Credentials for Accessing Remote Windows Computers.

The LogicMonitor Collector service must be granted “Log on as a service” under “Local Policy/User Rights Assignment” in the Windows server’s local security policy settings. See Troubleshooting Windows Collectors.

If the Windows server is running antivirus software, you will need to add a recursive exclusion for the LogicMonitor Collector application directory. See About the LogicMonitor Collector.

Installing Linux Collector

Prerequisites to install a Linux Collector are as follows:

• For Collectors running version 28.500 (or higher numbered versions), the Bourne shell is required for the Linux installation script. You may need to install the vim-common package to get the xxd binary that the installer depends on.
• For Collectors running version 28.100 (or higher numbered versions), the sudo package must be installed on Linux when running the Collector as a non-root user. The installer will also make additions to /etc/sudoers to handle service restart and memory dumps.
• In Linux environments with the Collector running in containers, the Collector must run as root: suid root is /bin/ping.

1. Download the installer file directly to your server (if your server supports web browsing) or onto another server and use a file transfer option (such as scp) to copy it to the server where you will install the collector.
   For Linux, we also provide options to download and install using cURL or Wget. Click on the option to copy the download command to your clipboard and then run it on your server.
2. After downloading the installer onto your Linux server, change the permissions to make the binary executable.
   # chmod +x <installer-file>.bin
3. Run the executable.
   # ./<installer-file>.bin

When the installation is complete, you will see a message that it installed successfully. You can now start adding resources to be monitored.

Verifying Connection

After successfully installing the Collector on your Windows or Linux server, return to the Add Collector page in LogicMonitor and verify that the Collector is connected to your portal.

Collector Hostname

Each Collector has a name or ID that is registered with the LogicMonitor server when you download the Collector. The Collector’s hostname refers to the IP address or DNS name of the server that the Collector has been installed on.

• For Linux, the Collector will resolve the hostname by running the hostname -f or hostname commands. If both commands fail, the hostname defaults to: localhost.localdomain.
• For Windows, the hostname is a combination of the domain and computername.

Initially, you could run Linux Collectors using root credentials. Later, we extended this support to users with non-root credentials to install Collectors.

We have now enhanced the migration process to enable users to migrate Collectors running as root to run under non-root users without uninstalling Collector or losing any data. You can follow both prompt based and silent migration processes to migrate Collectors running as root to run under non-root user.

You must run the script updateToNonRoot.sh. The default path is, /usr/local/logicmonitor/agent/bin/updateToNonRoot.sh

Requirements

• Users with root credentials can execute the script.
• Ensure that the Collector is installed as a root user.

Points to Consider

• In case of silent migration, you must place the parameters in the following sequence: -q -u -d. 
• When migrating Linux Collector using the silent migration method, to access help you can enter the parameter -h after the script ./updateToNonRoot.sh. The following parameters are displayed:

Migrating Linux Collectors

You can migrate Linux Collector from root to non-root user using the silent or prompt based migration method. Note that when you install Linux Collector using any of the two installation methods, LogicMonitor creates a default non-root user ‘logicmonitor’. When migrating Linux Collector from root to non-root user, if the non-root user that you specified for migration does not exist, the ./updateToNonRoot.sh script will create that non-root user.

Silent Migration

In the command prompt, run the following commands:

1. Log in to the machine with root credentials.
2. Navigate to the agent/bin folder of your Collector.
3. Enter and run the command ./updateToNonRoot.sh followed by the parameters for silent migration. The format and sequence is -q -u [non-root username] -d [custom path, if any]

After you run the script, the Linux Collector is migrated from root to non-root. 

Prompt based Migration

In the command prompt, run the following commands:

1. Log in to the machine with root credentials.
2. Navigate to the agent/bin folder of your Collector.
3. Run the script ./updateToNonRoot.sh.
   The system will prompt you to specify the user to migrate the Collector to non-root.
4. The script will create a default non-root user ‘logicmonitor’ and use it. You can create and use your own non-root user account, if necessary.
5. By default, the Collector is located at /usr/local/logicmonitor. If the Collector is located at some other directory, then specify that path.
   After you run the script, the Linux Collector is migrated from root to non-root. 

Verifying Migration

To verify if the Collector has successfully migrated from root to non-root, follow these steps 10 minutes after the migration is complete:

1. In LogicMonitor, navigate to Collectors and search for the Collector ID which you migrated to non-root user.
2. In the Manage column corresponding to the specific Collector, click the Settings icon. The Manage Collector dialog box is displayed. 
3. Click the Support drop-down and select Collector Status.

Rolling Back Migration

In case the updateToNonRoot.sh script fails to migrate Linux Collector from root to non-root, or if you face any issue after migration, you can run the revertToRootUser.sh script to roll back migration. The script is available in the agent/bin folder.

#!/bin/sh
 
# get the name of init process
get_init_proc_name() {
    file_name="/proc/1/stat"
    cat $file_name|cut -f1 -d')'|cut -f2 -d'('
}
 
# get a string as answer from the stdin
get_input() {
    prompt_msg=${1:?"prompt message is required"}
    default_value=${2}
    if [ "$default_value" != "" ];then
        prompt_default_value=" [default: $default_value]"
    fi
    read -p "$prompt_msg$prompt_default_value:" value
    if [ "$value" = "" ];then
        value=$default_value
    fi
    echo $value
}
 
help() {
    echo "Usage : [-h] [-y] [-u install user] [-d install path]
            -h        help           - show this message
            -y        silent-update  - update silently
            -d        install path   - installation path of collector(default: /usr/local/logicmonitor)"
    exit 1
}
OPTS_SILENT=false
DEST_USER="root"
DEST_DIR="/usr/local/logicmonitor"
DEST_GROUP="root"
 
while getopts "hqu:d:" current_opts; do
 
    case "${current_opts}" in
        h)
            help
            ;;
        q)
           OPTS_SILENT=true
            ;;
        d)
           DEST_DIR=${OPTARG}
            ;;
        *)
            help
            ;;
    esac
done
 
 
if [ "$OPTS_SILENT" != "true" ]; then
  DEST_DIR=`get_input "Enter the directory under which collector is installed" "$DEST_DIR"`
fi
 
if [ -d "$DEST_DIR/agent" ]; then
 
    service logicmonitor-watchdog stop
    service logicmonitor-agent stop
 
    systemctl disable logicmonitor-agent.service
    systemctl disable logicmonitor-watchdog.service
 
    CUR_USER=$(stat -c '%U' $DEST_DIR)
 
    if [ "$CUR_USER" != "root" ]; then
     LM_WATCHDOG_SERVICE="$DEST_DIR/agent/bin/logicmonitor-watchdog.service"
     sed -i.bak "s#User=$CUR_USER#User=root#g" $LM_WATCHDOG_SERVICE
     sed -i.bak "s#Group=$CUR_USER#Group=root#g" $LM_WATCHDOG_SERVICE
     rm -f $LM_WATCHDOG_SERVICE.bak
     LM_AGENT_SERVICE="$DEST_DIR/agent/bin/logicmonitor-agent.service"
     sed -i.bak "s#User=$CUR_USER#User=root#g" $LM_AGENT_SERVICE
     sed -i.bak "s#Group=$CUR_USER#Group=root#g" $LM_AGENT_SERVICE
     rm -f $LM_AGENT_SERVICE.bak
    fi
 
    $ldconfig
 
    chown  $DEST_USER:$DEST_GROUP $DEST_DIR/
    chown -R $DEST_USER:$DEST_GROUP $DEST_DIR/agent
 
    INIT_PROC=`get_init_proc_name`
 
    if [ "$INIT_PROC" = "systemd" ];then
      mkdir /etc/systemd/user
      cp $DEST_DIR/agent/bin/logicmonitor-agent.service /etc/systemd/system
      cp $DEST_DIR/agent/bin/logicmonitor-watchdog.service /etc/systemd/system
      chown $DEST_USER:$DEST_GROUP /etc/systemd/system/logicmonitor-agent.service
      chown $DEST_USER:$DEST_GROUP /etc/systemd/system/logicmonitor-watchdog.service
      chmod 0644 /etc/systemd/system/logicmonitor-agent.service
      chmod 0644 /etc/systemd/system/logicmonitor-watchdog.service
      systemctl enable logicmonitor-agent.service
      systemctl enable logicmonitor-watchdog.service
      rm -f /etc/systemd/user/logicmonitor-watchdog.service
      rm -f /etc/systemd/user/logicmonitor-agent.service
      systemctl daemon-reload
      echo "Succesfully reverted collector services to run under $DEST_USER"
 
    else
      ln -sf ./bin/logicmonitor-agent /etc/init.d/logicmonitor-agent
      ln -sf ./bin/logicmonitor-watchdog  /etc/init.d/logicmonitor-watchdog
      chown $DEST_USER:$DEST_GROUP /etc/init.d/logicmonitor-agent
      chown $DEST_USER:$DEST_GROUP /etc/init.d/logicmonitor-watchdog
 
      /sbin/chkconfig --add /etc/init.d/logicmonitor/logicmonitor-agent 2>/dev/null
      /sbin/chkconfig --add /etc/init.d/logicmonitor/logicmonitor-watchdog 2>/dev/null
 
      #if update-rc.d exists, let's run it to install our services
      if which update-rc.d 2> /dev/null;then
        # We found update-rc.d, let's use it ...
         update-rc.d logicmonitor-agent defaults 2>/dev/null
         update-rc.d logicmonitor-watchdog defaults 2>/dev/null
      fi
      echo "Succesfully reverted collector services to run under $DEST_USER"
 
    fi
 
 
 
 $DEST_DIR/agent/bin/logicmonitor-watchdog start
 
else
  echo "The agentPath is not $DEST_DIR or is not provided. Please provide correct path where collector is installed and run the script again."
fi

Previously, you could monitor Windows devices only through Windows Collector. LogicMonitor has now developed the ability to monitor Windows devices using Linux Collectors. You can continue to perform WMI tasks on Linux Collectors. Linux Collectors have the ability to perform tasks for both the Operating Systems.

This feature is cost-effective as you need not buy a licensed copy of Windows server for Collector, thereby reducing your LogicMonitor onboarding and adoption cost. 

Requirements

• OpenSSL version 1.0.x or 1.1.x.
• x64 (64-bit) Linux machine supported by OMI.
  • CentOS 6, 7, and 8 
  • Debian 8, 9, and 10
  • Oracle Linux 5, 6, 7, and 8
  • Red Hat Enterprise Linux Server 5, 6, 7, and 8
  • SUSE Linux Enterprise Server 11, 12, 12 ppc, and 15
  • Ubuntu 14.04 LTS, 16.04 LTS and 18.04 LTS, and 20.04 LTS
• Collector version 10000.100. It is a special Beta version and should be used only for this Beta. It will not be supported in the production environment. To access this version, see Installing Collectors.
• Root permission to install Open Management Infrastructure (OMI) server during Collector installation.

Points to Consider

• As part of the Collector installation process, OMI will be installed on your Linux machine.
• SBProxy is replaced with OMI server installed on Linux Collector.
• The following OSS dependency and the license it is shipped under is given in the table:

WMI Credentials

Provide username and password as a device-level property.

• Username = wmi.user
• Password = wmi.pass

Enter username in the username@domain format to pass the domain name in the username.

agent.conf Configuration Parameters

You should configure the following parameters:

Basic Authentication

By default, basic authentication (only over HTTPS) Port 5986 will be disabled on WinRM configuration of the remote host. To enable it, perform the following steps on the remote monitored host in cmd_prompt:

1. winrm quickconfig
2. winrm set winrm/config/service/auth @{Basic=”true”}

You need not install any additional packages for basic authentication. However, an HTTPS listener must be created/enabled on the Windows devices. If you do not have HTTPS listener created for WinRM, follow the steps given below to set Windows devices with basic authentication.

Create an HTTPS Listener using Self-Signed Certificate

To create an HTTPS listener for WinRM, perform the following steps:

1. Run the command WinRM e winrm/config/listener in cmd_prompt to check if port 5986 is already enabled on WinRM service.
2. Create a new self-signed certificate using PowerShell.
   New-SelfSignedCertificate -DnsName “<YOUR_DNS_NAME>” – CertStoreLocation Cert:\LocalMachine\My
   Note: The DnsName is your computer’s full name. You can find it under Control Panel > System and Security > System > Full computer name.
3. Copy the thumb print and run the following command in cmd_prompt.
   winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”<YOUR_DNS_NAME>”; CertificateThumbprint=”<COPIED_CERTIFICATE_THUMBPRINT>”}
4. To verify if the listener is created, run the command WinRM e winrm/config/listener in cmd_prompt to print details of port 5985 and 5986.
5. To add a new firewall inbound rule to allow all connections for port 5986 (TCP), follow these steps:
   1. Search and select the Windows Firewall with Advanced Security option. The Windows Firewall with Advanced Security window is displayed.
   2. In the left navigation, right-click Inbound Rules and select New Rule. The New Inbound Rule Wizard window is displayed.
   3. Select the Port radio button and click Next.
   4. Select the TCP radio button.
   5. Select the Specific local ports radio button and enter 5986 in the blank field. Click Next. 
   6. Select the Allow the connection radio button and click Next.
   7. Select the Domain, Private, and Public checkboxes and click Next.
   8. Enter a rule name in the Name field and click Finish.

Enable Windows Monitoring when Installing Linux Collectors

1. Follow the instructions given in Installing Collectors to install Linux Collector. Once the Collector is successfully installed, the system will display a message if you want to enable Windows monitoring. Note that by default, Windows monitoring is NOT enabled on Linux Collector.
   
2. Press Y to install packages required to monitor Windows devices through Linux Collector.
3. To enable Linux Collector to monitor Windows devices, in agent.conf settings, manually set the linux.collector.enable.windows.monitoring as ‘true’.

You can integrate LogicMonitor Collector with CyberArk Vault to store sensitive information such as login credentials, keys, and other sensitive data for hosts, devices, services, and more. In addition to a single account, CyberArk Vault also supports Dual Account to eliminate any edge case delays that may occur using a single account such as data collection loss and locking of accounts that could occur during the password rotation process.

Requirements

To integrate LogicMonitor Collector with CyberArk for Dual Account, you must fulfil the following requirements:

• EA Collector version 32.200 or later.
• Two CyberArk accounts with similar privileges. The VirtualUsername for both the accounts must be the same.
• One of the two CyberArk accounts must be marked as active in the CyberArk portal. CyberArk should handle this automatically during the password rotation.

CyberArk Application Authentication Methods

LogicMonitor Collector and CyberArk integration support the following methods for the application authentication:

• Allowed machines
• Path
• Hash
• Client certificates

Out of these four methods, we have explained the Client certificate method in the Configuring CyberArk Certificates section.

Authentication to Privileged Access Security (PAS) Solution

The CyberArk AIMWebService application is deployed on the IIS Server. LogicMonitor Collector and CyberArk integration uses Basic authentication to the IIS Server.

You should use the password provided to you to log in to the Vault. After logging in, we recommend that you change your password.

Collector Agent Configuration Settings for CyberArk Integration

The following table contains Collector agent configurations for the Dual Accounts:

Configuring Vault Properties

You must configure Vault properties that include Vault metadata and Vault keys for the Collector at the device or device group level.

Configuring Metadata Properties

You must configure the following Vault metadata properties.

Configuring Vault Keys

Vault keys need to be specified at the device level with the suffix .lmvault. For example, ssh.user information should have the key specified as ssh.user.lmvault. You must configure the following Vault keys.

LogicMonitor Collector and CyberArk Vault Integration

• Multi-Safe support: Specify multiple Safes under a device to retrieve credentials from Multiple Safes. 
• Multi-Vault support: You can use multiple Vaults for the devices under a Collector. Each of the devices can point to a single Vault. 
• You can call Vault API over HTTP or HTTPS. However, if you call the Vault APIs over HTTPS, you must configure the RootCA cert. For more information, see RootCA cert.
• You must complete CyberArk authentication. For more information, see CyberArk Application Authentication Methods section. 

• For CyberArk Dual Accounts, along with the existing parameters, the CyberArk API call requires two additional parameters: ‘DualAccountStatus’ and ‘VirtualUsername’. See the Dual Account Properties section on the CyberArk Dual Account page.
• For CyberArk Dual Accounts, the property can be specified at the device or device group level.
• You must set the Dual Account properties such as VirtualUsername at each property level on the device.
• When a Dual Account is enabled for CyberArk Vault, then based on the template of the account the response parsing can be done for various fields in the response.