-
Spike
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
Future Sustainability
-
False
-
-
False
-
None
-
None
-
NetObserv - Sprint 278
Start a google doc (or directly PoC) to design a new Conversation Tracking mode, that is not using the existing FLP-based mode (we want it to work out of regular flow logs).
Basically, this should be only a UI/presentation work, no change in query, just reorganising how data is displayed.
Quick thoughts, to be refined:
- A new option is added in Traffic flows display options to group flows by conversation
- The "conversation key" can be customized: e.g. with or without source port; with or without both ports: bidirectional or unidirectional
- Data grouping results in something like that, for each row:
- Start time, end time (mix/max of all flow times within the conversation)
- Source (IP+name+namespace etc.)
- Dest (IP+name+namespace etc.)
- Some aggregated data (e.g. Total bytes/packets/drops/etc. ; mean/max latency etc.; first N network events...)
- Details: the list of raw flows within the conversation should still be somehow accessible
- When possible, try to leverage TCP flags to know who initiated the connection (SYN) and find a way to display that information (we may be tempted to rename columns "source/dest" to "client/server" or "initiator/?" however the problem is we're not always be able to know who is the initiator) - maybe what we can do, is when a SYN flag is found, promote that source as the source of the whole conversation; given that choosing the conversation source is arbitrary otherwise, in bidirectional traffic
Since this work might be quite big, potentially spanning over several releases, recommendation is to not try doing all at once, but split into iterable tasks that can be released independently - E.g: start first with just bidirectional traffic and 5-tuples keys; add the other extra options later. Also start with just a couple of aggregated data, not everything.
- relates to
-
NETOBSERV-2282 Improved conversation tracking
-
- New
-