Documentation ¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type FlowFetcher ¶ added in v0.2.1
type FlowFetcher struct {
// contains filtered or unexported fields
}
FlowFetcher reads and forwards the Flows from the Traffic Control hooks in the eBPF kernel space. It provides access both to flows that are aggregated in the kernel space (via PerfCPU hashmap) and to flows that are forwarded by the kernel via ringbuffer because could not be aggregated in the map
func NewFlowFetcher ¶ added in v0.2.1
func NewFlowFetcher( traceMessages bool, sampling, cacheMaxSize int, ingress, egress bool, ) (*FlowFetcher, error)
func (*FlowFetcher) Close ¶ added in v0.2.1
func (m *FlowFetcher) Close() error
Close the eBPF fetcher from the system. We don't need an "Close(iface)" method because the filters and qdiscs are automatically removed when the interface is down
func (*FlowFetcher) LookupAndDeleteMap ¶ added in v0.2.1
func (m *FlowFetcher) LookupAndDeleteMap() map[flow.RecordKey][]flow.RecordMetrics
LookupAndDeleteMap reads all the entries from the eBPF map and removes them from it. It returns a map where the key For synchronization purposes, we get/delete a whole snapshot of the flows map. This way we avoid missing packets that could be updated on the ebpf side while we process/aggregate them here Changing this method invocation by BatchLookupAndDelete could improve performance TODO: detect whether BatchLookupAndDelete is supported (Kernel>=5.6) and use it selectively Supported Lookup/Delete operations by kernel: https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md Race conditions here causes that some flows are lost in high-load scenarios
func (*FlowFetcher) ReadRingBuf ¶ added in v0.2.1
func (m *FlowFetcher) ReadRingBuf() (ringbuf.Record, error)