Merge pull request #50648 from ShaunaDiaz/GHI46046

Author: maxwelldb

modules/cnf-associating-secondary-interfaces-metrics-to-network-attachments.adoc

@@ -4,15 +4,15 @@
 // *networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc
 
 [id="cnf-associating-secondary-interfaces-metrics-to-network-attachments_{context}"]
-= Associating secondary interfaces metrics to network attachments
+= Extending secondary network metrics for monitoring
 
 Secondary devices, or interfaces, are used for different purposes. It is important to have a way to classify them to be able to aggregate the metrics for secondary devices with the same classification.
 
-Exposed metrics contain the interface but do not specify where the interface originates. This is workable when there are no additional interfaces, but if a secondary interface is added, it is difficult to make use of the metrics since it is hard to identify the interfaces using only the interface name as an identifier.
+Exposed metrics contain the interface but do not specify where the interface originates. This is workable when there are no additional interfaces. However, if secondary interfaces are added, it can be difficult to use the metrics since it is hard to identify interfaces using only interface names.
 
 When adding secondary interfaces, their names depend on the order in which they are added, and different secondary interfaces might belong to different networks and can be used for different purposes.
 
-With `pod_network_name_info` it is possible to extend the current metrics with the additional information that identifies the interface type. In this way, it is possible to aggregate the metrics and to add specific alarms to specific interface types.
+With `pod_network_name_info` it is possible to extend the current metrics with additional information that identifies the interface type. In this way, it is possible to aggregate the metrics and to add specific alarms to specific interface types.
 
 The network type is generated using the name of the related `NetworkAttachmentDefinition`, that in turn is used to differentiate different classes of secondary networks. For example, different interfaces belonging to different networks or using different CNIs use different network attachment definition names.
 
@@ -54,7 +54,7 @@ This daemonset publishes a `pod_network_name_info` gauge metric, with a fixed va
 pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
 ----
 
-The network name label is produced using the annotation added by Multus. It ia the concatenation of the namespace the network attachment definition belongs to, plus the name of the network attachment definition.
+The network name label is produced using the annotation added by Multus. It is the concatenation of the namespace the network attachment definition belongs to, plus the name of the network attachment definition.
 
 The new metric alone does not provide much value, but combined with the network related `container_network_*` metrics, it offers better support for monitoring secondary networks.