Best Practices Guide

Following are some best practices recommended for optimum functioning of ManageEngine OpManager Distributed Edition.

• Hardware and Software Requirements
• Configuring OpManager for Performance
• Discovery Configuration
• Monitoring Configuration
• Mapping Configuration
• Security and Authentication
• Alerting
• Database Tuning
• Java Heap Size

Hardware and Software Requirements

Having the right hardware and software resources on a system, enables better performance of the application installed on that system. Make sure the specified System Requirements are met for OpManager to perform effectively.

Configuring OpManager for Performance

Certain parameters can be fine-tuned depending on the environment. While most configurations are exposed via the user interface, few other changes are effected in the configuration files and some database tables manually. Module-wise configurations and recommended values are listed below:

Discovery Configuration in Probe:

Before Discovery:

OpManager relies on other communication protocols such as SNMP, WMI, Telnet, and SSH for classification and monitoring. So make sure the following two configurations are done before triggering discovery:

1. Configuring the relevant SNMP, WMI, and CLI credentials
2. Defining Device Templates

Configuring Discovery Parameters

OpManager pings the devices for discovery and further for determining availability, and 4 ping packets are sent by default. If there is network latency, it is possible that some devices are not discovered, or post discovery, they are not polled for status. This can be addressed by configuring few ping parameters.

Steps:

1. From <opmanager-home>/conf folder open the file ping.properties.

