Chapter 4. Host/Node Management

Being able to configure what checks to run on which nodes is one of the key features in the SysOrb Web Interface. Basically there are three different kinds of checks you can configure:

• NetChecks are checks that the SysOrb Server itself can perform to check the performance of a given service on a node. This means that the node being checked does not necessarily have the SysOrb Agent installed.

  NetChecks range from simple ICMP ("ping") checks to mail server checks. It is not necessary for a node to be a SysOrb Agent in order for a NetCheck to work from the SysOrb Server.

• AgentChecks are performed by the SysOrb Agent which reports the results of the performed checks on the host to the SysOrb Server.

  These checks are performed by the SysOrb Agent and include checks on CPU load, free disk space, memory consumption and similar information.

• snmpChecks are also checks performed by the SysOrb Server. This type of check can test gauges, counters and enumerations on SNMP capable devices, for example network printers, routers and intelligent switches.

Before you can configure the SysOrb Server to start monitoring a SysOrb Agent there are a few things you need to set up on the Agent. Please refer to the Administrator's Guide to the SysOrb Network Monitoring System for more information on how to configure a SysOrb Agent to check in to a specific SysOrb Server.

When adding or modifying node information the following are used to specify how the node will behave and when it will check in:

• Node label: A name that you would like to see, on the various listings from SysOrb. SysOrb does not try to interpret this name in any way, it does not have to correpond to the DNS name or WINS name of the node.

• Node dns-name/ip-address: The name by which the node will be recognized by the SysOrb Server.

  Note: If you are preparing the SysOrb Server for a SysOrb Agent it is important that this name is exactly the same as the name specified in the configuration of the SysOrb Agent. If the two hostnames differ the SysOrb Server will reject the SysOrb Agent. See the Administrator's Guide for more information on how to configure the SysOrb Agent.

• Information URL: If you have additional documentation regarding this node for the operators, you can supply an URL here, and SysOrb will show a link to the documentation on the various listings where this node appears.

• Check in every: This is only used for SysOrb Agents. It tells the SysOrb Agent how often it should checkin. If you are configuring a node without the SysOrb Agent installed, you should set this value to Disabled

• Alert group: The group to notify in case of warnings or alerts. When configuring checks, their default Alert group will be the same as this.

  Possible values: None, As domain, AlertGroupX, AlertGroupY,...

  Default value: None

• Checkin alert Strategy: This allows you to select the method for determining when an administrator should be alerted about the Agent not checking in. The two possible values are Immediate and ScoreKeeper. Please refer to Section 1.3 for more information about how this works.

• Scheduled downtime: Some nodes are only used in certain periods, for instance during working hours. SysOrb can be instructed only to send warnings and alerts during these periods. It will still perform the checks around the clock for statistical purposes, just not send warnings or alerts outside working hours.

  You configure this by specifying all the time intervals of the week, for which SysOrb should not send warnings or alerts. For instance if you want SysOrb to monitor a server from 8 am to 4 pm every workday, you would add downtime intervals from 0:00:00 to 8:00:00 and from 16:00:00 to 23:59:60 on each of Monday to Friday, and one interval from 0:00:00 to 23:59:60 on Saturday and Sunday.

  Note: If you have many nodes which should be monitored during the same set of intervals, you may consider putting those into a domain, and configuring scheduled downtime for the entire domain.

• Unexpected downtime: When SysOrb detects a problem on a node, you sometimes know that someone will deal with it at some specific later time. You do not want to be flooded with SysOrb messages until then. In that case you can use these fields to instruct SysOrb not to send any warnings or alerts regarding this node until some later point in time.

  Using the drop-down box labeled Node down you can select that the node will be down for 1, 3, 6 or 24 hours. You can also select the option named "Until", and enter a date and time in the text field to the right.

  When enabling unexpected downtime you can choose to let SysOrb send a notification to anyone ordinarily receiving warnings or alerts regarding this node. This is accomplished using the Notify group drop-down box.

• Community: This value specifies which SNMP community SysOrb should use when checking this node using SNMP.

• Protocol version: SysOrb supports both SNMP version 1 and version 2. If you know which one your network equipment uses, you can specify it here before scanning the node. Otherwise SysOrb will first try version 2, and if the node does not reply to that, then version 1.

• Port: If your SNMP equipment uses a port other than the standard 161, then you should enter it here, to make SysOrb issue its SNMP requests to that port for this Node.

• Scan: When you click this button, SysOrb will perform an SNMP walk of the node, thus making snmpChecks available on this node.

  After the scan, if you think that SysOrb did not find all the possible checks that you think the network equipment supports, you may want to inspect the incident log of the node. It will show if SysOrb skipped something, because it does not have the required MIB's, if that is the case you can consult the Administrators Guide for an explanation on how to import MIB-files into SysOrb. You find the incident log by clicking Overview on the left navigation bar and hitting the button labeled Incident log.

Apart from these options it is also possible to define how the score of a node should be modified by how different checks turn out. This is done through the Score system as described in Section 1.3. The signed values defined in the options below are added to the score of the host/node when a check succeeds or fails.

• Checkin score: This is added every five seconds whenever the last checkin was on time. (must be negative)

• Missed checkin score: This is added every five seconds whenever the Agent has exceeded its timeframe for checking in. (must be positive)

• Warn at: When the node's score or the score of one of its checks, is above this level a warning message will be sent to the appropriate paths.

• Warn ceiling: Checks resulting in warnings can never result in a score exceeding this limit.

• Alert at: When the node's score or the score of one of its checks is above this level an alert message will be sent to the appropriate paths.

• Alert ceiling: Checks resulting in alerts can never result in a score exceeding this limit.

The page can also contain a button to release the key, that the server holds for the SysOrb Agent. This key is negotiated when the SysOrb Agent contacts the SysOrb Server for the first time, so it can be used to authorize the agent the next time it checks in. If the agent is reinstalled and has lost its key it is necessary to release the key, in order for the SysOrb Server to allow the Agent without providing a key. It it also necessary to release the key, if you have deinstalled the SysOrb Agent from a host, and you wish to move the SysOrb Agent license to another host.