Missing context data in TN alarm's description/recommended action when TN and manager are in different versions
Article ID: 345756
Updated On:
Products
VMware NSX Networking
Issue/Introduction
Symptoms:
Alarm context data key might change in different releases. The alarm framework has logic to only send current version supported alarm context key-value pairs to syslog/alarms collector/snmp trp. So if a TransportNode (e.g. edge node or host node) and manager are in different versions, the TN will only send its version's supported context key-values pairs to manager, which might be different than what manager supported. This will result in missing context data in TN alarm's description/recommended action if TN nodes and manager nodes are in different versions.
Alarm context data key might change in different releases. The alarm framework has logic to only send current version supported alarm context key-value pairs to syslog/alarms collector/snmp trp. So if a TransportNode (e.g. edge node or host node) and manager are in different versions, the TN will only send its version's supported context key-values pairs to manager, which might be different than what manager supported. This will result in missing context data in TN alarm's description/recommended action if TN nodes and manager nodes are in different versions.
Environment
VMware NSX-T
Cause
Here is an example:
For edge_health.edge_cpu_usage_high alarm,
In 3.2.x the context data’s keys that feature send to the alarm framework are: entity_id, system_resource_usage
In 3.2.x, alarm framework support keys are: entity_id, system_resource_usage.
In 4.2, the context data’s keys that feature sent to the alarm framework are: entity_id, transport_node_name, transport_node_address, system_resource_usage.
In 4.2, alarm framework support keys are: transport_node_name, transport_node_address, system_resource_usage
So with a 4.2 edge and a 3.2.x NSX manager, the edge will only send context key-value pairs: transport_node_name, transport_node_address, system_resource_usage to 3.2.x manager. But 3.2.x manager also needs "entity_id" to fulfill its description, so the user will see "The CPU usage on Edge node {{entity_id}} has reached 90%" in Description in 3.2.x manager.
For edge_health.edge_cpu_usage_high alarm,
In 3.2.x the context data’s keys that feature send to the alarm framework are: entity_id, system_resource_usage
In 3.2.x, alarm framework support keys are: entity_id, system_resource_usage.
In 4.2, the context data’s keys that feature sent to the alarm framework are: entity_id, transport_node_name, transport_node_address, system_resource_usage.
In 4.2, alarm framework support keys are: transport_node_name, transport_node_address, system_resource_usage
So with a 4.2 edge and a 3.2.x NSX manager, the edge will only send context key-value pairs: transport_node_name, transport_node_address, system_resource_usage to 3.2.x manager. But 3.2.x manager also needs "entity_id" to fulfill its description, so the user will see "The CPU usage on Edge node {{entity_id}} has reached 90%" in Description in 3.2.x manager.
Resolution
Once the NSX Manager has been upgraded to the same version, the symptom will be eliminated. All the alarms will be deleted after manager upgrade(and if the issue is still there, a new alarm will raise and since the edge and manager's version match now, the description/recommended action will be filled with the expected context data).
Feedback
Yes
No
Powered by
