Configuring receipt of CommuniGate Pro events
You can configure the receipt of CommuniGate Pro 6.1 events in KUMA. Integration is only possible when sending events via syslog using the TCP protocol. The resources described in this article are available for KUMA 3.0 and newer versions. Processing of SIP module events is supported (such events contain the "SIPDATA" character sequence).
Configuring event receiving consists of the following steps:
- Configuring CommuniGate Pro to send events
- Configuring the KUMA collector for receiving CommuniGate Pro events
- Verifying receipt of CommuniGate Pro events in the KUMA collector
You can verify that the CommuniGate Pro event source server is correctly configured in the Searching for related events section of the KUMA web interface.
The CommuniGate Pro system generates an audit event as several separate records that look like this:
<event code> timestamp ID direction: information from base event 1
<event code> timestamp ID direction: information from base event 2
<event code> timestamp ID direction: base information n
A set of KUMA resources is used to process CommuniGate Pro events; this set of resources must be applied when creating a collector:
- Normalizer
- Aggregation rule
- Filters for destinations
The collector aggregates multi-line base events based on event ID, normalizes them, and sends the aggregated event to the storage and the correlator.
The aggregated event has the following form:
Service information from the aggregation rule: ID: information from base event 1, information from base event 2, information from base event n
After aggregation, the received event is sent to the same collector where the aggregated event is normalized.
Processing algorithm for CommuniGate Pro events
The following algorithm was implemented to process CommuniGate Pro events:
- Initial normalization
At this stage, the initial normalization of base events is performed. The first character in the base event is a numeral. The events are brought to a format suitable for subsequent aggregation: the first character is extracted from the event and put into the DeviceCustomString1 field, the identifier is put into the ExternalID field, and the host name is put into the DeviceHostName field. Basic normalization is performed in the main normalizer.
- Checking for aggregation
The event is examined to see if it is aggregated or not. As a result, non-aggregated events (the first character is a numeral) have an aggregation rule applied, and then aggregated events are sent to re-normalization. Aggregation is performed using the "[OOTB] CommuniGate Pro. Aggregation rule".
- Applying the aggregation rule
At this stage, the aggregation rule is applied to the events, the base events are collated and take the following form:
Service information from the aggregation rule: ID: information from base event 1, information from base event 2, information from base event n
After aggregation, the collated event is sent back to the same collector to subject the aggregated event to normalization.
To close the event processing loop, you must specify the same collector as the destination. In the diagram, the destination is named "Loop" to draw attention to the event processing loop. You can give an arbitrary name to your destination.
- Normalization of the aggregated event
Normalization of the aggregated event that begins with a "{" character is performed in the following extra normalizers: Aggregated events, Aggregated events - kv part.
- Sending to storage and the correlator
Aggregated and normalized events are sent to storage and the correlator.
The following figure shows the flow chart of CommuniGate Pro event processing.
