Configuring Network Manager Observer jobs
Using the IBM Tivoli Network Manager Observer, you can define jobs that dynamically load data discovered by Network Manager for analysis.
Before you begin
Important: The IBM Tivoli Network Manager Observer supports the on-premises IBM Tivoli Network Manager version 4.2.
Ensure you have the IBM Tivoli Network Manager service details to hand, such as the domain, host and port number.
The IBM Tivoli Network Manager Observer jobs extract Network Manager resources using an Object Query Language JDBC driver, and the observer loads and updates the resources and their relationships within the topology.
Enabling access to the URL routes
To access the URL routes for the topology Swagger documentation, see the Enabling access to URL routes topic.
About this task
You configure the following two jobs.
Load
A transient (one-off) job that queries Network Manager for topology data, and performs a complete upload for a single IBM Tivoli Network Manager domain.
By default, Load jobs are one-off, transient jobs that upload all of the requested topology data as soon as they are triggered.
For cross-domain connections: Each ITNM domain must read existing cross-domain connections from the topology service, which means that you may need to run two observations of all domains contributing cross-domain connections (that is, run the full load job twice) before all cross-domain edges are created.
You can also run these jobs (again) manually from the Observer UI, or schedule them to run at set times when configuring them.
Listen
A long-running job that monitors the Network Manager message bus for changes and updates the topology service. When the job is started, the observer creates an OQL connection that listens for changes in the IBM Tivoli Network Manager network. Any resources added, changed or deleted are passed on by the OQL connection and the topology is updated.
The listen job runs until it is explicitly stopped, or until the observer is stopped.
Procedure
Define or edit the following parameters, then click Run job to save and run the job.
Encryption requirement: See the Configuring observer jobs security topic for more information.
| Parameter | Action | Details |
|---|---|---|
| Unique ID | Enter a unique name for the job | Required |
| ITNM instance name | Specify the IBM Tivoli Network Manager instance name | Required. Specify the same instance name for all jobs to enable connectivity across domains. |
| ITNM domain port | Specify the IBM Tivoli Network Manager port for the specified domain | Required. The value of port will vary if multiple domains exist. To determine which port number to use for a Network Manager domain, look for the domain-specific ncp_config entry in the $NCHOME/etc/precision/ServiceData.cfg file. |
| ITNM domain | Specify the IBM Tivoli Network Manager domain | Required |
| Hostname or Server IP | Specify the IBM Tivoli Network Manager hostname or server IP on which the domain is running | Required |
| OQL connection timeout (ms) | Specify the OQL Connection timeout value | Optional. The default is 3000 (30 seconds). |
| Edge Type Map | Map IBM Tivoli Network Manager layers to topology relationship types | Optional. If blank, IBM Cloud Pak® for AIOps will auto-map. The value of topology type can be found in IBM Tivoli Network Manager in '$NCHOME/precision/disco/stitchers/DNCIM/PopulateDNCIMTopologies.stch'; alternatively, run the following
OQL statement against the model service to list the available topology type: select ENTITYNAME from ncimCache.entityData where METACLASS='Topology' |
| Exclude resources without connections | Select whether to display disconnected resources | Optional. The choices are true and false. The default is true. |
| Access scope | Enter text to provide a scope for the resources. Access scope can help map alerts to resources when resources in different scopes share the same parameters, such as matchTokens. | Optional. Tip: You can define access scope for locations, project names, namespaces, etc. |
| Generate debug support file | Set this parameter to 'True' in order to capture the output of the next scheduled job run as a file. This file will be stored with an observer's log files and can be used to debug observer issues, for example at the request of your designated support team, or while using a test environment. For one-off jobs (that is, Load jobs), this parameter reverts to 'False' after the next completed run. To examine the output produced, you can load the generated debug file using the File Observer. | Optional |
| Observer job description | Enter additional information to describe the job | Optional |
| Job schedule | Specify when the job runs | Optional. Load jobs only. |