IBM Support

Hints and Tips for Upgrading to the IBM Netcool Generic Probe

Technical Blog Post


Abstract

Hints and Tips for Upgrading to the IBM Netcool Generic Probe

Body

I will use the OSS RC in this example however it's relative to most probes that connect to an EMS and has reached end of life with IBM.

 

The key is to use the new props file that comes with the generic probe, we see many issues where the properties file is copied over in this case from the OSS RC to the Generic. This will not work.

 

For example

 

OSS RC Probe

Debug: D-UNK-000-000: (Non-encrypted property) NSIorfile-> http://192.1.1.9:80/ior/NameService.ior

 

Generic Probe

Debug: D-UNK-105-000: NamingServiceIORFile: "/tmp/NameService.ior"

 

As you can see the properties are not the same, additionally you cannot get the ior file using http with the Generic probe as its not supported.

 

I use /tmp as an example as $OMNIHOME can often fail if you have not set you environment variables correctly.

 

 

 

Next...

 

Debug: D-UNK-105-000: IDLAttrMapFile:

 

This file again can causes issues with Environment Variables and I would recommend using the explicit path and not $OMNIHOME

 

/opt/IBM/Omnibus81/omnibus/probes/includes/generic_3gpp_v6_4_RuleElementMap.xml

 

There are 2 ways to connect to an EMS using the corba interface.

https://www.ibm.com/support/knowledgecenter/en/SSSHTQ/omnibus/probes/generic_3gpp_v6.4/wip/reference/gen_3gpp_64_corba.html

 

Method 1 uses the following properties:

 

NamingServiceHost - host on which the naming service is running
NamingServicePort - port on which the Naming Service is running
AlarmIRPName - name of the Alarm IRP object to which the probe sends a resynchronization request.
NotificationIRPName - name of the Notification IRP object to which the probe sends active alarm subscription requests.

Eg.
NamingServiceHost : 127.0.1.1
NamingServicePort : 50000
AlarmIRPName : 'ALARMIRP'
NotificationIRPName : 'NOTIFICATIONIRP'

 

The probe retrieves the object reference of the Entry Point object from the IOR file specified by the EntryPointIORFile property. It then sends a resynchronization request to the Alarm IRP object specified by the AlarmIRPName property and sends an active alarms subscription request to the Notification IRP object specified by the and NotificationIRPName property.

 

Method 2 uses the following properties:

 

AlarmIRPOIRFile - name of Alarm IRP IOR file name which carries configuration enabling probe to resync alarm.
NotificationIRPIORFile - name of Notification IRP IOR file name which enabling probe to receive active alarm subscription requests.

Eg.
AlarmIRPIORFile : '../../../alarmirp.ior'
NotificationIRPIORFile : '../../../notificationirp.ior'

 

The probe retrieves the object reference of the Alarm IRP object from the IOR file specified by the AlarmIRPIORFile property and the probe retrieves the object reference of the Notification IRP object from the IOR file that is specified by the NotificationIRPIORFile property.

 

If you are using the Naming Service, you must configure the following properties, using this as an example as it has the most properties...

 

NamingServiceHost >> Use nslookup to the EMS to see what you can use here, what ever is returned you can use

 

NamingServicePort >> The port you see in the NameService.ior is the port you use here

 

NamingServiceIorFile >> /tmp/NameService.ior, the ior file you get the port and from the file you use here

 

AlarmIRPName >> "com/ericsson/nms/fm_cirpagent/AlarmIRP", this format of this is found in the IDL, so depending on how the IDL is configured will depend on if you have . or /

 

NotificationIRPName >> "com/ericsson/nms/cif/service/NMSNAConsumer again this format of this is found in the IDL, so depending on how the IDL is configured will depend on if you have . or /

 

If the IOR file properties are not specified, the probe retrieves the object references of the AlarmIRP object and NotificationIRP object from the Naming Service. To locate the Naming Service, the probe either uses the NamingServiceHost and NamingServicePort properties to identify the host name and port number of the Naming Service, OR the IOR file specified by the NamingServiceIorfile property. So not both either or.

 

The Naming Service uses the values that are specified by the AlarmIrpName and NotificationIrpName properties to retrieve the object references to the IRP objects.

 

Example of what to expect in the log.

 

Debug: D-UNK-000-000: (Non-encrypted property) NamingServiceIORFile- /opt/IBM/Omnibus81/omnibus/probes/linux2x86/NameService.ior

Debug: D-UNK-000-000: (Non-encrypted property) NamingServiceHost-> <EMSHost>

Debug: D-UNK-000-000: (Non-encrypted property) NamingServicePort-> <EMSPort>

