CORBA Collector

The Oracle Communications Unified Assurance CORBA Collector microservice is part of the microservice event pipeline. The CORBA Collector collects Multi-Technology Network Management (MTNM) Common Object Request Broker Architecture (CORBA) events from external Element Management Systems (EMS) and Network Management Systems (NMS) and converts them to Unified Assurance events for further processing.

CORBA Collector Flow

CORBA messages are collected and processed by the CORBA Collector as follows:

The CORBA Collector loads connection details from environment variables and connects to the NMS or EMS.
The NMS or EMS sends CORBA events to the CORBA Collector.
The CORBA Collector transforms the events from StructuredEvent Java objects to Unified Assurance collection events.
The CORBA Collector sends the transformed events to the Pulsar assure1/event/collection topic.
The topic sends the event to the FCOM Processor microservice to be normalized and inserted into the Event database.
A Unified Assurance user can view and manage the events in the user interface.

CORBA Event Details

The following event types are supported:

NT_ALARM
NT_TCA

You can choose either one or both of these by setting the CORBA_NOTIFICATION_TYPES microservice configuration parameter as shown in "Default Configurations".

The CORBA Collector supports any vendor with the TMF MTNM standard of NT_ALARM and NT_TCA.

Example CORBA Event

The following example shows an incoming CORBA event that would be accepted by the CORBA Collector.

name: notificationId value: 1
name: objectName value:
    name: EMS value:ExampleEMS
    name: ManagedElement value:ExampleElement
name: nativeEMSName value:ExampleEMSName
name: objectType value:OT_MANAGED_ELEMENT
name: emsTime value:20230828124734.0
name: neTime value:20230828124734.0
name: isClearable value:TRUE
name: layerRate value:15
name: perceivedSeverity value:PS_MAJOR
name: nativeProbableCause value:Disconnection
name: probableCause value:EMS
name: probableCauseQualifier value:
name: serviceAffecting value:SA_UNKNOWN
name: affectedTPList value:
name: rcaiIndicator value:FALSE
name: additionalText value:
name: additionalInfo value:
    name: LSNExt_AckStatus value:ALM_UNACKNOWLEDGED
    name: LSNExt_MEName value:ExampleEMSName
    name: LSNExt_ALCV value:Unknown
    name: LSNExt_AlarmUniqueString value: EMS DN=ExampleEMSDN, EMS notifId=Not Relevant, CAM ID=1234567
    name: LSNExt_GroupName value: ExampleNMS

After processing by the CORBA Collector, the event would look as follows:

{
    "@timestamp": "<timestamp>",
    "_agents": [{
        "@timestamp": "<timestamp>",
        "host": "<POD Name>",
        "app": "corba-collector",
        "version": "1.0.0",
        "input": "<NMS Connection url>",
        "output": "persistent://assure1/event/collection"
    }],
    "_domain": "tmf_mtnm",
    "_type": "corba",
    "corba": {
        "rcaiIndicator": "false",
        "probableCauseQualifier": "",
        "serviceAffecting": "SA_UNKNOWN",
        "additionalText": "",
        "neTime": "20230828124734.0",
        "emsTime": "20230828124734.0",
        "corbaEventType": "VendorName",
        "objectType": "OT_MANAGED_ELEMENT",
        "perceivedSeverity": "PS_MAJOR",
        "probableCause": "EMS",
        "nativeEMSName": "ExampleEMSName",
        "layerRate": "15",
        "nativeProbableCause": "Disconnection",
        "additionalInfo": {
            "LSNExt_GroupName": "ExampleNMS",
            "LSNExt_MEName": "ExampleEMSName",
            "LSNExt_ALCV": "Unknown",
            "LSNExt_AckStatus": "ALM_UNACKNOWLEDGED",
            "LSNExt_AlarmUniqueString": "EMS DN=ExampleEMSDN, EMS notifId=Not Relevant, CAM ID=1234567"
        },
        "objectName": {
            "ManagedElement": "ExampleElement",
            "EMS": "ExampleEMS"
        },
        "notificationId": "1",
        "isClearable": "true",
        "affectedTPList": ""
    }
}

