[receiver/netflow] Add the netflow receiver - PR 1

[dlopes7]

This adds the base implementation of config and factory for the netflow receiver, according to CONTRIBUTING.md.
Later another PR will be opened with the actual implementation of the receiver.

It was not clear to me if the CHANGELOG entry should be added on this PR, or the one that actually implements the receiver, I am choosing to add it to the second PR.

Link to tracking Issue: #32732

Testing: Added tests for the config, receiver and listener creation

Documentation: Added the first version of the README with sample yaml and a documentation of the different fields.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dlopes7 / name: David Lopes (8c7bd24, 306b267, e4b5115, 3b1019e, 5cea6ec, 97e1bec, 8c65324, 77270e6, c4e9bd2, b619e40, 0996c1c, be502c2, ca5128c, c5ee961, d6dae6e, 871f2ff, 062d07a, 5f03ff9, 9aa77b6, 3b42bc4, d446489, 3ae8ad1, 8de9251, f62e092, b9f74cf, 7e13976, cf4720b, f8d4c2c, 040136f, e1c03bf, 7561af8, 9680294, 56b1024, cd49448, 4428150, 20eee81, f3e45ed, 0ff2e6c, f56b4ae)
• ✅ login: evan-bradley / name: Evan Bradley (58b4baa, e6b99ac)

[evan-bradley]

Thanks @dlopes7.

Could you run make chlog-new and fill out a new_component changelog?

[evan-bradley]

Can I configure multiple netflow listeners, or is it one listener per scheme?

[dlopes7]

Yes, but now that you mention it I think it might make more sense to allow a single listener per netflow config

[i3149]

Consider supporting the auto-detect feature of goflow2 vs making users explicitly set what flow type they are using.

[crobert-1]

Just a couple nits, hopefully it's helpful 👍

[LucasHocker]

@dlopes7 are we awaiting further reviews or code changes from the reviews?

[dlopes7]

Based on the proposed format changes I am suggesting this format for the output:

type NetworkAddress struct {
	Address []byte `json:"address,omitempty"`
	Port    uint32 `json:"port,omitempty"`
}

type Flow struct {
	Type           string `json:"type,omitempty"`
	TimeReceived   uint64 `json:"time_received,omitempty"`
	Start          uint64 `json:"start,omitempty"`
	End            uint64 `json:"end,omitempty"`
	SequenceNum    uint32 `json:"sequence_num,omitempty"`
	SamplingRate   uint64 `json:"sampling_rate,omitempty"`
	SamplerAddress []byte `json:"sampler_address,omitempty"`
}

type Protocol struct {
	Name []byte `json:"name,omitempty"` // Layer 7
}

type NetworkIO struct {
	Bytes   uint64 `json:"bytes,omitempty"`
	Packets uint64 `json:"packets,omitempty"`
}

type OtelNetworkMessage struct {
	Source      NetworkAddress `json:"source,omitempty"`
	Destination NetworkAddress `json:"destination,omitempty"`
	Transport   string         `json:"transport,omitempty"` // Layer 4
	Type        string         `json:"type,omitempty"`      // Layer 3
	IO          NetworkIO      `json:"io,omitempty"`
	Flow        Flow           `json:"flow,omitempty"`
}

[evan-bradley]

@dlopes7 Can you rebase on main and add your GitHub handle to cmd/githubgen/allowlist.txt?

[dlopes7]

New format after changes following semantic conventions would be

{
    "destination": {
        "address": "192.168.0.1",
        "port": 22
    },
    "flow": {
        "end": 1731073104662487000,
        "sampler_address": "192.168.0.2",
        "sequence_num": 49,
        "start": 1731073077662487000,
        "time_received": 1731073138662487000,
        "type": "NETFLOW_V5"
    },
    "io": {
        "bytes": 529,
        "packets": 378
    },
    "source": {
        "address": "192.168.0.3",
        "port": 40
    },
    "transport": "TCP",
    "type": "IPv4"
}

[evan-bradley]

@dlopes7 It looks like there are some conflicts with main, can you pull in the latest from main into your branch and resolve the conflicts?

[evan-bradley]

Thanks @dlopes7. To reduce churn on common files (issue templates, codeowners, etc.) I'm going to merge this and we can address open conversations in the follow-up PR.