No. The monitored devices need not necessarily have SNMP if you just want to check for availability. OpManager relies on Ping to check the device availability. For monitoring other host resources , traffic etc, OpManager requires SNMP to be enabled on the monitored devices.
For non-SNMP servers, OpManager uses WMI (Windows) or CLI (other Unix-based devices) for monitoring.
Both, the SNMP read and write community string needs to be set on the source router. The write community is used to configure the IPSLA on the device while the read community is used by OpManager to gather performance data from the router
Enabling the IP SLAs Responder provides the details of packet loss statistics on the device sending IP SLAs operations. IP SLAs Responder is enabled on the target router (rtr responder) before configuring a Jitter operation.
The monitored parameters include Latency, Jitter, Packet Loss, and MOS. The parameters are described below for reference:
Jitter : Jitter is defined as a variation in the delay of received packets. Users often experience disturbing sounds over a conversation coupled with loss of synchronization at times and is referred to as jitter. High levels of jitter can result in some packets getting discarded and thereby impact the call quality. Ensuring a jitter-free transmission to provide qualitative service depends on identifying the bottle-neck responsible for the jitter, and acting on it to eliminate it. OpManager's VoIP monitoring feature helps you find the problem and ensures maximum QoS on your VoIP network.
Packet Loss : Packet loss is a measure of the data lost during transmission from one resource to another in a network. Packets are discarded often due to network latency. Using OpManager, you can monitor the packet loss and take corrective actions based on the information.
One way Latency: Latency (delay) is the time taken for a packet to reach the destination device. When monitoring latency over VoIP, the delay measured is the time taken for a caller's voice at the source site to reach the other caller at the destination site. Network latency contributes to delay in voice transmission, resulting in huge gaps between the conversation and interruptions.
Round Trip Time: Round Trip Time is the time taken for a packet to reach the destination and again comes back to the source device. The total time it takes for the round trip is measured in milliseconds.
MOS: The Mean Opinion Score is the key quality indicator of VoIP traffic quality. And is measured in the scale of 1 to 5 (poor to excellent quality)
Codecs (Coder/Decoder) serve to encode voice/video data for transmission across IP networks. The compression capability of a codec facilitates saving network bandwidth and it is therefore appropriate that you choose the correct codec for your IP network. Here is a quick reference to the codecs with the corresponding packets size and bandwidth usage:
|
Codec & Bit Rate (Kbps) |
Operation Frequency |
Default number of packets |
Voice Payload Size |
Bandwidth |
Bandwidth |
Bandwidth |
|---|---|---|---|---|---|---|
|
G.711a/u |
60 msecs by default. You can specify in the range of 0 - 604800 msecs. |
1000 |
160 + 12 RTP bytes |
82.8 kbps |
67.6 |
87.2 |
|
G.729 |
1000 |
20 + 12 RTP bytes |
26.8 kbps |
11.6 |
31.2 |
OpManager uses SNMP to gather data from the Cisco IP SLA agent. This error is displayed when wrong SNMP read / write community string is configured for the Source router of the VoIP Monitor in OpManager.
To configure the correct SNMP write community string in OpManager, go to the snapshot page of the source router and change the SNMP credentials by clicking on the 'Click here to change' corresponding to the "Passwords" field. In the pop-up enter the appropriate credentials and submit it. After successfully submitting the correct SNMP credentials, try to add the VoIP Monitor again for the Source device (Maps > VoIP Monitor > Settings)
Both, the SNMP read and write community string needs to be set on the source router. The write community is used to configure the IPSLA agent on the device while the read community is used by OpManager to gather performance data from the router.
The possible reasons could be:
OpManager doesn't use STP for layer 2 mapping. We are in the process of enhancing our layer 2 mapping feature are are considering the possibility.
Yes, OpManager supports automated Layer2/Layer3 mapping. You can also export them to Visio.
Yes, you can run OpManager as a Unix Service.
Follow the steps mentioned below to install OpManager as a service on a linux box.
1. Copy the attached opmanager.txt file to /etc/init.d directory as opmanager
mv /etc/init.d/opmanager.txt /etc/init.d/opmanager
2. Edit the MDIR variable in this file which should point to the bin folder of OpManager Installation directory. Typically, the default installation folder on a Linux box will be /root/ManageEngine/OpManager/bin. Hence the value for MDIR will be
MDIR=/opt/ManageEngine/OpManager/bin
3. Provide executable permissions for this script using
chmod 755 /etc/init.d/opmanager
4. Use chkconfig command to add opmanager as a service
You can start OpManager in the nohup mode so you don't have to worry about the service being terminated when the console is closed. The service will continue to run in the background. Make these changes in the start and stop script files of OpManager:
in start
nohup /opt/ManageEngine/OpManager/bin/StartOpManagerServer.sh
in stop
nohup /opt/ManageEngine/OpManager/bin/ShutDownOpManager.sh
OS: RH Linux 7.2 and above
Inactive ports do not throw alerts though they are discovered. During discovery inactive ports are added inside OpManager with a different status. There wont be any alarms for those interfaces. Once it goes up and then down, OpManager will automatically start monitoring the interfaces similar to other interfaces.
Network topology is the arrangement of nodes and links in the network and the interconnections among the nodes. Finding the networks connectivity is purely based on the SNMP.
In OpManager, the network maps are designed in such a way that map renders the overall networks connectivity. This map consists of only network devices like switches, routers, firewall and wireless devices and it is called as Layer3 map. To see the devices connected to a particular switch, click on the switch icon in networks map. It is called as Layer2 map because the connectivity is found based on the mac address which is present in the switches and device mac address. The topology maps can be saved as business view. YOu can easily edit the maps and add into widgets / dashboards. The network maps have different layout options as well.
It is very much possible to run OpManager in a Virtual Machine. But it is better to have OpManager installed in a physical server for a simple reason that OpManager server may miss critical events during the period of VMotion / DRS & HA. Also, VMware monitoring addon in OpManager uses VMotion events to automatically map the VMs to corresponding Host machines, in case where this event is missed you need to do a manual rediscovery of ESX.
If you feel you have less number of ESX (say 1-2) or VMotion will not happen etc., it is perfectly ok to install OpManager on a Virtual Machine. We recommend OpManager to be installed on a physical machine, if you want to closely monitor your ESX servers in your environment.
You might not have received alerts from the device if the trap host is not configured in the source Router. Make sure you configure the routers to send traps to OpManager. Telnet the router and type the following command:
snmp-server host (opmanager server IP) traps (host community string) rtr
For instance, if the OpManager host IP Address is 192.168.18.128, and the community string is private, the command would be:
snmp-server host 192.168.18.128 traps private rtr
OpManager uses only ICMP echo and path echo in its WAN RTT module as of now. We might include some additional functionality in future based on priority and demand.
We have tested scripts based on Shell, Perl, Powershell, VB. However, OpManager can run other scripts that can be executed from the command prompt. Basically OpManager writes the script content to a file and then executes the given command via a command prompt.
You can upload your script using the form here. Our developer will validate the script and make changes to make it 'workable' and email you the modified script.
A recent query from a customer:
We’re running with 8812 and we have 2000 devices licensed with essential and we monitor about 18 vmware hosts. I’ve saw that essential is now limited to 500 hosts and only 5 virtual host licenses is included. What will happen when we upgrade to version 9?
Your current installation will not be affected by the upgrade to OpManager version 9.The Essential edition limitation of 5 ESX hosts applies to the fresh installation of OpManager 9.
About the 500 devices, it is not a limitation but an advisory about the scalability of OpManager for the best performance. As you have 2000 devices, you will have to upgrade the OpManager server's hardware to meet the minimum System Requirement. In case of doubts about how many ESX hosts you can monitor post upgrade, send a copy of your license file AdventNetLicense.xml found under \OpManager\classes folder to opmanager-support@manageengine.com. The support team will verify and email you the details.
Its possible to upgrade OpManager from a standalone version to an enterprise Probe. Your existing instance of OpManager can be upgraded as a Probe. For the licensing part, we will have to generate a new license in comparison with your existing license. If you require additional information on the Licensing & Pricing for the Enterprise Edition, please email .
If you have any questions about OpManager, feel free to raise a support request and we’ll get back to you.
400-660-8680
