From f4a387a1a977a7ce170c9d29d1c7b074a92204c9 Mon Sep 17 00:00:00 2001 From: Joel Takvorian Date: Wed, 25 Mar 2026 10:18:14 +0100 Subject: [PATCH] Fix github links --- content/about.md | 8 +++++--- content/posts/2022-12-12-3d_topology.md | 2 +- content/posts/2023-10-02-lokiless.md | 4 ++-- content/posts/2023-12-05-acm.md | 4 ++-- content/posts/2024-02-28-whats_new_1_5.md | 2 +- content/posts/2024-04-05-agent_metrics_perf.md | 2 +- content/posts/2024-07-25-cli.md | 6 +++--- content/posts/2024-10-23-whats_new_1_6.md | 4 ++-- content/posts/2025-02-11-cli_whats_new_1.8.md | 2 +- content/posts/2025-02-13-perf-improvements/index.md | 2 +- content/posts/2025-02-26-whats-new-1-8/index.md | 2 +- content/posts/2025-07-17-whats-new-1-9/index.md | 2 +- content/posts/2025-10-28-flow-matrix/index.md | 4 ++-- content/posts/2025-10-28-whats-new-1-10/index.md | 4 ++-- content/posts/2026-02-02-whats-new-1-11/index.md | 4 ++-- content/posts/2026-03-02-subnet-labels/index.md | 8 ++++---- content/start.md | 4 ++-- templates/layouts/roq-default/main.html | 2 +- templates/layouts/roq-default/post.html | 2 +- 19 files changed, 35 insertions(+), 33 deletions(-) diff --git a/content/about.md b/content/about.md index 6127369..f9e142e 100644 --- a/content/about.md +++ b/content/about.md @@ -1,15 +1,17 @@ --- title: About description: | - NetObserv aka Network Observability is a set of components used to observe network traffic by generating NetFlows from eBPF agents, enrich those flows using a configurable pipeline that is Kubernetes-aware, export them in various ways (logs, metrics, Kafka, IPFIX...), and finally provide a comprehensive visualization tool for making sense of that data, and a CLI. Those components can be used as standalones or deployed in Kubernetes / OpenShift via an integrated Operator. + NetObserv aka Network Observability is a set of components used to observe network traffic by generating network flows from eBPF agents, enrich those flows using a configurable pipeline that is Kubernetes-aware, export them in various ways (logs, metrics, Kafka, IPFIX...), and finally provide a comprehensive visualization tool for making sense of that data, and a CLI. Those components can be used as standalones or deployed in Kubernetes via an operator. layout: :theme/page --- # About NetObserv -NetObserv is a set of components used to observe network traffic by generating NetFlows from [eBPF agents](https://github.com/netobserv/netobserv-ebpf-agent), enriching those flows using [a configurable pipeline](https://github.com/netobserv/flowlogs-pipeline/) which is Kubernetes-aware, exporting them in various ways (logs, metrics, Kafka, IPFIX...), and finally providing a comprehensive [visualization tool](https://github.com/netobserv/network-observability-console-plugin/) for making sense of that data, and [a CLI](https://github.com/netobserv/network-observability-cli). Those components can be used as standalones or deployed in Kubernetes / OpenShift via an [integrated Operator](https://github.com/netobserv/network-observability-operator/). +NetObserv is a set of components used to observe network traffic by generating network flows from [eBPF agents](https://github.com/netobserv/netobserv-ebpf-agent), enriching those flows using [a configurable pipeline](https://github.com/netobserv/flowlogs-pipeline/) which is Kubernetes-aware, exporting them in various ways (logs, metrics, Kafka, IPFIX...), and finally providing a comprehensive [visualization tool](https://github.com/netobserv/netobserv-web-console/) for making sense of that data, and [a CLI](https://github.com/netobserv/netobserv-cli). Those components can be used as standalones or deployed in Kubernetes with an [operator](https://github.com/netobserv/netobserv-operator/). -It is known and distributed in Red Hat OpenShift as the [Network Observability operator](https://docs.openshift.com/container-platform/latest/observability/network_observability/network-observability-operator-release-notes.html). +It is fully open-source and, for the most part, CNI-agnostic (some features such as monitoring network policy events are CNI-dependent). + +It is known and distributed in Red Hat OpenShift as the [Network Observability operator](https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/installing-network-observability-operators). ## Topology view diff --git a/content/posts/2022-12-12-3d_topology.md b/content/posts/2022-12-12-3d_topology.md index f1f313e..4e44f0e 100644 --- a/content/posts/2022-12-12-3d_topology.md +++ b/content/posts/2022-12-12-3d_topology.md @@ -113,7 +113,7 @@ One of the next implementations is going to be [sankey chart](https://observable ## We need you ! -Feel free to contribute by commenting this post, opening issues in [netobserv console plugin](https://github.com/netobserv/network-observability-console-plugin/issues) or opening pull request in any [netobserv component](https://github.com/netobserv) +Feel free to contribute by commenting this post, opening issues in [netobserv console plugin](https://github.com/netobserv/netobserv-web-console/issues) or opening pull request in any [netobserv component](https://github.com/netobserv) Tell us more about your expectations, the way you currently solve issues and what could help your daily experience. diff --git a/content/posts/2023-10-02-lokiless.md b/content/posts/2023-10-02-lokiless.md index a0c001c..00e8164 100644 --- a/content/posts/2023-10-02-lokiless.md +++ b/content/posts/2023-10-02-lokiless.md @@ -47,7 +47,7 @@ For simplicity, ClickHouse is deployed locally and [ktunnel](https://github.com/ ### Prerequisites - An OpenShift or Kubernetes cluster -- [NetObserv operator](https://github.com/netobserv/network-observability-operator) installed (do not install a `FlowCollector` yet). +- [NetObserv operator](https://github.com/netobserv/netobserv-operator) installed (do not install a `FlowCollector` yet). - ClickHouse binary: grab it as explained in their [quick install guide](https://clickhouse.com/docs/en/install#quick-install). - [ktunnel](https://github.com/omrikiei/ktunnel) binary. - Some common tools such as `curl`, `kubectl`, `envsubst`... @@ -88,7 +88,7 @@ It creates a `clickhouse` service in the `default` namespace, bridged to your lo ### Prepare Kafka -The steps here are very similar to the [Kafka deployment script](https://github.com/netobserv/network-observability-operator/blob/release-1.4/.mk/development.mk#L54-L63) that we use in NetObserv for development and testing purposes. They use [Strimzi](https://strimzi.io/) - the upstream of AMQ Streams for OpenShift - to get Kafka in the cluster, and a topic named "flows-export" is pre-created. +The steps here are very similar to the [Kafka deployment script](https://github.com/netobserv/netobserv-operator/blob/release-1.4/.mk/development.mk#L54-L63) that we use in NetObserv for development and testing purposes. They use [Strimzi](https://strimzi.io/) - the upstream of AMQ Streams for OpenShift - to get Kafka in the cluster, and a topic named "flows-export" is pre-created. ```bash # Create a namespace for all the deployments diff --git a/content/posts/2023-12-05-acm.md b/content/posts/2023-12-05-acm.md index 434fefd..16855ca 100644 --- a/content/posts/2023-12-05-acm.md +++ b/content/posts/2023-12-05-acm.md @@ -56,7 +56,7 @@ If you're running NetObserv 1.5 or above, edit the `FlowCollector` resource, fin - `workload_egress_packets_total` - `workload_ingress_packets_total` -This adds metrics used in later steps. [Take a look](https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md) at the available metrics if you want to customize this setup further. +This adds metrics used in later steps. [Take a look](https://github.com/netobserv/netobserv-operator/blob/main/docs/Metrics.md) at the available metrics if you want to customize this setup further. If you are only interested in metrics, you don't need to install and enable Loki. Read more about that [here](https://cloud.redhat.com/blog/deploying-network-observability-without-loki-an-example-with-clickhouse). But while NetObserv doesn't currently provide an out-of-the-box experience for viewing multi-cluster logs from Loki, these flow logs are still the most detailed and accurate data available when it comes to troubleshooting the network per cluster, providing a finer insight than metrics. @@ -255,6 +255,6 @@ We would end up with these two new rules: Be careful about escaping double-quotes, though it's not very pretty, it is necessary: else you would end up with a parsing error. Also, the `label_replace` chained calls here could be avoided as they look messy, but they make it actually easier to manipulate those metrics later on, in Grafana. -Also, don't forget that NetObserv has [more metrics to show](https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md), especially starting from the coming-soon release 1.5, such as TCP latencies, [packet drop](https://cloud.redhat.com/blog/network-observability-real-time-per-flow-packets-drop) counters and so on. And just for teasing, we are working on a fresh new API in NetObserv that will soon let you build pretty much any metric you want out of flow logs, for even more dashboarding possibilities. +Also, don't forget that NetObserv has [more metrics to show](https://github.com/netobserv/netobserv-operator/blob/main/docs/Metrics.md), especially starting from the coming-soon release 1.5, such as TCP latencies, [packet drop](https://cloud.redhat.com/blog/network-observability-real-time-per-flow-packets-drop) counters and so on. And just for teasing, we are working on a fresh new API in NetObserv that will soon let you build pretty much any metric you want out of flow logs, for even more dashboarding possibilities. If you want to get in touch with the NetObserv team, you can use our [discussion board](https://github.com/orgs/netobserv/discussions). diff --git a/content/posts/2024-02-28-whats_new_1_5.md b/content/posts/2024-02-28-whats_new_1_5.md index 631efb5..fad2e5f 100644 --- a/content/posts/2024-02-28-whats_new_1_5.md +++ b/content/posts/2024-02-28-whats_new_1_5.md @@ -57,7 +57,7 @@ In "Processor configuration", the changes are to enable availability zones, clus ![Processor configuration]({page.image('whats-new-1-5/processor-configuration.png')}) _
Figure 4: Processor configuration
_ -The full list of predefined metrics is [here](https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md). When you include a metric, it stores it in Prometheus and is available as a Prometheus metric prefixed with "netobserv_". For example, if you add the metric *namespace_egress_bytes_total*, then go to **Observe > Metrics** and enter the PromQL `sum(rate(netobserv_namespace_egress_bytes_total[1m]))`. This should display a single line that is the sum of the average number of egress bytes over one-minute intervals. Select a refresh time in the upper right dropdown if you want the graph to be updated periodically. +The full list of predefined metrics is [here](https://github.com/netobserv/netobserv-operator/blob/main/docs/Metrics.md). When you include a metric, it stores it in Prometheus and is available as a Prometheus metric prefixed with "netobserv_". For example, if you add the metric *namespace_egress_bytes_total*, then go to **Observe > Metrics** and enter the PromQL `sum(rate(netobserv_namespace_egress_bytes_total[1m]))`. This should display a single line that is the sum of the average number of egress bytes over one-minute intervals. Select a refresh time in the upper right dropdown if you want the graph to be updated periodically. Availability zones and cluster ID will be covered in the traffic flow table section below. diff --git a/content/posts/2024-04-05-agent_metrics_perf.md b/content/posts/2024-04-05-agent_metrics_perf.md index ffff179..de8f87d 100644 --- a/content/posts/2024-04-05-agent_metrics_perf.md +++ b/content/posts/2024-04-05-agent_metrics_perf.md @@ -207,7 +207,7 @@ This had a big impact on CPU usage: - +457% CPU when compared to `cacheMaxFlows=10000` - +143% CPU when compared to `cacheMaxFlows=2000, cacheTimeout=1s` -To avoid this, it's best to keep `cacheMaxFlows` big enough to minimize the ring buffer ratio usage, in spite of the increased memory usage. Other mitigation options could be limiting the number of generated flows by other means, such as [configuring the agent](https://github.com/netobserv/network-observability-operator/blob/19bcb45d6899f12feb13f94a925a10a4f4c92106/docs/FlowCollector.md#flowcollectorspecagentebpf-1) to add filters on monitored interfaces or to increase the sampling value, if the resulting loss in observability is an acceptable trade-off for you. +To avoid this, it's best to keep `cacheMaxFlows` big enough to minimize the ring buffer ratio usage, in spite of the increased memory usage. Other mitigation options could be limiting the number of generated flows by other means, such as [configuring the agent](https://github.com/netobserv/netobserv-operator/blob/19bcb45d6899f12feb13f94a925a10a4f4c92106/docs/FlowCollector.md#flowcollectorspecagentebpf-1) to add filters on monitored interfaces or to increase the sampling value, if the resulting loss in observability is an acceptable trade-off for you. ## Conclusion diff --git a/content/posts/2024-07-25-cli.md b/content/posts/2024-07-25-cli.md index 1c59757..6540957 100644 --- a/content/posts/2024-07-25-cli.md +++ b/content/posts/2024-07-25-cli.md @@ -112,7 +112,7 @@ oc krew install netobserv ### From tar archive -Download the latest version either from [github releases](https://github.com/netobserv/network-observability-cli/releases) or [developers.redhat.com](https://developers.redhat.com/content-gateway/rest/mirror2/pub/openshift-v4/clients/netobserv/latest). +Download the latest version either from [github releases](https://github.com/netobserv/netobserv-cli/releases) or [developers.redhat.com](https://developers.redhat.com/content-gateway/rest/mirror2/pub/openshift-v4/clients/netobserv/latest). Then follow the instructions on [Installing and using CLI plugins](https://docs.openshift.com/container-platform/4.15/cli_reference/openshift_cli/extending-cli-plugins.html#cli-installing-plugins_cli-extend-plugins) from Openshift documentation. @@ -141,7 +141,7 @@ oc netobserv help ``` Netobserv allows you to capture flow and packets from your cluster. -Find more information at: https://github.com/netobserv/network-observability-cli/ +Find more information at: https://github.com/netobserv/netobserv-cli/ Syntax: netobserv [flows|packets|cleanup] [filters] @@ -172,7 +172,7 @@ options: ``` As you can see, the CLI offers two captures options for now: -- `flows` to get network flows containing [enriched informations](https://github.com/netobserv/network-observability-operator/blob/main/docs/flows-format.adoc#network-flows-format-reference) +- `flows` to get network flows containing [enriched informations](https://github.com/netobserv/netobserv-operator/blob/main/docs/flows-format.adoc#network-flows-format-reference) On top of this command, you can add extra features and filters. Example to capture `Round Trip Time` of `TCP` flows using port `80`: ``` diff --git a/content/posts/2024-10-23-whats_new_1_6.md b/content/posts/2024-10-23-whats_new_1_6.md index a5605ab..24a4101 100644 --- a/content/posts/2024-10-23-whats_new_1_6.md +++ b/content/posts/2024-10-23-whats_new_1_6.md @@ -92,7 +92,7 @@ To generate flows (or not generate flows) for very specific data, you can specif protocol: TCP ``` -Enter `oc edit flowcollector`. Again, look for the `ebpf` section and add the rest of the lines starting at `flowFilter`. The `cidr` specifies a network address and prefix. The example refers to any traffic, but for a specific network, use a value like `10.0.62.0/24`. The feature is limited to one filter and many of the attributes can only have one value. For more details, see the [flowFilter reference](https://github.com/netobserv/network-observability-operator/blob/main/docs/flowcollector-flows-netobserv-io-v1beta2.adoc#specagentebpfflowfilter). +Enter `oc edit flowcollector`. Again, look for the `ebpf` section and add the rest of the lines starting at `flowFilter`. The `cidr` specifies a network address and prefix. The example refers to any traffic, but for a specific network, use a value like `10.0.62.0/24`. The feature is limited to one filter and many of the attributes can only have one value. For more details, see the [flowFilter reference](https://github.com/netobserv/netobserv-operator/blob/main/docs/flowcollector-flows-netobserv-io-v1beta2.adoc#specagentebpfflowfilter). ### eBPF Agent metrics @@ -181,7 +181,7 @@ _
Figure 7: Not 'ip' filter
_ In my [Network Observability 1.5 blog](https://developers.redhat.com/articles/2024/03/20/whats-new-network-observability-15), I covered the development preview of the FlowMetrics API. While it's possible to take any [flow data labels](https://docs.openshift.com/container-platform/4.16/observability/network_observability/json-flows-format-reference.html) and turn it into a Prometheus metric, that web page was updated to indicate which fields can be safely used as labels to avoid high cardinality. -This feature is now GA, and includes more filtering options (see [reference](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowMetric.md)) and support for [dashboards in OpenShift](https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md#charts-openshift-only). That link also has many more examples of using custom metrics. +This feature is now GA, and includes more filtering options (see [reference](https://github.com/netobserv/netobserv-operator/blob/main/docs/FlowMetric.md)) and support for [dashboards in OpenShift](https://github.com/netobserv/netobserv-operator/blob/main/docs/Metrics.md#charts-openshift-only). That link also has many more examples of using custom metrics. ## Network Observability CLI diff --git a/content/posts/2025-02-11-cli_whats_new_1.8.md b/content/posts/2025-02-11-cli_whats_new_1.8.md index da4a552..dfd11a1 100644 --- a/content/posts/2025-02-11-cli_whats_new_1.8.md +++ b/content/posts/2025-02-11-cli_whats_new_1.8.md @@ -111,7 +111,7 @@ key: SrcK8S_Namespace value: openshift.* ![regexes]({page.image('cli-whats-new-1-8/regexes.png')}) -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. +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/netobserv-operator/blob/main/docs/flows-format.adoc) to see the possible fields. ## Unified Collector User Experience All filtering capabilities are now supported for **packets** capture and displays enriched data while collecting. This improvement was made possible by introducing the [flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline) component inside [eBPF agents](https://github.com/netobserv/netobserv-ebpf-agent), which parses packets and generates flows from them. diff --git a/content/posts/2025-02-13-perf-improvements/index.md b/content/posts/2025-02-13-perf-improvements/index.md index 0f4a998..ba660bc 100644 --- a/content/posts/2025-02-13-perf-improvements/index.md +++ b/content/posts/2025-02-13-perf-improvements/index.md @@ -157,7 +157,7 @@ The drawback of using per-CPU maps for network flows is that for the same flow, Today, we change all of that by refactoring our data structures. Our solution is to avoid writing the flow map from the enrichment hooks. Instead of that, we are introducing a new map, dedicated to enriched data. Map keys are going to be duplicated across those two maps, but it's a lesser evil. So now, we can change the main map to be a shared one across CPUs, with a spinlock. We still have some reassembling work to do in the user space though, to merge the main map with the enrichment map, but it is more straightforward than merging entire flows together. We also have a couple of ideas to further improve this process, more on that later. -Splitting data between a main map and an enrichment map has another benefit: when no enrichment is needed (e.g. when none of the [agent features](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecagentebpf-1) are enabled), no memory is allocated for them, resulting — again — in a more efficient memory usage. +Splitting data between a main map and an enrichment map has another benefit: when no enrichment is needed (e.g. when none of the [agent features](https://github.com/netobserv/netobserv-operator/blob/main/docs/FlowCollector.md#flowcollectorspecagentebpf-1) are enabled), no memory is allocated for them, resulting — again — in a more efficient memory usage. This is for a large part what triggered the memory improvement mentioned above: diff --git a/content/posts/2025-02-26-whats-new-1-8/index.md b/content/posts/2025-02-26-whats-new-1-8/index.md index eea705f..5d87513 100644 --- a/content/posts/2025-02-26-whats-new-1-8/index.md +++ b/content/posts/2025-02-26-whats-new-1-8/index.md @@ -315,4 +315,4 @@ This is another feature-rich release that works hand-in-hand with OVN-Kubernetes Network Observability continues to provide flexibility in deciding what you want to observe so that you can minimize the resources used. This is in addition to the internal optimizations that we've made in this release. -While many of the features are in Developer Preview, it gives you a chance to try these out and give us some feedback before it becomes generally available. You can write comments and contact us on the [discussion board](https://github.com/netobserv/network-observability-operator/discussions). +While many of the features are in Developer Preview, it gives you a chance to try these out and give us some feedback before it becomes generally available. You can write comments and contact us on the [discussion board](https://github.com/netobserv/netobserv-operator/discussions). diff --git a/content/posts/2025-07-17-whats-new-1-9/index.md b/content/posts/2025-07-17-whats-new-1-9/index.md index 42a72ec..8cd90fa 100644 --- a/content/posts/2025-07-17-whats-new-1-9/index.md +++ b/content/posts/2025-07-17-whats-new-1-9/index.md @@ -223,6 +223,6 @@ Figure 6: Wireshark - Packet capture file with comments ## Summary -This is another solid release from the Network Observability team. If you use IPsec, you can get insight into this type of traffic. A filter query was added in both flowlogs-pipeline and the Network Observability CLI. If you want to easily capture flows, metrics, and packets, Network Observability CLI is the tool for you! Write to us on the [discussion board](https://github.com/netobserv/network-observability-operator/discussions) if you have any feedback or suggestions for improvements. +This is another solid release from the Network Observability team. If you use IPsec, you can get insight into this type of traffic. A filter query was added in both flowlogs-pipeline and the Network Observability CLI. If you want to easily capture flows, metrics, and packets, Network Observability CLI is the tool for you! Write to us on the [discussion board](https://github.com/netobserv/netobserv-operator/discussions) if you have any feedback or suggestions for improvements. _Special thanks to Julien Pinsonneau, Joel Takvorian, Mehul Modi, and Mohamed S. Mahmoud for reviewing._ diff --git a/content/posts/2025-10-28-flow-matrix/index.md b/content/posts/2025-10-28-flow-matrix/index.md index 3e0dfcc..137cb86 100644 --- a/content/posts/2025-10-28-flow-matrix/index.md +++ b/content/posts/2025-10-28-flow-matrix/index.md @@ -42,7 +42,7 @@ Let's look for another approach. ### The FlowMetrics API -The [FlowMetrics API](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowMetric.md) is a very good fit here, because it allows you to shape the metrics that you want. You choose what to aggregate on, what to filter on, what to observe. What do we want here? For every connection: +The [FlowMetrics API](https://github.com/netobserv/netobserv-operator/blob/main/docs/FlowMetric.md) is a very good fit here, because it allows you to shape the metrics that you want. You choose what to aggregate on, what to filter on, what to observe. What do we want here? For every connection: - The source (client) workloads and namespaces - The destination (server) workloads, namespaces and ports @@ -116,7 +116,7 @@ Labels are what flows are going to be aggregated on. When several flows are reco This list of labels is roughly what we described above, plus the `SrcSubnetLabel` / `DstSubnetLabel` which will be explained below, and the `Flags` (TCP flags) which we need for flattening+filtering as explained below. -You can read more about all the available fields [here](https://github.com/netobserv/network-observability-operator/blob/main/docs/flows-format.adoc). +You can read more about all the available fields [here](https://github.com/netobserv/netobserv-operator/blob/main/docs/flows-format.adoc). ```yaml flatten: [Flags] diff --git a/content/posts/2025-10-28-whats-new-1-10/index.md b/content/posts/2025-10-28-whats-new-1-10/index.md index 537c109..f1f456e 100644 --- a/content/posts/2025-10-28-whats-new-1-10/index.md +++ b/content/posts/2025-10-28-whats-new-1-10/index.md @@ -102,7 +102,7 @@ spec: privileged: true ``` -Underneath the covers, it creates a PrometheusRule object. To see what that looks like, enter `oc get prometheusrules -n netobserv -o yaml`. However, if you want to modify a predefined alert, you must [edit FlowCollector as described here](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/network_observability/network-observability-alerts_nw-observe-network-traffic#network-observability-configuring-predefined-alerts_network-observability-alerts). If you get ambitious, you can also write your own custom alerts! See [Alerts in the NetObserv Operator](https://github.com/netobserv/network-observability-operator/blob/main/docs/Alerts.md) for more information on this feature. +Underneath the covers, it creates a PrometheusRule object. To see what that looks like, enter `oc get prometheusrules -n netobserv -o yaml`. However, if you want to modify a predefined alert, you must [edit FlowCollector as described here](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/network_observability/network-observability-alerts_nw-observe-network-traffic#network-observability-configuring-predefined-alerts_network-observability-alerts). If you get ambitious, you can also write your own custom alerts! See [Alerts in the NetObserv Operator](https://github.com/netobserv/netobserv-operator/blob/main/docs/Alerts.md) for more information on this feature. ## Technology Preview: Network Health Dashboard @@ -190,6 +190,6 @@ Figure 14: Network Observability CLI - Packets In Network Observability CLI, there were significant improvements in the user interface and ease of use. The UI was completely revised and supports the mouse. Columns in the flow table and selection of graphs to display for metrics are customizable. It is now able to display graphs and packet captures without resorting to external programs. -In Network Observability, it is easier to create a FlowCollector and FlowMetric instance. It is more secure with the use of network policies. The custom alerts and Network Health Dashboard, while still in Technology Preview, are signs of things to come. As we move beyond insights into analysis, give us feedback on this and other topics on the [discussion board](https://github.com/netobserv/network-observability-operator/discussions). +In Network Observability, it is easier to create a FlowCollector and FlowMetric instance. It is more secure with the use of network policies. The custom alerts and Network Health Dashboard, while still in Technology Preview, are signs of things to come. As we move beyond insights into analysis, give us feedback on this and other topics on the [discussion board](https://github.com/netobserv/netobserv-operator/discussions). _Special thanks to Joel Takvorian, Julien Pinsonneau, and Amogh Rameshappa Devapura for reviewing this article._ diff --git a/content/posts/2026-02-02-whats-new-1-11/index.md b/content/posts/2026-02-02-whats-new-1-11/index.md index 8f42ff1..f21f152 100644 --- a/content/posts/2026-02-02-whats-new-1-11/index.md +++ b/content/posts/2026-02-02-whats-new-1-11/index.md @@ -33,7 +33,7 @@ In the **Deployment model** field, there is a new **Service** option. It deploy ![FlowCollector Wizard - Service deployment model](flowcollector_wizard-service.png)
Figure 1. The "Deployment model" field provides a new "Service" option. -The Service model is sort of in between the two existing models, Direct and Kafka. The Direct model deploys as a DaemonSet, so it runs a flowlogs-pipeline pod on each node. The Kafka model is just like the Service model, except it supports Apache Kafka for better scalability. View the [architectural diagrams of each model](https://github.com/netobserv/network-observability-operator/blob/main/docs/Architecture.md#service-deployment-model) for more details. +The Service model is sort of in between the two existing models, Direct and Kafka. The Direct model deploys as a DaemonSet, so it runs a flowlogs-pipeline pod on each node. The Kafka model is just like the Service model, except it supports Apache Kafka for better scalability. View the [architectural diagrams of each model](https://github.com/netobserv/netobserv-operator/blob/main/docs/Architecture.md#service-deployment-model) for more details. The default setting is Service model with three flowlogs-pipeline pods. You may need more pods if your cluster has heavy traffic or uses a low sampling interval (that is, samples more data). For large clusters, it is still recommended to use the Kafka model. @@ -225,6 +225,6 @@ Speaking of icons, they've been refreshed and updated to better represent the Ku This release provides features that give you better control on how resources are used with the Service deployment model and the new FlowCollectorSlice CRD. There were improvements to the Network Health dashboard and support for recording rules. Usability enhancements were made in the UI filters, along with a zero-click Loki setup for demonstration purposes. Finally, the DNS name was added and the Kubernetes Gateway object is now recognized. -We want to make a bigger push to serve the community, so if there's something on your wishlist, go to the [discussion board](https://github.com/netobserv/network-observability-operator/discussions), and let us know what you have in mind! Until next time... +We want to make a bigger push to serve the community, so if there's something on your wishlist, go to the [discussion board](https://github.com/netobserv/netobserv-operator/discussions), and let us know what you have in mind! Until next time... _Special thanks to Julien Pinsonneau, Olivier Cazade, Amogh Rameshappa Devapura, Leandro Beretta, Joel Takvorian, and Mehul Modi for reviewing this article._ diff --git a/content/posts/2026-03-02-subnet-labels/index.md b/content/posts/2026-03-02-subnet-labels/index.md index a5e5fb8..8a44ed7 100644 --- a/content/posts/2026-03-02-subnet-labels/index.md +++ b/content/posts/2026-03-02-subnet-labels/index.md @@ -18,7 +18,7 @@ But again, it doesn't know with absolute certainty what IP should be considered ## What are subnet labels? -As per [the doc](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecprocessorsubnetlabels), subnet labels "allow to define custom labels on subnets and IPs or to enable automatic labelling of recognized subnets in OpenShift, which is used to identify cluster external traffic. When a subnet matches the source or destination IP of a flow, a corresponding field is added: `SrcSubnetLabel` or `DstSubnetLabel`." +As per [the doc](https://github.com/netobserv/netobserv-operator/blob/main/docs/FlowCollector.md#flowcollectorspecprocessorsubnetlabels), subnet labels "allow to define custom labels on subnets and IPs or to enable automatic labelling of recognized subnets in OpenShift, which is used to identify cluster external traffic. When a subnet matches the source or destination IP of a flow, a corresponding field is added: `SrcSubnetLabel` or `DstSubnetLabel`." In OpenShift, NetObserv checks the Cluster Network Operator configuration to know which CIDRs are configured for Pods, Services and Nodes, then it configures `flowlogs-pipeline` accordingly. You can verify that in the generated configmap: @@ -82,11 +82,11 @@ It gives you all the traffic to external workloads or services. You can also create `FlowMetrics` resources dedicated to outside traffic. Thankfully, we provide some examples that should work out of the box with the default subnet labels: ```bash -kubectl apply -n netobserv -f https://raw.githubusercontent.com/netobserv/network-observability-operator/refs/heads/main/config/samples/flowmetrics/cluster_external_egress_traffic.yaml -kubectl apply -n netobserv -f https://raw.githubusercontent.com/netobserv/network-observability-operator/refs/heads/main/config/samples/flowmetrics/cluster_external_ingress_traffic.yaml +kubectl apply -n netobserv -f https://raw.githubusercontent.com/netobserv/netobserv-operator/refs/heads/main/config/samples/flowmetrics/cluster_external_egress_traffic.yaml +kubectl apply -n netobserv -f https://raw.githubusercontent.com/netobserv/netobserv-operator/refs/heads/main/config/samples/flowmetrics/cluster_external_ingress_traffic.yaml ``` -(More examples available [here](https://github.com/netobserv/network-observability-operator/tree/main/config/samples/flowmetrics), including for external traffic latency) +(More examples available [here](https://github.com/netobserv/netobserv-operator/tree/main/config/samples/flowmetrics), including for external traffic latency) These metrics leverage the absence of Subnet Labels in order to track external traffic. They also consider Subnet Labels prefixed with `EXT:` as external traffic. If you look at their definition, you'll see these rules expressed as that: diff --git a/content/start.md b/content/start.md index 5c4be55..d9d8141 100644 --- a/content/start.md +++ b/content/start.md @@ -8,5 +8,5 @@ layout: :theme/page There are two independent starting points for using NetObserv: -- By [installing the operator](https://github.com/netobserv/network-observability-operator/blob/main/README.md), allowing 24/7 network flows monitoring. -- By [using the CLI](https://github.com/netobserv/network-observability-cli/blob/main/README.md), for on-demand monitoring and troubleshooting. +- By [installing the operator](https://github.com/netobserv/netobserv-operator/blob/main/README.md), allowing 24/7 network flows monitoring. +- By [using the CLI](https://github.com/netobserv/netobserv-cli/blob/main/README.md), for on-demand monitoring and troubleshooting. diff --git a/templates/layouts/roq-default/main.html b/templates/layouts/roq-default/main.html index c0bbb02..5cdcc9a 100644 --- a/templates/layouts/roq-default/main.html +++ b/templates/layouts/roq-default/main.html @@ -56,7 +56,7 @@

To support us, give us some stars:

- Star + Star

Powered by Roq

diff --git a/templates/layouts/roq-default/post.html b/templates/layouts/roq-default/post.html index 61203bc..0a16cda 100644 --- a/templates/layouts/roq-default/post.html +++ b/templates/layouts/roq-default/post.html @@ -43,7 +43,7 @@ {#article-end}