The value of corbaEventType is mapped from the CORBA_EMS_VENDOR configuration variable and helps match the rule for event processing in the FCOM processor.

CORBA Foundation Rules

You can see the default foundation rules for CORBA, as well as the rules for Ribbon (formerly ECI) and Tejas, in the Configuration interface for Rules, under Core Rules, in one of the default branches at the following location:
processing -> event -> fcom -> _objects -> corba.

You can customize these rules for your environment and vendors.

See "Rules" in Unified Assurance User's Guide for more information about using the Configuration interface.

Customizing the Default CORBA Foundation Rules and the Vendor Rules

To customize the CORBA foundation rules:

Go to the Configuration interface for Rules, under Core Rules, and find the following location in the default read-write branch:
processing -> event -> fcom -> _objects -> corba
To customize the default rules, go to the default folder and modify the existing JSON file. To customize the rules for a vendor, go to the specified vendor folder and modify the JSON file.
Delete the existing deployment of the FCOM processor and redeploy it using the CORBA microservice Helm Chart.

Prerequisites

Before installing the CORBA Collector microservice, set up the following:

A microservices cluster. See "Microservice Cluster Setup".
The Apache Pulsar microservice. See "Pulsar".
The FCOM Processor microservice. See "FCOM Processor".
The Event Sink microservice. See "Event Sink."
The CORBA server URI.
A Kubernetes Secret for the EMS username and password. Run the following command as the assure1 user:
```
a1k create secret generic <release-name>-secret --from-literal=emsUserName=<username> --from-literal=emsPwd='<password>' -n <namespace>
```
where :
- <release-name> is the release name of the CORBA collector deployment from the user interface.
- <username> is the EMS username.
- <password> is the EMS password.
- <namespace> is the namespace.

Setup

Standard Single Server deployment:

su - assure1
export NAMESPACE=a1-zone1-pri
export WEBFQDN=<Primary Presentation Web FQDN> 
a1helm install corba-collector assure1/corba-collector -n $NAMESPACE --set global.imageRegistry=$WEBFQDN

Standard Multi-Server deployment and starts the microservice on a specific node:

su - assure1
export NAMESPACE=a1-zone1-pri
export WEBFQDN=<Primary Presentation Web FQDN>
export NODEFQDN=<Cluster Target Node FQDN>
a1helm install corba-collector assure1/corba-collector -n $NAMESPACE --set global.imageRegistry=$WEBFQDN --set nodeSelector."kubernetes\.io/hostname"=$NODEFQDN

Default Configuration

This table shows the default values for the CORBA Collector configuration parameters. You can view or change these parameters in the Helm chart for the microservice.

