|
1 | | -// CNF-43 Associate Secondary Interfaces Metrics to Network Attachments |
2 | 1 | // Module included in the following assemblies: |
3 | 2 | // |
4 | 3 | // *networking/associating-secondary-interfaces-metrics-to-network-attachments.adoc |
5 | 4 |
|
| 5 | +:_mod-docs-content-type: CONCEPT |
6 | 6 | [id="cnf-associating-secondary-interfaces-metrics-to-network-attachments_{context}"] |
7 | 7 | = Extending secondary network metrics for monitoring |
8 | 8 |
|
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. |
10 | 10 |
|
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.. |
12 | 12 |
|
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. |
14 | 14 |
|
15 | 15 | 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. |
16 | 16 |
|
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. |
18 | 18 |
|
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 | | ----- |
0 commit comments