Blue points on Netcool/OMNIbus
When architect a Tivoli Netcool/OMNIbus solution, careful planning must be undertaken to ensure all necessary factors have been considered before provisioning both the software and hardware components ― as well as designing the architecture layout.
The standard multitier architecture configuration is the pre-canned, best practice Tivoli Netcool/OMNIbus configuration that ships with the product and can be used to deploy one, two or three tier systems. Since event count so heavily impacts on profiling time and therefore ObjectServer loading, it is an important consideration in the sizing of a solution.
it is better to install a failover pair of ObjectServers to provide resiliency in the event of an outage.
The profiling log provides a summary for each ObjectServer granularity cycle of how much time the ObjectServer spent interacting with processes external to the ObjectServer. Each event that is inserted into the ObjectServer by a Probe incurs load on the ObjectServer. The overall load each Probe puts on the ObjectServer can be monitored via the ObjectServer profiling log.
The trigger statistics log provides a summary for each ObjectServer granularity cycle of how much time the ObjectServer spent running internal processes ― specifically: triggers.
Since one Probe should be provisioned to handle up to 100 events per second, then one SNMP Probe should be sufficient. Note that consideration should be given to deploying a second SNMP Probe in peer-to-peer mode for resiliency.
To inspect a Probe's current properties settings and to see all the available runtime options, simply run the Probe with the dumpprops switch as in the following example:
$OMNIHOME/probes/nco_p_syslog -dumpprops
If the ObjectServer reaches its maximum number of connections, no further connections to the ObjectServer are possible until some of the previously made connections are released. The default number of connection for a new ObjectServer is 256. A setting of 1024 is the maximum allowable value.
If a trigger will be installed and run on a Collection layer ObjectServer, it can typically be left to run all the time ― requiring no specific modification. Typically however, temporal triggers installed on Aggregation layer ObjectServers should only be active on the acting primary ― ie. on the primary Aggregation ObjectServer or the backup Aggregation ObjectServer when the primary is down. In such cases, a WHEN clause should be added to the trigger used to restrict its execution.
The suppression level of an event or group of events can be manually set by operators via an Event List tool or via custom triggers. Some default triggers are also configured to modify the SuppressEscl field ― including flash_not_ack (Flash field set to 1) and escalate_off.
whenever a user is added to the “Netcool” group, the VMMSYNC process will create that user on the ObjectServer infrastructure so that when that user logs into WebGUI, opens an Active Event List and runs tools or adds journal entries, they will be successful. Without corresponding user creation on the ObjectServer layer, users would be able to log in, but would have limited capabilities. Similarly, whenever a user is removed from the “Netcool” group on the LDAP server, the VMMSYNC process will remove that user on the ObjectServer infrastructure.
When defining the external action, the Netcool Administrator must specify which user the external action should run as. If the Netcool Process Agent is running as a privileged or super user on the host machine, then a Netcool Administrator could potentially configure external actions to be carried out on the host system as a privileged user. The way to prevent this scenario is by running the Netcool Process Agent used by the ObjectServer for external actions as a non-privileged user.