2. Uncomment (remove the # symbol) against the timeout parameter and specify the ping timeout depending on the latency.

3. Similarly, you can increase the number of ping retries by configuring the value for retries parameter. Make sure you uncomment this parameter too for the configuration to be effected.

4. Save the changes to the file.

5. OpManager service requires a restart when changes are made to this file. So, restart OpManager for the changes to be effected.

Note: The above configuration is recommended only if there is latency.

Monitoring & Data-collection Configuration in Probe

• Addressing SNMP Timeout

• Data-collection

• Database connections

• Disabling unnecessary polling

• Monitoring Intervals

Addressing Timeout Issue

The default SNMP query timeout to variables in a device is 5 seconds. If there is a delay in the agent response for some devices, you can globally increase the SNMP timeout as follows:

Steps:

1. From <opmanager-home>/conf folder, open the file NmsProcessesBE.conf

2. Look for the following default entry in this file:

PROCESS com.adventnet.nms.poll.Collector

ARGS POLL_OBJECTS_IN_MEMORY 25 POLL_JDBC true MAX_OIDS_IN_ONE_POLL 15

AUTHORIZATION true DATA_COLLECTION_QUERY_INTERVAL 120000 PASS_THRO_ALL_POLLING_OBJECTS true CLEAN_DATA_INTERVAL 999999

3. Include the additional parameter DATA_COLLECTION_SNMP_TIMEOUT 15 .

Now the changed entry will be as shown below:

PROCESS com.adventnet.nms.poll.Collector

ARGS POLL_OBJECTS_IN_MEMORY 25 POLL_JDBC true MAX_OIDS_IN_ONE_POLL 15

AUTHORIZATION true DATA_COLLECTION_QUERY_INTERVAL 120000 PASS_THRO_ALL_POLLING_OBJECTS true CLEAN_DATA_INTERVAL 999999 DATA_COLLECTION_SNMP_TIMEOUT 15

4. Save the changes and restart OpManager Service.

Data Collection in the Probe

By default, OpManager Probe uses 12 threads for SNMP polling and 12 threads for WMI polling.

SNMP Data-collection

The assumption is that each monitored device has a minimum of 10 polled data (monitored resources such as cpu, memory, disk size etc). Each interface object has 11 polled data which include incoming traffic, outgoing traffic, Bandwidth Utilization, Errors, Discards etc. Depending on the number of polled data, you can increase the number of datapoll threads.

Steps:

1. From <opmanager-home>/conf folder, open the file threads.conf

2. Increase the value of datapoll threads from 12 to the required number of threads for SNMP polling.

3. Save changes and restart OpManager Service.

Following is a reference table to increase the number of threads:

Note : Enable monitoring only for the required interfaces from the device snapshot Template page using the option Actions > Configure Interfaces. You can enable/disable polling for all interfaces of a specific type from Admin > Interface templates > Required template.

WMI Data-collection

(Includes Resource monitors, Windows Service Monitors, AD monitors, MSSQL monitors,

Exchange monitors. Assumption is around 50 polled data per monitored Windows device)

Steps:

In the file <opmanager-home>/conf/threads.conf, increase the value of WMI_EXEC from 12 to the required

number of threads for WMI polling.

Viewing Polled Data

You can view the polled data by querying the database. Here are the steps:

1. From the command prompt, change directory to <opmanager-home>/mysql/bin
2. Connect to MySQL as follows: For central server: mysql -u root -P 23306 centraldb For Probe: mysql -u root -P 33306 dmsdb 
3. Now execute the following query to see the number of Polled data for the monitored devices with the protocol information (SNMP, WMI, CLI etc): select count(*) from PolledData where PROTOCOL='SNMP';

In the PolledData table, following are a few columns you may want to understand:

• NAME- the name of the polleddata (the monitored resource)
• AGENT- the device in which the resource is monitored
• ID - a unique ID for each polleddata
• PROTOCOL- the monitoring protocol which could be SNMP for SNMP polling, WMI for WMI polling, CLI for Telnet/ SSH polling, SPOLL - for pings to devices to determine availability

Database Connection Pool

If the number of Polled Data is over 50000, the number of non-transaction connections can be increased in the range of 7 to 10 (default being 6 connections). Here is how you configure:

Steps

1. From <opmanager-home>/conf folder, open the file database_params.conf.

2. Increase the value of NON_TRANS_CONNECTIONS parameter to the required number.

3. Save changes and restart OpManager Service.

Disabling Unnecessary Polling

During scheduled maintenance

Whenever a maintenance is scheduled in the network for some devices, you can suspend polling for those devices by scheduling downtime in OpManager . This prevents unnecessary requests to network resources resulting in false alerts. There will be improved performance as the devices covered in the scheduled do not use the data poll threads.

Disabling polling for a category:

From Admin > Monitoring Intervals, remove selection for the category for which you want to disable polling.

Monitoring Intervals

OpManager allows you to set different monitoring intervals for different categories. You can also disable polling for a device category like say, Desktops. Monitoring intervals can be varied for individual devices too.

Specifying Polling Intervals for Devices:

From Admin > Monitoring Intervals, configure a smaller monitoring interval for critical categories like servers or routers and space out for the other categories like printers etc. The recommended interval for very critical devices is 5 minutes, while you can set a minimum of 1 minute interval also for a very few devices.

Specifying Monitoring Intervals for Resources (CPU, Memory, Disk etc):

The resources critical to a device's availability can be polled more frequently, with the minimum configurable interval being 1 minute, while the other resources can be polled less frequently.

Effecting Device-specific monitoring Configurations:

From the device snapshot page, select Actions > Monitoring and configure the required interval.

Mapping Configuration

Create new device templates or modify existing templates to accommodate and classify new device types correctly into the relevant category. When creating new business views or infrastructure views , it is recommended that view names are created without special characters like $, # etc.

Business views are created to logically group devices usually based on geography, or for assigning it to a particular operator/technician. Infrastructure views are created to group devices of a new category, which cannot be ideally classified into the existing infrastructure views. Example: Environment Sensors, IPPhones etc.

Security and Authentication

Installing and Starting

The user account with which you install OpManager should have full permission on all folders/sub-folders on the installation directory. Make sure the account has a secure password. Also, you can run OpManager only with the user account with which you installed the application.

Securing Admin Account

The default user created with full permission is admin with the password also as admin. Make sure you change the password once you login.

Restricting Users Scope

You can create user accounts and restrict their scope by assigning full permission or read-only access for all or part of the devices. This is done by creating business views and assigning users with relevant permissions to the users.

Alerting

OpManager sends SNMP, CLI, or WMI queries to devices for monitoring. So, ensure that the monitored devices do not restrict requests coming in from OpManager. If the devices are behind a firewall, the relevant ports must be opened, and also access lists on routing devices must be verified.

SNMP Traps

Trap Processors must be configured for new trap types. These traps are usually marked as unsolicited traps under alarms in OpManager. Once parsers are configured, meaningful alerts are generated from the traps.

Device Dependencies

False alerts are triggered when a set of monitored devices are behind another device (a firewall, router etc). The requests sent to the devices are routed through the firewall or router, and in the event of these dependent devices being down, all devices behind this dependent devices are deemed as down. Configuring device dependencies will prevent unnecessary polling to the devices behind the dependent device.

Proxy-settings

When monitoring URLs for availability, the requests to the URLs are sent through a proxy. So, this mandates proxy server settings configuration in OpManager. If the requests to certain URLs are direct and does not require to go through a proxy, the hostnames, or the IP Address of the devices must be specified in the No Proxy for field.

Notification Profiles

Make sure that correct mail server details are configured to enable all email-based notifications. The secondary mail-server settings must be configured if there is one. It is recommended that when creating notification profiles, the profile names do not contain special characters, space etc.

Database Tuning

Configuring MySQL Parameters

OpManager comes bundled with MySQL as the default database. Depending on the RAM of the server in which OpManager is installed, you can set the values of the MySQL parameters to perform to its capacity.

You can configure these MySQL parameters with the required values in <opmanager-home>/bin/startMYSQL.bat script. Here is how you pass these parameters:

Open the startMYSQL.bat in a notepad. The startMysql.bat file consists of three different configurations in it.

The user can uncomment the appropriate configuration, based on the system's configuration. For enabling a particular configuration:

1. Remove the word “rem” before “@start” for the configuration of your choice.
2. Add the word “rem” before “@start” of other configurations.
3. Save the file and restart OpManager.

The following is the default mysql configuration for a machine with 1 GB RAM,

rem Settings for 32 bit machine, 1GB RAM

@start /B mysqld-nt --defaults-file=..\data\my.cnf --basedir=..\ --port=%DB_PORT% --datadir=..\data --tmpdir=..\tmp --set-variable=query-cache-type=1 --read_buffer_size=2M --read_rnd_buffer_size=2M --sort_buffer_size=2M --join_buffer_size=2M --myisam_sort_buffer_size=10M --myisam_max_sort_file_size=30M --key_buffer_size=200M --bulk_insert_buffer_size=20M --innodb_buffer_pool_size=100M --query_cache_size=100M --max_heap_table_size=20M --tmp_table_size=20M --innodb_flush_log_at_trx_commit=2 --language=..\share\english\ --skip-bdb --skip-ndbcluster --skip-external-locking –log-warnings

There are similar configurations commented out for machines with 2 GB and 4 GB RAM.

Increasing Java Heap Size

OpManager Java Heap Size can be increased based on optimization requirements by editing the value of

-Xms/-Xmx parameter in StartOpManagerServer.bat/sh script or by editing the file

<opmanager-home>/conf/wrapper.conf (Initial/Maximum Java Heap Size). The recommended JVM Heap Size is:

Wish you a successful deployment. Feel free to get in touch with our support for technical assistance.