-
Notifications
You must be signed in to change notification settings - Fork 97
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
[EV-4885] Improve flow log aggregation level doc #1488
Conversation
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
2780d80
to
40440f2
Compare
40440f2
to
9c13bd4
Compare
|-----------|-------------------------------------|-------------------------------------------------------------------| | ||
| 0 | | No aggregation | | ||
| 1 | AnyProcessInSameSourcePod | Identity fields below source pod level are masked out. It means that if multiple processes or containers, within the same source pod, perform the same operation, the events are aggregated. | | ||
| 2 | AnyProcessInSameSourcePodPrefix | Identity fields below source pod-prefix level are masked out. It means that if multiple processes or containers, within pods with the same prefix, perform the same operation, the events are aggregated. | |
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.
| 2 | AnyProcessInSameSourcePodPrefix | Identity fields below source pod-prefix level are masked out. It means that if multiple processes or containers, within pods with the same prefix, perform the same operation, the events are aggregated. | | |
| 2 | AnyProcessInSameSourcePodPrefix | In addition to the above, source pod names are aggregated based on their shared prefixes. This means that flows, to the same destination, from pods within the same Deployment/ReplicaSet are aggregated together. | |
"pod-prefix" is an implementation detail; I think it;d help to link back to user concepts such as ReplicaSets/Deployments
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 for the suggestion, I've added it and adapted the level 3 description accordingly.
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.
Looks a lot clearer overall. Do we document the detailed flow log JSON somewhere else? Don't want to lose that completely, but I agree that it's confusing in this document so +1 for removing it here.
What about adding an example flow log section to the end of the flow logs page? I've added a |
46196b6
to
9e251c0
Compare
f8435e1
to
c95fbfc
Compare
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.
lgtm, much improved compared with the old version.
c95fbfc
to
58110f2
Compare
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.
Nice improvement. I've left a few more detailed comments, but happy to leave them to your judgement.
| 0 | | No aggregation | | ||
| 1 | AnyProcessInSameSourcePod | Identity fields below source pod level are masked out. It means that if multiple processes or containers, within the same source pod, perform the same operation, the events are aggregated. | | ||
| 2 | AnyProcessInSameSourcePodPrefix | In addition to the above, source pod names are aggregated based on their shared prefixes. This means that flows, to the same destination, from pods within the same Deployment/ReplicaSet are aggregated together. | | ||
| 3 | AnyProcessInSamePodPrefix | This level of aggregation builds on the previous two levels and also groups destination pod names based on their shared prefixes. | |
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.
This feels like maybe going too far in copying the RS doc. But I see that it does broadly work, and in particular that AnyProcessInSameSourcePod
does correspond to source port masking. That said:
-
Would something like
AnyConnectionFromSameSourcePod
be better in this context thanAnyProcessInSameSourcePod
, to put the focus more on network connections than on processes? (Although it is correct that connections have to made by processes...) Then Level 3 could beAnyConnectionBetweenSamePodPrefixes
. (Although also need to incorporate Shaun's point here about not saying "pod prefix" if possible.) -
Similarly, perhaps "make the same connection to a destination" instead of "perform the same operation"?
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 see you've addressed the point about "pod prefix" below.)
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'm finding it hard replacing pod prefix
without creating a very long name. I feel the items have to be read along with their description.
I could replace:
AnyConnectionFromSamePodPrefix
with AnyConnectionFromSamePodController
AnyConnectionBetweenSamePodPrefixes
with AnyConnectionBetweenSamePodControllers
but I feel we're just replacing the word, without applying the intended change. WDYT?
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.
IMO, the words you already added to explain pod prefix suffice. (I.e. the "In Kubernetes ..." paragraph.) Given that you've done that, I would say it's OK to keep using PodPrefix
here.
type minimizes the flow logs generated for traffic coming from different containers within the same pod and going to the same destination endpoint | ||
and port. The two flows originating from `client-a` without aggregation are combined into one. | ||
|
||
In Kubernetes, ReplicaSets and StatefulSets can automatically create names for pods. For example, the pods `nginx-1` and `nginx-2` are created by the |
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 think it's worth mentioning Deployments and DaemonSets here too. In particular I would guess that Deployment is the most common usage pattern.
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.
(If you need an umbrella term for all of those, I believe it is "pod controller".)
``` | ||
|
||
The log shows an incoming connection reported by the "Destination" node, allowed by a policy on port 80. The flows in the log are grouped using a | ||
5-minute aggregation interval, calculated as **`end_time`** - **`start_time`**. During this interval, one flow (**`"num_flow": 1`**) was recorded. At |
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.
"calculated" feels wrong here. I think better to say that start_time and end_time describe the aggregation period.
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.
Looks like a nice improvement, thanks!
@dimitri-nicolo I've been keeping an eye on this and waiting for the technical reviews. Let me know when you're ready for me to review. |
@ctauchen This is now ready for your review, thanks! |
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.
@dimitri-nicolo Thanks, a few formatting and typo-level fixes for you. Othwerwise LGTM.
@@ -101,3 +101,66 @@ Where, | |||
action for the tier. In this case, the `<policy name>` is selected arbitrarily from the set of policies within | |||
the tier that apply to the endpoint. | |||
* `-2` means "unknown". The rule index was not recorded. | |||
|
|||
### Flow log example, with **no aggregation** |
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.
### Flow log example, with **no aggregation** | |
### Flow log example, with `no aggregation` |
|
||
### Flow log example, with **no aggregation** | ||
|
||
A flow log with aggregation level 0, **`no aggregation`**, might look like: |
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.
A flow log with aggregation level 0, **`no aggregation`**, might look like: | |
A flow log with aggregation level 0, `no aggregation`, might look like: |
No need for bold when we're already using a code font. Should remove throughout.
} | ||
``` | ||
|
||
The log shows an incoming connection reported by the "Destination" node, allowed by a policy on port 80. The **`start_time`** and **`end_time`** |
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.
The log shows an incoming connection reported by the "Destination" node, allowed by a policy on port 80. The **`start_time`** and **`end_time`** | |
The log shows an incoming connection reported by the destination node, allowed by a policy on port 80. The **`start_time`** and **`end_time`** |
The log shows an incoming connection reported by the "Destination" node, allowed by a policy on port 80. The **`start_time`** and **`end_time`** | ||
describe the aggregation period (5 min.) During this interval, one flow (**`"num_flow": 1`**) was recorded. At higher aggregation levels, flows from | ||
endpoints performing the same operation and originating from the same Deployment/ReplicaSet are grouped into a single log. In this example, the | ||
common source endpoints are prefixed with **`access-6b687c8dcb-`**. Parameters like **`source_ip`** may be dropped and set to **`null`** depending on |
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.
common source endpoints are prefixed with **`access-6b687c8dcb-`**. Parameters like **`source_ip`** may be dropped and set to **`null`** depending on | |
common source endpoints that are prefixed with **`access-6b687c8dcb-`**. Parameters like **`source_ip`** may be dropped and set to **`null`**, depending on |
|
||
Finally, with `AnyConnectionBetweenSamePodPrefixes` we combine source and destination pods that are part of the same pod controller. With level 3, the flow logs | ||
are aggregated by the destination port and protocol, as long as they originate from pods with the same pod-prefix and destined for pods of the same | ||
pod-prefix. All logs previously distinct, are aggregated into a single flow log (see the last row). |
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.
pod-prefix. All logs previously distinct, are aggregated into a single flow log (see the last row). | |
pod-prefix. Previously distinct logs are aggregated into a single flow log (see the last row). |
``` | ||
|
||
### Change default aggregation level | ||
|
||
Before [changing the default aggregation level](../../../reference/resources/felixconfig.mdx#aggregationkind), note the following: | ||
|
||
- Although any change in aggregation level affects flow log volume, lowering the aggregation number (especially to `0` for no aggregation) will cause significant impacts to log storage. If you allow more flow logs, ensure that you provision more log storage. | ||
- Verify that the parameters that you want to see in your aggregation level, are not already [filtered](filtering.mdx) | ||
- Verify that the parameters that you want to see in your aggregation level, are not already [filtered](filtering.mdx). |
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.
- Verify that the parameters that you want to see in your aggregation level, are not already [filtered](filtering.mdx). | |
- Verify that the parameters that you want to see in your aggregation level are not already [filtered](filtering.mdx). |
73497a6
to
45de23a
Compare
@ctauchen thanks for the comments, I've address the changes in the latest commit |
Product Version(s):
Enterprise 3.19.2, Cloud and version 3.19.1
Issue:
Link to docs preview:
SME review:
DOCS review:
Additional information:
Merge checklist: