Welcome to docs.opsview.com


This page allows you to configure hosts. You need to have the CONFIGUREHOSTS access level in your role to be able to configure hosts.

Hostname or IP

This is the primary hostname, or IP, for this host.

Bear in mind that a host does not have to be a physical host, so this field does not have to be an actual hostname or IP.

Note: If you use a hostname, there is a dependency on the Opsview system to resolve this host name at the time of the service check. See the best practices guide for name resolution.

Changes to this field will update the Monitored by field. Opsview will try and pick the monitoring server which has a hostname or address most similar to the host. This works by looking at the domain names or the IP ranges of the slave nodes. If the slave node has an IP address but the host has a host name, then a similarity will not be found (Note: in a slave cluster, only the first node is used for comparison). You can disable this feature in System Preferences.

Host Title

This is the name of the host as known by Nagios® Core. This needs to be unique across the entire monitoring system. Note that reports and performance graphs will use the name to find historical information, so if you change the name of a host these will be lost.

The name is constrained to 63 characters.

Other addresses

This is for a list of other hostname or IPs that this host corresponds to. Enter a comma to separate the addresses. You can use spaces to enhance readability.

When you configure your servicecheck, you can access these addresses using the macros $ADDRESSES$, (which returns the entire list including commas, with spaces stripped), $ADDRESS1$ (for the 1st address), $ADDRESS2$ (for 2nd address), etc.

If other addresses are not defined, but the $ADDRESSx$ macros are used, $ADDRESSx$ will default to the primary IP address of the host. $ADDRESSES$ is left undefined.

This field is also used for relating these IP addresses to this host for the purposes of SNMP trap processing.

Monitored by

This field only appears if you have more than one monitoring server. Select which monitoring server you want this host associated with. This monitoring server will then monitor all services for this host.

This list will restrict the items based on your role's access levels for CONFIGUREHOSTS.


Select the parents of this host. This will set the parent/child relationship within Nagios Core so that host outages can be calculated better.

This relationship is used to calculate if a host is DOWN or UNREACHABLE, ie, if the dependencies for the host mean the host is really down or if something in the middle is hiding the true state of the host. Use this to relationship to minimise notifications as you can disable notifications for UNREACHABLE hosts.

For example, if you have a switch as the parent of 10 hosts and the switch is marked as DOWN, then when the 10 hosts are checked and considered DOWN, they will be marked as UNREACHABLE instead and you will only get one notification for the switch instead of 10 host notifications. Note, there maybe a delay in this eventual condition as results will be coming in at different times.

You can select multiple parents, if you have a failover capability. There are various filters that can be selected to reduce the number of hosts visible in the source list on the right.

When generating the Nagios Core configuration for parents of a host, this is the logic used by Opsview:

  • Use the list of parents specifically defined
  • Otherwise, if the host itself is used as a monitoring slave, set the parent to be the Opsview master
  • Otherwise, if the host is the Opsview master, set no parents
  • Otherwise, set the parent to be the host representing the monitoring server from the Monitored By field. If the monitoring server is a slave cluster, set parents to be all the cluster nodes

Note: In a distributed environment, the slave system doesn't know about all hosts, so similar rules apply but there will be filtering based on whether the parent host exists within the slave system or not. This means that the Opsview master is the only system that has a complete picture of the network topology.


For a physical machine, the parent would be the switch that the machine connects to. Set multiple switches if you have a redundant switch configuration.

For a virtual machine, the parent is the VM host that it is running on (or multiple ones if you have a cluster of VM hosts). The physical VM host would then have the parent set to the switch that it is connected to.

Note: The logic is different for the main Opsview system, because Opsview is conceptually the most important dependency and thus should be at the “top of the tree”. So do not set the Opsview server to have a parent of its switch - set this switch to have a parent of the Opsview server. Furthermore, if the Opsview server is on a VM host, set the VM host to have a parent of Opsview and set the nearest switch to have a parent of the VM host.

Host Group

This list will only show host groups which are leaves at the bottom of the host group hierarchy. The list will be restricted based on your role's access level for CONFIGUREHOSTS.

If you have admin access, then a New Hostgroup text field will appear if you want to create a new hostgroup.

Host Check Command

This defines the command to check the host by. The default is to run a ping test, but there are various other options. You can configure new host check commands under the Advanced → Host Check Commands in the left hand navigator (note, the order of the host check commands is user defined).


You need to have CONFIGUREKEYWORDS for this field to appear.

Assign keywords to this host. Only service checks with the same keyword that is also on this host will be associated with this keyword.

Select from the drop down the required keywords.

Note: You will need to create the keyword first to appear in the drop down.

Note: You need to reload for any viewports to update any keyword associations.

Notify On

Choose which states this host should notify on.

Note: If a host does not notify on any states, then the services on that host will also not send any notifications.

Notification Period

The time period when notifications are allowed to be sent to contacts.

Re-notification Interval

Period of time (in minutes unless configured otherwise) after which a notification is resent if the host is still unhandled. If this is set to 0, only the first notification is sent (when a hard state change occurs).

Flap Detection

Enable or disable flap detection. The host is considered flapping if it changes states more than 7 times in the last 20 checks.

Check Period

This defines when your should check the host is available. If you have hosts that are only on during specific hours, select an appropriate time period. The state of the host will not be checked outside of the time period and will just use the previous state.

Check Interval

This defines the time interval in minutes of when to check the host. If this is set to 0, the host will only be checked on demand (when a service has changed state). We recommend leaving this set to the default value of 5 minutes 1).

