-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[receiver/netflow] Add the netflow receiver - PR 1 #34164
base: main
Are you sure you want to change the base?
Conversation
According to CONTRIBUTING.md, adding the scaffolding of the netflow receiver for the first PR
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @dlopes7.
Could you run make chlog-new
and fill out a new_component
changelog?
receiver/netflowreceiver/README.md
Outdated
receivers: | ||
netflow: | ||
listeners: | ||
- scheme: netflow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I configure multiple netflow listeners, or is it one listener per scheme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but now that you mention it I think it might make more sense to allow a single listener per netflow config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider supporting the auto-detect feature of goflow2 vs making users explicitly set what flow type they are using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple nits, hopefully it's helpful 👍
Co-authored-by: Curtis Robert <[email protected]>
Co-authored-by: Evan Bradley <[email protected]>
Co-authored-by: Evan Bradley <[email protected]>
Co-authored-by: Curtis Robert <[email protected]>
* Improve readme, showing default values * Allow a single listener per config * Remove the contrib distribution from the metadata * Add the changelog entry
const ( | ||
defaultSockets = 1 | ||
defaultWorkers = 2 | ||
defaultQueueSize = 1_000_000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the queue size here is # of UDP Packets, a UDP packet can be up to 9KB which would be 9GB of memory usage with a full queue.
Perhaps the default queue should be smaller?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's a good default? Should we make this 1_000
so it is only 9MB?
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
I am back to this this week and reviewing the suggestions |
Co-authored-by: Evan Bradley <[email protected]>
@dlopes7 are we awaiting further reviews or code changes from the reviews? |
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"`
} |
@dlopes7 Can you rebase on main and add your GitHub handle to |
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"
} |
@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? |
…tor-contrib into netflow-receiver
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.