Skip to content

Commit a0553e7

Browse files
committed
OSDOCS-15203:CQA for associating secondary metrics
1 parent 20fbf2c commit a0553e7

File tree

4 files changed

+76
-60
lines changed

4 files changed

+76
-60
lines changed
Lines changed: 5 additions & 60 deletions
Original file line numberDiff line numberDiff line change
@@ -1,73 +1,18 @@
1-
// CNF-43 Associate Secondary Interfaces Metrics to Network Attachments
21
// Module included in the following assemblies:
32
//
43
// *networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc
54

5+
:_mod-docs-content-type: CONCEPT
66
[id="cnf-associating-secondary-interfaces-metrics-to-network-attachments_{context}"]
77
= Extending secondary network metrics for monitoring
88

9-
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.
9+
Secondary devices, or interfaces, are used for different purposes. Metrics from secondary network interfaces need to be classified to allow for effective aggregation and monitoring.
1010

11-
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.
11+
Exposed metrics contain the interface but do not specify where the interface originates. This is workable when there are no additional interfaces. However, relying on interface names alone becomes problematic when secondary interfaces are added because it is difficult to identify their purpose and use their metrics effectively..
1212

13-
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.
13+
When adding secondary interfaces, their names depend on the order in which they are added. Secondary interfaces can belong to distinct networks that can each serve a different purposes.
1414

1515
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.
1616

17-
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.
17+
The network type is generated from the name of the `NetworkAttachmentDefinition` resource, which distinguishes different secondary network classes. For example, different interfaces belonging to different networks or using different CNIs use different network attachment definition names.
1818

19-
[id="cnf-associating-secondary-interfaces-metrics-to-network-attachments-network-metrics-daemon_{context}"]
20-
== Network Metrics Daemon
21-
22-
The Network Metrics Daemon is a daemon component that collects and publishes network related metrics.
23-
24-
The kubelet is already publishing network related metrics you can observe. These metrics are:
25-
26-
* `container_network_receive_bytes_total`
27-
* `container_network_receive_errors_total`
28-
* `container_network_receive_packets_total`
29-
* `container_network_receive_packets_dropped_total`
30-
* `container_network_transmit_bytes_total`
31-
* `container_network_transmit_errors_total`
32-
* `container_network_transmit_packets_total`
33-
* `container_network_transmit_packets_dropped_total`
34-
35-
The labels in these metrics contain, among others:
36-
37-
* Pod name
38-
* Pod namespace
39-
* Interface name (such as `eth0`)
40-
41-
These metrics work well until new interfaces are added to the pod, for example via https://github.com/intel/multus-cni[Multus], as it is not clear what the interface names refer to.
42-
43-
The interface label refers to the interface name, but it is not clear what that interface is meant for. In case of many different interfaces, it would be impossible to understand what network the metrics you are monitoring refer to.
44-
45-
This is addressed by introducing the new `pod_network_name_info` described in the following section.
46-
47-
[id="cnf-associating-secondary-interfaces-metrics-with-network-name_{context}"]
48-
== Metrics with network name
49-
50-
This daemonset publishes a `pod_network_name_info` gauge metric, with a fixed value of `0`:
51-
52-
[source,bash]
53-
----
54-
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
55-
----
56-
57-
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.
58-
59-
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.
60-
61-
Using a `promql` query like the following ones, it is possible to get a new metric containing the value and the network name retrieved from the `k8s.v1.cni.cncf.io/network-status` annotation:
62-
63-
[source,bash]
64-
----
65-
(container_network_receive_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
66-
(container_network_receive_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
67-
(container_network_receive_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
68-
(container_network_receive_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
69-
(container_network_transmit_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
70-
(container_network_transmit_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
71-
(container_network_transmit_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
72-
(container_network_transmit_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name)
73-
----
Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
// Module included in the following assemblies:
2+
//
3+
// *networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="cnf-metrics-secondary-interfaces-by-name_{context}"]
7+
= Metrics with network name
8+
9+
The Network Metrics daemonset publishes a `pod_network_name_info` gauge metric, with a fixed value of `0`.
10+
11+
.Example of `pod_network_name_info`
12+
[source,bash]
13+
----
14+
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
15+
----
16+
17+
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.
18+
19+
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.
20+
21+
Using a `promql` query like the following ones, it is possible to get a new metric containing the value and the network name retrieved from the `k8s.v1.cni.cncf.io/network-status` annotation:
22+
23+
[source,bash]
24+
----
25+
(container_network_receive_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
26+
(container_network_receive_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
27+
(container_network_receive_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
28+
(container_network_receive_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
29+
(container_network_transmit_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
30+
(container_network_transmit_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
31+
(container_network_transmit_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
32+
(container_network_transmit_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name)
33+
----
Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
// Module included in the following assemblies:
2+
//
3+
// *networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="cnf-network-metrics-daemon_{context}"]
7+
= Network Metrics Daemon
8+
9+
The Network Metrics Daemon is a daemon component that collects and publishes network related metrics.
10+
11+
The kubelet is already publishing network related metrics you can observe. These metrics are:
12+
13+
* `container_network_receive_bytes_total`
14+
* `container_network_receive_errors_total`
15+
* `container_network_receive_packets_total`
16+
* `container_network_receive_packets_dropped_total`
17+
* `container_network_transmit_bytes_total`
18+
* `container_network_transmit_errors_total`
19+
* `container_network_transmit_packets_total`
20+
* `container_network_transmit_packets_dropped_total`
21+
22+
The labels in these metrics contain, among others:
23+
24+
* Pod name
25+
* Pod namespace
26+
* Interface name (such as `eth0`)
27+
28+
These metrics work well until new interfaces are added to the pod, for example via https://github.com/intel/multus-cni[Multus], as it is not clear what the interface names refer to.
29+
30+
The interface label refers to the interface name, but it is not clear what that interface is meant for. In case of many different interfaces, it would be impossible to understand what network the metrics you are monitoring refer to.
31+
32+
This is addressed by introducing the new `pod_network_name_info` described in the following section.

networking/advanced_networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,4 +6,10 @@ include::_attributes/common-attributes.adoc[]
66

77
toc::[]
88

9+
Administrators can use the `pod_network_info` metric to classify and monitor secondary network interfaces. The metric does this by adding a label that identifies the interface type, typically based on the associated `NetworkAttachmentDefinition` resource.
10+
911
include::modules/cnf-associating-secondary-interfaces-metrics-to-network-attachments.adoc[leveloffset=+1]
12+
13+
include::modules/cnf-network-metrics-daemon.adoc[leveloffset=+1]
14+
15+
include::modules/cnf-metrics-secondary-interfaces-by-name.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)