Max Check Attempts

This defines the number of times a host has to fail before it changes into a hard state for notifications.

Retry Interval

This defines the time interval in minutes when trying whether a host is still in a failed state.

Event Handler

You can set an event handler for the host. See event handlers page for more information.

Host Templates

This defines the list of host templates that this host has associated. See the host template pages for more information.

Note: if the smart host template removal option is enabled, host specific exceptions may be removed.


See the monitors page for more information about selecting the service checks that this host would monitor.


SNMP devices must be configured to provide read access rights to the Opsview servers

Enable SNMP

This tickbox controls the overall ability of this host to communicate via SNMP. If this tickbox is unchecked, then the Use MRTG and Use NMIS fields are effectively unchecked.

If this is checked, then there will be an extra submit button that will submit the changes and then take you to the interfaces screen.

Note that it is still possible to assign service checks that require SNMP - they are unlikely to work correctly.

SNMP Version

Select the appropriate SNMP version.

Note: if a device supports SNMPv1 and SNMPv2, use SNMPv2 as the performance is much better since it will be possible to run bulk queries.

For SNMP v1 or v2c, you only need to enter the community string.

For SNMP v3, you have to enter the password, the authentication protocol and the authentication password. If you do not enter a privacy password, no privacy will be set.

To test the authentication information, you can press Test SNMP connection button which will attempt to communicate with the host.

Note: The SNMP v1/v2c community string, SNMPv3 auth password and SNMPv3 priv password are password fields and it is not possible to retrieve these passwords when set - you can only reset the passwords.


This defines the port number to connect to the SNMP device. Default is 161.

SNMP Community

This defines the community string to connect to the SNMP device. Applies to SNMP v1 and SNMP v2c.

This value will be encrypted in the Opsview database. After this value has been saved, it cannot be retrieved back in the user interface.

If you want to change the value, click the Reset button to change it.

SNMPv3 Username

This defines the SNMPv3 username to connect to the SNMP device.

SNMPv3 Authentication Protocol

This defines the SNMPv3 protocol to connect to the SNMP device to authenticate the user.

SNMPv3 Authentication Password

This defines the SNMPv3 password to connect to the SNMP device to authenticate the user.

This value will be encrypted in the Opsview database. After this value has been saved, it cannot be retrieved back in the user interface.

If you want to change the value, click the Reset button to change it.

SNMPv3 Privacy Protocol

This defines the SNMPv3 protocol to encrypt traffic between Opsview and the SNMP device.

SNMPv3 Privacy Password

This defines the SNMPv3 password to encrypt traffic between Opsview and the SNMP device. If this is not set, then no attempt to encrypt traffic will take place. For devices using Net-SNMP, an empty privacy password will still allow connection to the device even if a privacy password is defined for a user.

This value will be encrypted in the Opsview database. After this value has been saved, it cannot be retrieved back in the user interface.

If you want to change the value, click the Reset button to change it.

Test SNMP Connection

This will connect to the device using the credentials supplied in the UI. On a successful connection, Opsview will return the system description information of the device. If there is a connection failure, Opsview will return information about what the failure is, as returned by the underlying communication software.

There could be various reasons for a connection failure:

  • IP address or DNS name incorrect
  • SNMP port incorrect
  • SNMP version incorrect
  • SNMP community incorrect
  • SNMPv3 authentication protocol or authentication password incorrect
  • SNMPv3 privacy protocol or privacy password incorrect


If you use an SNMP polling service check, AES128 may not be a supported Privacy Protocol because the underlying Net-SNMP software may not support AES128.

If you have any shell characters for the SNMP v3 parameters, these may not get passed to the SNMP polling service check correctly. This is a limitation in the check_snmp plugin.

SNMP Interfaces

See the SNMP interfaces page for more information.

Use MRTG for Interfaces

If this option is specified, then MRTG will be setup to poll this host to get basic interface statistics.

NOTE: MRTG must be at least version 2.15.0 when using SNMPv3 on a host. A warning will be put onto the reload page if MRTG is not new enough. Please contact your OS vendor if you need to upgrade your version of MRTG.

Use NMIS for Interfaces

If this option is specified, then NMIS will be setup to poll this host to get interface statistics.

Note: NMIS only works with SNMP v1/2c at the moment.

Host Type

If Use NMIS for Interfaces is selected, then you will need to tell NMIS what type of host this is. This allows it to select an appropriate profile to determine the characteristics of the host.


Attributes are some meta data you can associate with a host, which can be referenced in a service check definition to allow changing specific values in the argument field. For more information, see the attribute page.

Host Attributes

Click on the Plus icon to add new host attributes. You can have multiple attributes of the same name. Click on the Reveal icon to show the argument field.

The value can only consist of alphanumeric characters, space, a period (”.”), a forward slash (”/”) or a dash (”-”), up to 63 characters - this is because the value could be used in the service name, which has restrictions on the characters used. Any trailing spaces will be removed.

The argument field allows any characters, but be aware that Nagios Core may process some special characters like !, $ and \.

The argument field can be set to inherit from the default attribute argument setting. This is useful if you want to have a generalised argument, which is overridden on a per host basis.


On systems with the RANCID plugin installed, the following extra options are available

Use Rancid

Enable scanning of the device by RANCID

Rancid Autoenable

Set the 'autoenable' RANCID property when scanning devices

1) Opsview 4.4.0 and earlier have 0 as their default.