Information: I-JPR-000-000: Setting up Naming Service related properties.

Debug: D-UNK-000-000: (Non-encrypted property) ORBLocalHost-> <probehost>

Information: I-JPR-000-000: NameService : ORBInitRef.NameService = corbaloc::<EMSHost>:<EMSPort>/NameService

Debug: D-UNK-000-000: (Non-encrypted property) ORBLocalPort-> 6060

Debug: D-UNK-000-000: (Non-encrypted property) ORBWCharDefault-> UTF16

Debug: D-UNK-000-000: (Non-encrypted property) ORBCharEncoding-> ISO-8859-1

Debug: D-UNK-000-000: (Non-encrypted property) ORBDebug-> true

Debug: D-UNK-000-000: (Non-encrypted property) ORBDebugFile-> /opt/IBM/Omnibus81/omnibus/log/ORBDebugFile.log

Information: I-JPR-000-000: ORB will use host <probehost>

Information: I-JPR-000-000: ORB will use port 6060

Information: I-JPR-000-000: ORB will use this default widechar code set UTF16

Information: I-JPR-000-000: ORB will use this native encoding set for character ISO-8859-1

Information: I-JPR-000-000: ORB debug is enabled

Debug: D-UNK-000-000: (Non-encrypted property) NotificationIRPName-> com/ericsson/nms/cif/service/NMSNAConsumer

Debug: D-JPR-000-000: Resolving initial references to NamingService using hostPort for IRP: com/ericsson/nms/cif/service/NMSNAConsumer Information: I-JPR-000-000: Connecting to NotificationIRP

 

None of the Generic Probe for 3GPP CORBA is able to support the Ericsson OSS-RC Event IRP, since it requires a proprietary interface specification.

 

Events from EventIRP channel will not appear in probe log if probe is not connected/subscribed to the IRP. Otherwise, we may see events with type '1z1' as mentioned in this technote:

http://www-01.ibm.com/support/docview.wss?uid=swg21682361

 

What messages do you see when there is a connection

 

The probe retrieves an EmsSession_I while providing NmsSession_I (to the EMS server) when it first connects using getEmsSession().

 

The probe then pings EMS (EmsSession_I) periodically depending on the probe HeartbeatInterval value setting. When the probe pings the EMS, there will be debug message written as "Call emsSession.ping()...".

 

Likewise, the EMS could use NmsSession_I to ping the probe.

When the EMS pings the probe, there will be debug message written as "ClientSession.ping() called".

 

Top Tips

 

Probe's Standard features (Inherited from OIDK framework)

  • HeartbeatInterval – Interval in seconds for to check end point status.

    Inactivity - Disconnects from the endpoint if not receiving event after a period of time

    InitialResync: Resynchronise with endpoint upon startup

    ResyncInterval: Time interval to resynchronise every X seconds

    RetryCount - retry attempts if failed to connect to endpoint

    RetryInterval - Interval between retries or exponential backoff strategy (if set to 0)

     

    Supports following 3GPP Interfaces for protocol version 3.2, 5.5.1, 6.3, 6.4, 7.0, 9.0 a. Alarm IRP - 32.111-3b. Entry Point IRP - 32.363c. Notification IRP – 32.303

     

     

     

    Inactivity

    Inactivity is triggered in the probe when no new event is received in 1200 seconds, for example.

     

    Information: I-JPR-000-000: SHUTDOWN 'No events received for 1200 seconds'

     

    When triggered, the probe will perform connection cleanup and subsequently shutdown. It will then restart and reconnect to receive events.

     

     

    Number of seconds idle before probe decides to shutdown, for example

     

    Inactivity : 5

     

    Retry & Backoff Strategy Settings:

     

    HeartbeatInterval - Number of seconds before a connection status is checked

    RetryCount - Number of attempts on a retry, also determines feature is on/off.

    RetryInterval - When disconnected. The Interval used to perform a connection retry.

    0 - Gradually increases retry interval (Eg. 1s, 2s, 4s, 8s....)

    N - Retries in a fixed N seconds interval.

     

    HeartbeatInterval : 30

    RetryCount : 5

    RetryInterval : 0

     

     

     

     


    image

     

    Subscribe and follow us for all the latest information directly on your social feeds:

     

     

    image

     

    image

     

    image

     

     

      

    Check out all our other posts and updates:

    Academy Blogs:https://goo.gl/eZjStB
    Academy Videos:https://goo.gl/kJeFZE
    Academy Google+:https://goo.gl/HnTs0w
    Academy Twitter :https://goo.gl/DiJbvD
     


    image
     

    [{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

    UID

    ibm11081611