DOC-1684 update config client connections #1364
Conversation
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThe PR updates documentation in modules/manage/pages/cluster-maintenance/configure-availability.adoc. It revises wording for configuring kafka_connections_max_per_ip, adds a cross-reference to config-cluster.adoc, inserts notes about multi-IP attacks and using kafka_connections_max_overrides, and expands the workflow with explicit monitoring steps. New monitoring guidance includes setting up monitoring and checking redpanda_rpc_active_connections, with a code snippet and Grafana example. The Limitations section remains functionally the same, with added context aligning to the new notes. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
modules/manage/pages/cluster-maintenance/configure-availability.adoc (2)
38-39: Add link text and verify xref target.Provide descriptive link text and confirm the xref path resolves at build time.
Apply:
-See also: xref:manage:cluster-maintenance/config-cluster.adoc[]. +See also: xref:manage:cluster-maintenance/config-cluster.adoc[Cluster configuration].To verify the reference resolves, run the docs build/link-check pipeline or search the repo for the target file and anchors. If helpful, I can supply a script to locate the target and check for broken xrefs.
56-56: Avoid brittle “step 3” reference.Referencing numbered steps can drift with edits. Rephrase to be self-contained.
Apply:
-. Set the `kafka_connections_max_per_ip` value based on your analysis. Use the upper bound of normal connections from step 3, or use a lower value if you know how many connections per client IP are being opened. +. Set the `kafka_connections_max_per_ip` value based on your analysis. Use the upper bound of the normal connection range observed above, or a lower value if you know how many connections each client IP opens.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
modules/manage/pages/cluster-maintenance/configure-availability.adoc(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules - redpanda-docs-preview
- GitHub Check: Header rules - redpanda-docs-preview
- GitHub Check: Pages changed - redpanda-docs-preview
🔇 Additional comments (2)
modules/manage/pages/cluster-maintenance/configure-availability.adoc (2)
34-34: LGTM on intent and placement.Clear directive and correctly names the property.
60-60: Clarify overrides semantics; “exclude” can misleadRedpanda docs are inconsistent: kafka_connections_max_overrides is shown with ip:limit examples but described as an exemption list, and there’s no documented '-1' sentinel for unlimited. Update the note to avoid implying a pure “exclude” behavior or claiming '-1' support.
Suggested wording: NOTE: When facing attacks from multiple IP addresses, kafka_connections_max_per_ip alone may be insufficient. If offending IPs outnumber legitimate client IPs, you may need a low global per‑IP limit that risks impacting legitimate clients. Use kafka_connections_max_overrides to provide per‑IP overrides or to exempt known legitimate client IPs from the global limit — verify whether Redpanda accepts host:limit mappings (like Kafka) or only host entries, and whether an explicit '-1' for unlimited is supported before documenting specific syntax.
|
|
||
| . Continue monitoring the connection metrics after applying the limit to ensure that legitimate clients are not affected and that the problematic client is properly controlled. | ||
|
|
||
| NOTE: When facing attacks from multiple IP addresses, `kafka_connections_max_per_ip` alone may be insufficient. If offending IPs outnumber legitimate client IPs, you'll need to set `kafka_connections_max_per_ip` so low that it affects legitimate clients. If this is the case, try using `kafka_connections_max_overrides` to exclude known legitimate client IPs from the connection limit. |
There was a problem hiding this comment.
I wouldn't say "attacks" since it is not always "attacks" and more commonly for our case just accidents
kbatuigas
left a comment
kbatuigas
left a comment
There was a problem hiding this comment.
One clarifying question, but looks good otherwise. Please let me know if another review is needed!
|
|
||
| . Continue monitoring the connection metrics after applying the limit to ensure that legitimate clients are not affected and that the problematic client is properly controlled. | ||
|
|
||
| NOTE: If you find a high load of unexpected connections from multiple IP addresses, `kafka_connections_max_per_ip` alone may be insufficient. If offending IPs outnumber legitimate client IPs, you may need to set `kafka_connections_max_per_ip` so low that it affects legitimate clients. If this is the case, use `kafka_connections_max_overrides` to exempt known legitimate client IPs from the connection limit. |
There was a problem hiding this comment.
| NOTE: If you find a high load of unexpected connections from multiple IP addresses, `kafka_connections_max_per_ip` alone may be insufficient. If offending IPs outnumber legitimate client IPs, you may need to set `kafka_connections_max_per_ip` so low that it affects legitimate clients. If this is the case, use `kafka_connections_max_overrides` to exempt known legitimate client IPs from the connection limit. | |
| NOTE: If you find a high load of unexpected connections from multiple IP addresses, `kafka_connections_max_per_ip` alone may be insufficient. If offending IPs outnumber legitimate client IPs, you may need to set `kafka_connections_max_per_ip` so low that it affects legitimate clients. In this case, also use `kafka_connections_max_overrides` to exempt known legitimate client IPs from the connection limit. |
Do I understand correctly that "affects legitimate clients" means those clients are completely blocked from connecting to the broker?
There was a problem hiding this comment.
yes, they could be
c4milo
left a comment
c4milo
left a comment
There was a problem hiding this comment.
It looks great @micheleRP, thank you!
micheleRP
deleted the
DOC-1684-update-config-client-connections-with-new-recommendations
branch
Description
This pull request updates the documentation for configuring connection limits by client IP in Redpanda, clarifying how the
kafka_connections_max_per_ipproperty works and adding guidance for handling attacks from multiple IPs.kafka_connections_max_per_ipmay not be sufficient, and suggested usingkafka_connections_max_overridesto exempt known legitimate client IPs from the limit.Resolves https://redpandadata.atlassian.net/browse/DOC-1684
Review deadline:
Page previews
Configure Client Connections
Checks