Skip to content

Conversation

@jotak
Copy link
Member

@jotak jotak commented Feb 10, 2026

No description provided.

- **Template Version:** v1.0
- **Description:** <!-- Short project description -->

NetObserv is a set of components used to observe network traffic by generating NetFlows from eBPF agents with zero-instrumentation, enriching those flows using a Kubernetes-aware configurable pipeline, exporting them in various ways (logs, metrics, Kafka, IPFIX...), and finally providing a comprehensive visualization tool for making sense of that data, a network health dashboard, and a CLI. Those components are mainly designed to be deployed in Kubernetes via an integrated Operator, although they can also be used as standalones.
Copy link
Contributor

@stleerh stleerh Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On export, separate the data (logs, metrics) from the protocol (Kafka, IPFIX, OpenTelemetry).

Correction:
"for making sense of that data, such as a network health dashboard and a CLI."


### Background

Kubernetes can be complex, and so does Kubernetes networking. Especially as it can differ from a CNI to another. Cluster admins often find important to have a good observability over the network, that clearly maps with Kubernetes resources (Services, Pods, Nodes...). This is what NetObserv aims to offer. Additionally, it aims at identifying network issues, and raising alerts. While it is not designed as a security tool, the data that it provides can be leveraged, for instance, to detect network threat patterns.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest:
Kubernetes is complex, and so is Kubernetes networking, especially since it can differ from one CNI to another. Cluster admins often find it important to have good observability over the network that clearly maps with Kubernetes resources (e.g. services, pods, nodes).

Remove comma after "issues".


The operator reads the main configuration (FlowCollector CRD) to determine how to deploy and configure the related components.

The eBPF agents are deployed, one per node (DaemonSet), with elevated privleges, load their eBPF payload in the host kernel, and start collecting network flows. Those flows are sent to flowlogs-pipeline, which correlate them with Kubernetes resources, and performs various transformations, before sending them to a log store (Loki) and/or expose them as Prometheus metrics. Other exporting options exist. Loki, Prometheus and any receiving system are not part of the NetObserv payload, they must be installed and managed separately.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"privileges"

New sentence:
They must be installed and managed separately.


## Project Compliance

N/A: the project has not been evaluated against compliance standards as of today.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add FIPs here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants