VMware vRealize Network Insight System Defined Events

Products

• VMware Aria Operations for Networks

Issue/Introduction

Purpose of this article is to share information with regards to the multiple System defined events recorded/collected in VMware vRealize Network Insight.

Resolution

There are events in vRNI which are computed internally based on the data it gathers from different sources. These events are opened and closed based on the data polling that we do.

There are some events which are raised by NSX Manager as well, these are called System Events. There are hundreds of System Event defined in NSX and vRNI collects these events based on their severity.

There are some of the event for which we have specific mapping/name and rest all are mapped to generic.

The specific mapping/name events are below:

1.      NSX Manager to Edge VM communication failure
2.      NSX Edge VM not in active/self state
3.      NSX Edge to NSX Manager heartbeat failed
4.      Host messaging configuration update failed
5.      Host messaging connection re-config failed
6.      Host messaging channel between host and NSX Manager failed to re-establish
7.      Host messaging infrastructure down on host
8.      Distributed firewall update for host vNIC failed to be applied
9.      Distributed firewall update failed to be applied to host
10.  Distributed firewall configuration update failed
11.  SpoofGuard configuration update failed
12.  Distributed firewall rule not applied to host vNIC
13.  Distributed firewall container update failed on host
14.  SpoofGuard initial configuration failed

The generically mapped events are:

1.      NSX system event (warning)
2.      Critical NSX System Event

All of the above NSX System Events are shown with the "Event Code", which can be looked into NSX Manager page and also searchable on the internet to get more details around the issue. It's good to tell the event code in case of any conversation with NSX GSS.
 
For more information regarding how these events were introduced and how the events are closed, please refer to Related Information section

Please Note:

1. The above information is for NSX-v and not NSX-T.
2.  vRNI has not  converted any NSX-T system event to vRNI specific event. All event will come under “NSX-T System  Event”.
 

Additional Information

The reason for specific mapping/name is historical. When vRNI (Arkin) started introducing these events which were collected from NSX Manager, the idea was to show only few of the events which were major pain point at that time. With time, NSX Manager came up with lots of new System Events and still keep adding more with new releases. So we thought of mapping these events into generic name.

The way NSX Manager closes these system events is that there is CLOSE event for some of the events, and not for all. What it means is that, when NSX Manager OPEN the event, there might come a CLOSE event as well for it, but not all the event type has CLOSE event associated. The only way to determine that the OPEN problem (for which the CLOSE doesn't exist) is closed is to wait and see if the NSX Manager has re-send the OPEN event again or not. NSX Manager periodically re-send/re-open the event if the problem still persists. For these kind of System Event (which doesn't have CLOSE event associated), vRNI waits for few hours (2-4 hours) to make sure that the problem is not seen again by NSX Manager and then closes it in vRNI.
 
For all other events which are computed in vRNI, the opening and closing depends on the data gathered through polling.