Skip to content

Commit 2f8212b

Browse files
committed
wip
1 parent 00bd7c9 commit 2f8212b

File tree

3 files changed

+72
-0
lines changed

3 files changed

+72
-0
lines changed
Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
# Network Observability On Demand 1.8 Update
2+
3+
![logo]({page.image('cli-whats-new-1-8/cli_logo.png')})
4+
5+
By: Julien Pinsonneau
6+
7+
Since we [introduced the Network Observability CLI](./2024-07-25-cli.md), numerous features have been added. This article will cover the improvements in version 1.8 and provide some concrete examples.
8+
9+
## New Options Available
10+
This update adds several options to the CLI, covering more scenarios and enabling scripting on top of the tool.
11+
12+
### Run in Background
13+
The `--background` option allows you to start a flow or packet capture without connecting your terminal to the collector pod. This enables you to let the capture run in the background while you work on something else. You can check the capture's progress using the `follow` command and copy the collector output locally using the `copy` command. Once the job is complete, you can `stop` or `cleanup` everything.
14+
15+
### Custom Namespace
16+
You can now customize the capture namespace using the `NETOBSERV_NAMESPACE` environment variable. When the CLI starts, it automatically checks if this namespace exists and will stop if it finds any conflict with a pending capture. This is particularly useful if you want to run captures in parallel.
17+
18+
### Subnets Labelling
19+
The tool can now read configurations from `cluster-config-v1` and `network` to identify **Machine**, **Pods**, and **Services** subnets using the `--get-subnet` option. This will automatically add `SrcSubnetLabel` and `DstSubnetLabel` to your flows.
20+
21+
### YAML Output
22+
Outputting a `.yml` file instead of running the capture is now possible using the `--yaml` option. The file will contain all the resources needed to run the capture, such as the namespace, the agents embedding the pipeline and its configuration, and the related services. The collector will need to be run manually in parallel to start the capture.
23+
24+
## Advanced Filtering
25+
Filtering is crucial to gather precise network data without involving excessive resources and storage. The CLI focuses on this area, allowing you to deploy agents only where needed and fine-tune what's captured.
26+
27+
### NodeSelector
28+
It's now possible to define agents `nodeSelector` to capture on a subset of nodes. You can rely on existing labels or create a dedicated one for this usage. For example, you can run:
29+
```sh
30+
`oc netobserv flows --node-selector=kubernetes.io/hostname:my-node
31+
```
32+
to run the agents on the node with the `kubernetes.io/hostname:my-node` label.
33+
34+
### eBPF Filters
35+
Agents recently introduced the ability to filter on IPs, Ports, Protocol, Action, TCPFlags, and more simultaneously. You can now apply these filters in the CLI as shown below:
36+
37+
```sh
38+
netobserv flows \ # Capture flows
39+
--protocol=TCP --port=8080 \ # either on TCP 8080
40+
or --protocol=UDP # or UDP
41+
```
42+
43+
You can add as many filters as you want and separate them by or to create multiple capture scenarios.
44+
45+
### Regular Expressions
46+
If you need to filter on enriched content beyond the agent-level filters, you can use **regexes** to match any field/value pair. To filter all traffic from OpenShift namespaces, for example, you can use `--regexes=SrcK8S_Namespace~openshift.*`.
47+
48+
Regexes are comma-separated, so you can use multiple at once, such as `--regexes=SrcK8S_Namespace~my-ns,SrcK8S_Name~my-app`. Refer to the [flows format](https://github.com/netobserv/network-observability-operator/blob/main/docs/flows-format.adoc) to see the possible fields.
49+
50+
## Unified Collector UI
51+
Capturing packets now resembles flow capture, allowing you to live filter the content. This improvement was made possible by introducing the [flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline) component inside eBPF agents, which parse packets and generate flows from them. All filtering capabilities are compatible with this approach!
52+
53+
## Metrics Capture on OpenShift
54+
Capturing metrics is now possible using the `metrics` command. This creates a `ServiceMonitor` to gather metrics from the agents and store them in [Prometheus](https://prometheus.io/). You can enable all or specific features to gather more information about your network, such in:
55+
```sh
56+
oc netobserv metrics --enable_all
57+
```
58+
to capture packet drops, DNS and RTT metrics or
59+
```sh
60+
oc netobserv metrics --enable_pktdrop
61+
```
62+
to focus only on drops.
63+
64+
On top of the features, you can use all the filtering capabilities mentioned above to focus on what you're looking for. A `NetObserv / On Demand` dashboard will be automatically created, showing the results.
65+
66+
![dashboard]({page.image('cli-whats-new-1-8/dashboard.png')})
67+
68+
## Feedback
69+
We hope you enjoyed this article!
70+
71+
Netobserv is an OpenSource project [available on github](https://github.com/netobserv).
72+
Feel free to share your [ideas](https://github.com/netobserv/network-observability-operator/discussions/categories/ideas), [use cases](https://github.com/netobserv/network-observability-operator/discussions/categories/show-and-tell) or [ask the community for help](https://github.com/netobserv/network-observability-operator/discussions/categories/q-a).
2.49 KB
Loading
1.56 MB
Loading

0 commit comments

Comments
 (0)