Name	Value	Possible Values	Notes
LOG_LEVEL	INFO	FATAL, ERROR, WARN, INFO, DEBUG	The logging level used by the application.
STREAM_INPUT	No default value		For example: corbaloc://<IP>:<port>/NameService
STREAM_OUTPUT	persistent://assure1/event/collection	Text, 255 characters	The Apache Pulsar topic path. The topic at the end of the path may be any text value.
CORBA_EMS_CLASS_TYPE	No default value	Text	The class type. For example: TMF_MTNM
CORBA_EMS_VENDOR	No default value	Text	The vendor name. For example: TejasNetworks
CORBA_EMS_INSTANCE	No default value	Text	The EMS instance name. For example: TejasNetworks/TTMLTejEMS-1
CORBA_EMS_VERSION	No default value	Text	The EMS version. For example: 3.5
CORBA_EMS_SESSION_FACTORY	No default value	Text	The EMS session factory name. For example: TTMLTejEMS-1
CORBA_FILTER_TYPE	TCL	TCL, EXTENDED_TCL	The filter type. Its value is set to TCL for Tejas and EXTENDED_TCL for Ribbon (formerly ECI).
CORBA_NOTIFICATION_TYPES	No default value	NT_ALARM,NT_TCA	The notification types. A case-sensitive field that contains all notification types which can be processed. Each notification type should be separated by a “,”. For example: NT_ALARM,NT_TCA
CORBA_EMS_SESSION_CONNECTIVITY_RETRY_INTERVAL	120	Integer	The EMS connection retry interval, in seconds.
CORBA_EMS_MULTI_USER_FLAG	False	True, False	Whether the EMS can be logged into with multiple sets of credentials (True) or only one set of credentials (False). True or False should be passed as text, which will be parsed as Boolean true/false in the code.
REDUNDANCY_POLL_PERIOD	5	Integer	How often the secondary service checks to see if the primary is online, in seconds.
REDUNDANCY_FAILOVER_THRESHOLD	4	Integer	The number of failed polls before the secondary becomes the active application.
REDUNDANCY_FALLBACK_THRESHOLD	1	Integer	The number of successful polls before the secondary goes back to sleep.

Example of setting the log level to DEBUG

By default, the log level is set to INFO. You can change it using the following command:

a1helm install ... --set configData.LOG_LEVEL=DEBUG

Troubleshooting

If you can't connect to the CORBA URI configured in STREAM_INPUT, do the following:

Open the Helm Chart for the CORBA Collector microservice.
Add the following code snippet to the Helm deployment at the end of the Helm Chart:
```
hostAliases:
- ip: <ip>
  hostnames:
  - <hostname>
```
Redeploy the Helm Chart.

About CORBA Collector Redundancy

By default, redundancy is not enabled. You can enable it using the following command:

a1helm install ... --set redundancy.enabled=true

Because of limitations related to NMS session management, you can only establish one session for each NMS instance. The following redundancy use cases are supported:

Failover:
- The primary pod is evicted due to resource unavailability:
  - Kubernetes tries to respin the pod within milliseconds.
  - If the resources become available, the primary pod is brought back up to continue receiving events.
  - If the resources are not available, the primary pod's status is set to pending and the secondary pod starts receiving the events until the resources can be allocated to the primary again.
- The primary pod can't reach the network:
  - The primary pod keeps trying to connect to the NMS.
  - If the primary pod is unable to establish a connection after a certain number of retries, it updates a metric which lets the secondary pod know of the connection failure.
  - The secondary pod then establishes the connection with the NMS and continues processing the events until the primary pod network issue is resolved.
- The primary pod and the secondary pod can't reach each other, also known as the split brain scenario:
  - The primary pod is up and actively receiving events, but the redundancy poller does not receive a response from the primary pod and starts failover.
  - Since the primary pod has already established the session, the secondary pod will not be able to acquire it. It will exhaust the number of retries available before it terminates.
- The connection between the NMS and the active subscribers is broken, even though there are active sessions:
  - The event listener is not able to receive any events.
  - This is related to active monitoring of pods and of events received by Unified Assurance. In such cases, you should restart the pods manually.
Fallback to primary:
- The primary is up and, as part of the initialization, the metrics endpoint is active:
  - The primary tries to establish a session for the NMS instance but it gets an exception as the secondary already has an active session.
  - The secondary poller verifies and starts the fallback process by releasing all session resources.
  - By the time the primary retries establishing the NMS session for the second time, it will be available to acquire and establish the connection.

In situations where multiple users are available for the primary and secondary pod, you must create secrets of the same name separately in both clusters. Each pod running in the cluster will pick up their respective username and password to establish the connection to the NMS. A split brain scenario with multiple users may result in duplicate records, which is a known issue across all the Unified Assurance microservices.

For general information about redundancy in microservices, see "Cross-Data Center Redundancy" in Unified Assurance Concepts.

Title and Copyright Information

Implementation Guide

F88952-01