ManageEngine OpManager

Best Practices Guide

Following are some best practices recommended for optimum functioning of

ManageEngine OpManager.

• Hardware and Software Requirements

• Configuring OpManager for Performance
o Discovery Configuration
o Monitoring Configuration
o Mapping Configuration
o Security and Authentication
o Alerting
o Database Tuning
o 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
requirements are met for OpManager to perform effectively. Here are the specs:

Number of Processor RAM Hard Supported

devices/interfaces Disk Operating
Systems

Upto 100 devices/ 1.7 GHz 1GB 20 GB or higher Windows 2000

1000 interfaces or higher
including
Windows Vista
100-250 devices/ 2.4 GHz 2GB
1K -3K interfaces

250-500 servers/ 3.4 GHz 2GB

3K-5K interfaces

500-1000 servers/ 2*3.4GHz 4GB Linux: RedHat

5K to 10K interfaces 7.x and above,
Debian 3.0
1000 servers and above/ 4*3.4GHz 8GB
Over 10K interfaces

1
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

Before Discovery

OpManager relies on other communication protocols 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/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

• 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:

2
Steps

1. From /opmanager/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

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

SNMP Data-collection

The assumption is that each monitored device has a minuimum of 10 polled data
(monitored resources such as cpu, memory, incoming traffic, out-going traffic, errors
etc). Each Interface object has 11 polleddata which include RxTraffic, TxTraffic,
Bandwidth Utilization, Errors, Discards etc. Depending on the number of polleddata, you
can increase the number of datapoll threads.

Steps

1. From /opmanager/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:

Number of Hardware Number of Number of Monitoring

devices/interface datapoll SNMP Polled Interval
Threads Data

Upto 500 servers/

2*3.4GHz, 4GB 12 (default) Upto 50000 15 mins
5000 interfaces

More than
50000:
Beyond the above 4*3.4GHz, 4GB
13 - 20 Additional 1 15 mins
numbers to 8 GB
thread for every
5000 polleddata

3
Note : Enable monitoring only for the required interfaces from the device snapshce
Templaot page using the option Actions > Configure Interfaces. You can enable/disable
polling for all interfaces of a specific type from Admin > Interfates > 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 /conf/threads.conf, increase the value of WMI_EXEC from 12 to the required
number of threads for WMI polling.

Number of Number of Number of WMI Monitoring

devices Threads PolledData Interval

100 12 Upto 5000 15

More than 100 13 - 18 Over 5000 15

Viewing PolledData

You can view the polleddata by quering the database. Here are the steps:

1. From the command prompt, change directory to /opmanager/mysql/bin

2. Connect to MySQL as follows:

mysql -u root -P 13306 opmanagerdb

3. Now execute the following query to see the number of PolledData 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:

o NAME- the name of the polleddata (the monitored resource)

o AGENT- the device in which the resource is monitored
o ID - a unique ID for each polleddata
o 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 PolledData 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:

4
Steps

1. From /opmanager/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
mininum 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.

5
Business views are created to logically group devices such as based on geography, or for
assiging 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.

Enabling SSL

OpManager supports enabling SSL for WebClient , securing the web access. Make sure
you are on Build No.7010 or higher.

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
unncessary polling to the devices behind the dependent device.

6
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.

Parameter On 1GB RAM On 2GB RAM 4GB RAM

read_buffer_size 2 MB 5 MB 10 MB

read_rnd_buffer_size 2 MB 5 MB 10 MB

key_buffer_size 200 MB 250 MB 400 MB

query_cache_size 100 MB 130 MB 200 MB

max_heap_table_size 20 MB 50 MB 100 MB

innodb_buffer_pool_size 100 MB 150 MB 200 MB

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

Open the startMYSQL.bat in a notepad and include the following entries as MySQL start-
up parameters:

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

7
rem Settings for 32 bit machine, 2GB 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=5M --read_rnd_buffer_size=5M --sort_buffer_size=5M --
join_buffer_size=5M --myisam_sort_buffer_size=50M --
myisam_max_sort_file_size=50M --key_buffer_size=250M --
bulk_insert_buffer_size=50M --innodb_buffer_pool_size=150M --
query_cache_size=130M --max_heap_table_size=50M --tmp_table_size=50M --
innodb_flush_log_at_trx_commit=2 --language=..\share\english\ --log-warnings --skip-
bdb --skip-ndbcluster --skip-external-locking

rem Settings for 32 bit machine, 4GB 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=10M --read_rnd_buffer_size=10M --sort_buffer_size=10M --
join_buffer_size=10M --myisam_sort_buffer_size=50M --
myisam_max_sort_file_size=50M --key_buffer_size=400M --
bulk_insert_buffer_size=50M --innodb_buffer_pool_size=200M --
query_cache_size=200M --max_heap_table_size=100M --tmp_table_size=100M --
innodb_flush_log_at_trx_commit=2 --language=..\share\english\ --log-warnings --skip-
bdb --skip-ndbcluster --skip-external-locking

Distributing Database for scalability

If the monitored devices are over 500 (or over 5000 interfaces), with more than 50000
polleddata, you can consider porting the database onto another dedicated server. Here
are the steps:

1. Install a supported MySQL version on the dedicated server.

2. Edit the file /opmanager/conf/database_params.conf
3. Configure the host name and the MySQL port number for the url parameter as
follows:
url jdbc:mysql:// <name of the server where mysql is installed> : <mysql port>
/OpManagerDB
Example: url jdbc:mysql://database1-server:3306/OpManagerDB

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/conf/wrapper.conf (Initial/Maximum Java Heap Size). The
recommended JVM Heap Size is:

Hardware Initial Heap Size (-Xms) Maximum Heap Size (-Xmx)

1 GB RAM 100 200

2 GB RAM 200 512

4 GB RAM 512 1024

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