For simplicity, the QOS Server configuration file uses Python's data structure declaration format. All of the entries are either elements in a Python dictionary or a Python list of dictionaries. Dictionaries are delimited by curly braces with name: value pairs. Lists are delimited by square brackets. In both cases, elements are separated by commas. As the configuration is an executable Python script, the config can be loaded into Python to test for validity.
Note that the entire configuration file is one large dictionary with five primary keys:
Qos
Notify
Groups
Hosts
Each key is described in its own section below.
The 'Qos' section describes basic server configuration items.
Basic Server Configuration
Sets the displayed version for the Server. Cosmetic.
Sets the domain for the systems under monitoring. This part of the hostname will be removed in the alerts and host configuration. For example, an Agent named www.company.com with defaultDomain set to comany.com would cause the Agent to be called www in the Agent listings and notifications.
Sets the username & password combinations for the administration webpage and the report webpage. The value should be a dictionary of username: password combinations.
Sets the path and filename of sendmail interface to the local email system. This is required to send email notifications.
The Notification Configuration defines a set of groups that the Server uses to send notifications to when problematic conditions exist. A group lists the email addresses the notifications should be sent to for normal and page escalation levels. The post escalation level specifies a URL to HTTP POST information to. A special group name, default, sets the group to use if another group is not specified in the Entity configuration.
To set an alterate notification group to use for a particular Host, add a Host entity type with a notify key with the desired group set as its value. To change an Entity, add a notify key to the Entity's dictionary, and likewise for SubEntities and for individual Triggers. notify keys are automatically propagated downward and can be overridden multiple times as needed.
An example of setting a default notify group for an entire Agent:
'omourov' :
[
{ 'type' : 'Host' ,
'notify' : 'admins',
},
# rest of host config ...
],
An example of setting a notify group for a particular Entity:
'omourov' :
[
{ 'type' : 'Cpu' ,
'status' : 'on' ,
'notify' : 'admins' ,
'triggers': [{ 'level' : 'info', 'trigger' : '10'}],
},
# rest of host config ...
],
An example of setting a notify group for a specific SubEntity:
{ 'type' : 'Tcp' ,
'subents' : [
{
'status' : 'on' ,
'name' : 'mx1.example.com',
'tcpHost' : '12.34.56.78',
'tcpPort' : '25',
'goodPhrase' : '220 example.com ESMTP',
'notify' : 'admins',
'triggers' : [{ 'level' : 'warn', 'trigger' : '5' }, ],
}
]
}
And finally, an example of setting multiple Triggers with different notification groups:
{ 'type' : 'Disk' ,
'status' : 'on' ,
'triggers': [{ 'level' : 'info', 'notify': 'noc', 'trigger' : '90'},
{ 'level' : 'critical', 'notify': 'admins', 'trigger' : '95'}, ],
},
Notification Group Variables
The value is a list of email address(es) to contact when an alert is generated for triggers set to info notify level or the first failure for triggers set to warn notify level. Ideally this should point to the admin's standard inbox.
The value is a list of email address(es) to contact when an alert is generated for triggers set to critical notify level or the second failure for triggers set to warn notify level. Ideally this should point to a pager or other notification device as the Entity in question requires attention.
The value is a list with two items. The first item is a URL to send a HTTP POST request to. The second item, which must be double-quoted, is a dictionary of variable-value pairs to send as the body of the POST request. The values may reference the report dictionary, which contains the information from the Entity that is reporting problems.
The Groups section contains lists of Entities to consider as a group in the Report module. The group name is the key and the group members are a Python list of strings of the full Entity name.
The Host section defines the configration for the Agents. Each Agent that is to report data must have a key in this section. The key is the shortened hostname as reported by the Agent; therefore make sure the system hostname is set correctly or unpredictable results may occur. Each key's value is a dictionary of Entity keys, with the values the configuration for that Entity.
A sample Host configuration section looks like the following:
'omourov' :
[
{ 'type' : 'Cpu' ,
'status' : 'on' ,
'triggers': [{ 'level' : 'info', 'trigger' : '10'}],
},
{ 'type' : 'Disk' ,
'status' : 'on' ,
'triggers': [{ 'level' : 'info', 'trigger' : '90'},
{ 'level' : 'critical', 'trigger' : '95'}, ],
},
{ 'type' : 'Mem' ,
'status' : 'on' ,
'triggers': [{ 'level' : 'info', 'trigger' : '80000'},
{ 'level' : 'critical', 'trigger' : '100000'}, ],
},
{ 'type' : 'Proc' ,
'status' : 'on',
'triggers': [{'level':'info', 'trigger':'automount'}],
},
## end of omourov
]
Each list entry in the Host value has three required keys:
The name of the Entity described in this entry.
Sets if Entity is enabled (on) or not (off).
Sets the Triggers and Notify config for this Entity. The value set is dependent on the Entity type.