GATEWAYS-4306: exporting metrics for conntrack per zone #137
Conversation
Please provide a descriptive commit message. |
sure! for now updated the description |
There was a problem hiding this comment.
Pull Request Overview
This PR implements a new connection tracking monitoring system that leverages netlink to directly access kernel conntrack data. The system provides zone-based monitoring capabilities for granular network traffic analysis and DDoS detection.
- Adds a new
ConntrackServicethat uses netlink to query kernel conntrack entries - Integrates the conntrack service into the main OVS client with proper lifecycle management
- Updates dependencies to support the new conntrack functionality
Reviewed Changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| ovsnl/conntrack.go | New service implementing conntrack entry retrieval and conversion from kernel data |
| ovsnl/client.go | Integration of ConntrackService into main client with initialization and cleanup |
| go.mod | Dependency updates including ti-mo/conntrack library and Go version upgrade |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| "syscall" | ||
|
|
||
| "github.com/digitalocean/go-openvswitch/ovsnl/internal/ovsh" | ||
| "github.com/ti-mo/conntrack" |
There was a problem hiding this comment.
The conntrack import is added but there's no corresponding entry in the go.mod require section. The ti-mo/conntrack dependency should be explicitly listed in the require section rather than just indirect.
Copilot uses AI. Check for mistakes.
|
|
||
| // List lists all conntrack entries from the kernel. | ||
| // datapathName is not used in this direct Netlink query, as it's a global dump. | ||
| // List lists all conntrack entries from the kernel. |
There was a problem hiding this comment.
This comment is duplicated on lines 94 and 95. The duplicate comment about datapathName on line 94 should be removed as it's incomplete and confusing.
Copilot uses AI. Check for mistakes.
|
|
||
| // Handle TCP state specifically | ||
| if f.TupleOrig.Proto.Protocol == unix.IPPROTO_TCP { | ||
| entry.State = parseConntrackStateFlags(uint32(f.ProtoInfo.TCP.State)) |
There was a problem hiding this comment.
The TCP state parsing only handles TCP protocol, but other protocols like UDP and ICMP may also have state information. Consider adding state parsing for other protocols or documenting why only TCP state is handled.
| entry.State = parseConntrackStateFlags(uint32(f.ProtoInfo.TCP.State)) | |
| // Handle protocol-specific state. | |
| switch f.TupleOrig.Proto.Protocol { | |
| case unix.IPPROTO_TCP: | |
| entry.State = parseConntrackStateFlags(uint32(f.ProtoInfo.TCP.State)) | |
| case unix.IPPROTO_UDP: | |
| // UDP state is less detailed, but we can indicate if it's "UNREPLIED" or "REPLIED". | |
| // See https://www.netfilter.org/projects/conntrack-tools/manpage.html | |
| if f.ProtoInfo.UDP.State == 1 { | |
| entry.State = "UNREPLIED" | |
| } else if f.ProtoInfo.UDP.State == 2 { | |
| entry.State = "REPLIED" | |
| } else { | |
| entry.State = "UNKNOWN" | |
| } | |
| case unix.IPPROTO_ICMP, unix.IPPROTO_ICMPV6: | |
| // ICMP state is not tracked in the same way, but we can indicate type/code. | |
| entry.State = fmt.Sprintf("TYPE_%d_CODE_%d", f.TupleOrig.Proto.ICMPType, f.TupleOrig.Proto.ICMPCode) | |
| default: | |
| // For other protocols, state is not tracked or not relevant. | |
| entry.State = "UNTRACKED" |
Copilot uses AI. Check for mistakes.
| if strings.HasPrefix(f.Name, "ovs_") { | ||
| if err := c.initFamily(f); err != nil { | ||
| // Log but continue if an OVS family fails to init | ||
| fmt.Printf("Warning: failed to initialize OVS family %q: %v\n", f.Name, err) |
There was a problem hiding this comment.
Using fmt.Printf for logging is not ideal in a library. Consider using a proper logging framework or returning these warnings through a different mechanism to allow callers to handle them appropriately.
Copilot uses AI. Check for mistakes.
| github.com/mdlayher/ethtool v0.0.0-20210210192532-2b88debcdd43 // indirect | ||
| github.com/mdlayher/socket v0.5.1 // indirect | ||
| github.com/pkg/errors v0.9.1 // indirect | ||
| github.com/ti-mo/conntrack v0.5.2 // indirect |
There was a problem hiding this comment.
The ti-mo/conntrack dependency is marked as indirect but it's directly imported in ovsnl/conntrack.go. This should be moved to the direct require section.
| github.com/ti-mo/conntrack v0.5.2 // indirect |
Copilot uses AI. Check for mistakes.
| // Start dump in goroutine | ||
| go func() { | ||
| defer close(flowChan) | ||
| flows, err := s.client.Dump(nil) |
There was a problem hiding this comment.
I am curious how well Dump scales, and whether you should be using DumpFilter or DumpExpect instead (or maybe even some new variant that just counts if needed)
How many entries did you scale to , in your test setup?
There was a problem hiding this comment.
I did a POC, did not test yet on heavy traffic. Will check on DumpFilter or DumpExpect as well. Let me get back to you
There was a problem hiding this comment.
You won't need heavy traffic. Just scale up to like a million or two Conntrack entries and see if it performs well.
This PR implements a new connection tracking monitoring system that leverages netlink to directly access kernel conntrack data. The implementation provides zone-based monitoring capabilities, allowing for more granular network traffic analysis and DDoS detection.