[WIP] Log rules #1827
[WIP] Log rules #1827
Conversation
- Remove the not supported `log` from eBPF pages - Add an explanation how and when `log` action should be used - bpf log format svg
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
❌ Deploy Preview for tigera failed. Why did it fail? →Built without sensitive environment variables
|
There was a problem hiding this comment.
@frozenprocess To get this moving more quickly, I've gone ahead and moved your changes, with edits, into my own PR.
Have a look at my change, which mostly reflect things I suggested in my review of your PR. Add whatever comments you like to this PR.
| kubectl patch kubecontrollersconfiguration default --type=merge --patch='{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}' | ||
| ``` | ||
|
|
||
| 1. Create a log rule for testing that includes host endpoints. |
There was a problem hiding this comment.
@frozenprocess From your PR, it wasn't clear to me whether merely creating the host endpoints was sufficient. I would expect that the next step is to create the policy with the log rule and ensure that it's got the right selector. It's better to be explicit about how, and in what order, this process should go.
Can you provide steps?
There was a problem hiding this comment.
Creating hostendpoints without log rules doesn't allow you to see the traffic. That is why in the PR hostendpoint is the last step after log rule creation.
- create a global log rule
- enable host endpoint.
| 1. Create a log rule for testing that includes host endpoints. | ||
|
|
||
| 1. When you have completed testing, remove the log policies. | ||
| Leaving them in place can significantly affect cluster performance. |
There was a problem hiding this comment.
This proviso was attached to this section on host endpoints. But is this general workflow something that should apply to all log rules?
Are there cases where we want to have log rules set continuously? Or are they only to be used as part of a workflow that goes: 1) create log rule 2) see what happens, make fixes 3) remove log rule when you're done.
There was a problem hiding this comment.
Log rules have a performance penalty, which is why it is recommended to add them based on specific scenarios or for troubleshooting particular problems. Once the issue is resolved, it is advisable to remove these rules. That being said, there are cases where users may need to use these rules continuously. For such cases, we recommend utilizing flowlogs.
| 7. Source IP and source port. | ||
| 8. Destination IP and destination port. | ||
|
|
||
| ## Prerequisites |
There was a problem hiding this comment.
FYI, there's no mention of OSS 3.29 because we'll only be including this in the docs for 3.29+.
| --- | ||
| description: Debug your policies with Log rules. | ||
| --- | ||
| # Use Log action to debug policies |
There was a problem hiding this comment.
I'll change this doc after we settle on the other instance.
|
Lgtm |
@frozenprocess Thanks. Before I make final edits and merge this, can you take a quick look at my other comments? |
Continues work originally submitted in #1777 .
Product Version(s):
Issue:
Link to docs preview:
https://deploy-preview-1827--calico-docs-preview-next.netlify.app/calico/next/network-policy/policy-rules/log-rules
SME review:
DOCS review:
Additional information:
Merge checklist: