add kafka bridge connect docs#24
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR adds two comprehensive how-to guides for Strimzi components: one covering Kafka Connect cluster creation, plugin management, connector lifecycle, and operational configuration; another explaining Kafka Bridge deployment, REST API usage, service exposure, and configuration options. ChangesStrimzi Component How-To Guides
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 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: 2
🧹 Nitpick comments (1)
docs/en/how_to/37-kafka-bridge.mdx (1)
336-343: 💤 Low valueMinor grammar suggestion: hyphenate compound adjective.
The phrase "Base64 encoded" should be hyphenated as "Base64-encoded" when used as a compound adjective before a noun.
📝 Suggested grammar fix
-| `application/vnd.kafka.binary.v2+json` | Producing or consuming Base64 encoded binary records. | +| `application/vnd.kafka.binary.v2+json` | Producing or consuming Base64-encoded binary records. |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/how_to/37-kafka-bridge.mdx` around lines 336 - 343, The phrase "Base64 encoded binary records" in the table row for the content type `application/vnd.kafka.binary.v2+json` should use a hyphenated compound adjective; update the text to "Base64-encoded binary records" wherever that description appears (specifically in the table entry for `application/vnd.kafka.binary.v2+json`) to correct the grammar.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/en/how_to/35-kafka-connect.mdx`:
- Line 375: Update the sentence mentioning metrics export so it no longer calls
it a "sidecar": change the line that currently reads "Metrics are exported
through a JMX Prometheus exporter sidecar." to explain that Strimzi's
spec.metricsConfig.type: jmxPrometheusExporter causes the Kafka Connect JVM to
load the Prometheus JMX Exporter as a -javaagent in the same JVM process (i.e.,
not a separate sidecar container), so that documentation reflects the correct
pod/container topology and scrape target behavior.
In `@docs/en/how_to/37-kafka-bridge.mdx`:
- Around line 324-332: Remove the entire "Create a Topic" section that shows
POST to /admin/topics (the Bridge does not expose an /admin/topics endpoint) and
update the content types table to delete the row or cell that claims the Bridge
supports "admin API requests such as topic creation"; instead keep only
producing/consuming behavior in examples and ensure no examples reference
/admin/topics or "admin API" in the content types table.
---
Nitpick comments:
In `@docs/en/how_to/37-kafka-bridge.mdx`:
- Around line 336-343: The phrase "Base64 encoded binary records" in the table
row for the content type `application/vnd.kafka.binary.v2+json` should use a
hyphenated compound adjective; update the text to "Base64-encoded binary
records" wherever that description appears (specifically in the table entry for
`application/vnd.kafka.binary.v2+json`) to correct the grammar.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cd8ab38a-a6bd-4901-9014-83d781537a5d
📒 Files selected for processing (2)
docs/en/how_to/35-kafka-connect.mdxdocs/en/how_to/37-kafka-bridge.mdx
|
|
||
| ## Configure Metrics | ||
|
|
||
| Enable Prometheus metrics collection using `spec.metricsConfig`. Metrics are exported through a JMX Prometheus exporter sidecar. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In the latest Strimzi documentation for KafkaConnect metricsConfig.type: jmxPrometheusExporter, are metrics exposed by a sidecar container or by the Kafka Connect container/JVM (for example via javaagent)?
💡 Result:
In the Strimzi Kafka Connect configuration, when metricsConfig.type is set to jmxPrometheusExporter, the metrics are exposed by the Kafka Connect container itself using a Java agent [1][2]. Strimzi configures the Kafka Connect JVM to load the Prometheus JMX Exporter as a -javaagent [1]. This agent runs within the same JVM as the Kafka Connect process, allowing it to access JMX metrics directly from the application [1][3]. This approach differs from a sidecar container pattern, as no separate container is required to scrape or export these metrics [3]. For example, the Strimzi operator automatically injects the necessary configuration into the Kafka Connect pod's environment variables (typically via KAFKA_OPTS), which includes the path to the JMX Prometheus Exporter JAR and the associated configuration file [1].
Citations:
- 1: Kafka Connect metrics not working strimzi/strimzi-kafka-operator#7171
- 2: kafka connector crashing with metric-config.json format strimzi/strimzi-kafka-operator#5512
- 3: Explore options for metrics & monitoring strimzi/strimzi-kafka-operator#42
Remove "sidecar" from the metrics description—metrics are exposed by the Kafka Connect JVM via Java agent, not a sidecar container.
Line 375 incorrectly states metrics are exported "through a JMX Prometheus exporter sidecar." Strimzi's metricsConfig.type: jmxPrometheusExporter configures the Kafka Connect JVM to load the Prometheus JMX Exporter as a -javaagent running within the same JVM process, not via a separate sidecar container. This distinction is important for troubleshooting pod/container topology and scrape targets.
Suggested fix
-Enable Prometheus metrics collection using `spec.metricsConfig`. Metrics are exported through a JMX Prometheus exporter sidecar.
+Enable Prometheus metrics collection using `spec.metricsConfig`. Metrics are exposed by Kafka Connect using JMX Prometheus exporter configuration.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Enable Prometheus metrics collection using `spec.metricsConfig`. Metrics are exported through a JMX Prometheus exporter sidecar. | |
| Enable Prometheus metrics collection using `spec.metricsConfig`. Metrics are exposed by Kafka Connect using JMX Prometheus exporter configuration. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/en/how_to/35-kafka-connect.mdx` at line 375, Update the sentence
mentioning metrics export so it no longer calls it a "sidecar": change the line
that currently reads "Metrics are exported through a JMX Prometheus exporter
sidecar." to explain that Strimzi's spec.metricsConfig.type:
jmxPrometheusExporter causes the Kafka Connect JVM to load the Prometheus JMX
Exporter as a -javaagent in the same JVM process (i.e., not a separate sidecar
container), so that documentation reflects the correct pod/container topology
and scrape target behavior.
| ```bash | ||
| curl -X POST http://localhost:8080/admin/topics \ | ||
| -H 'content-type: application/vnd.kafka.json.v2+json' \ | ||
| -d '{ | ||
| "topic_name": "my-new-topic", | ||
| "partitions_count": 3, | ||
| "replication_factor": 3 | ||
| }' | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the correct content-type header for Kafka Bridge admin API topic creation requests?
💡 Result:
The Strimzi Kafka Bridge API does not provide a dedicated endpoint for creating Kafka topics; topic creation is typically handled by Kafka administrative tools (such as kafka-topics.sh) rather than the Bridge API [1]. The Kafka Bridge API is designed for producer and consumer operations [2][1]. When using the producer endpoints (e.g., POST /topics/{topicname}), you must provide a Content-Type header that specifies the embedded data format of the messages being sent [3][4][5]. The required header depends on the format of the data in the request body: 1. For JSON-formatted messages: Content-Type: application/vnd.kafka.json.v2+json [3][4][5] 2. For binary-formatted messages: Content-Type: application/vnd.kafka.binary.v2+json [3][4][5] If you are performing consumer operations, the required Content-Type header for POST requests (such as creating a consumer) is application/vnd.kafka.v2+json [3][4][5].
Citations:
- 1: https://strimzi.io/docs/bridge/latest/
- 2: https://strimzi.io/docs/bridge/0.21.3/full
- 3: https://strimzi.io/docs/bridge/0.21.6
- 4: https://docs.redhat.com/en/documentation/red_hat_streams_for_apache_kafka/2.6/html/using_the_amq_streams_kafka_bridge/assembly-kafka-bridge-overview-bridge
- 5: https://strimzi.io/docs/bridge/0.25.0/full
🏁 Script executed:
# Check if this is official Strimzi documentation and look for context about admin API
head -50 docs/en/how_to/37-kafka-bridge.mdxRepository: alauda/kafka-docs
Length of output: 2086
🌐 Web query:
Strimzi Kafka Bridge admin API endpoint /admin/topics documentation
💡 Result:
The Strimzi Kafka Bridge does not have an /admin/topics API endpoint. The Strimzi Kafka Bridge API is designed for producing and consuming messages, not for cluster administration [1][2][3]. While the Strimzi Kafka Bridge does expose a /topics resource, it is used for interacting with Kafka topics to send and receive records, not for administrative tasks like creating, deleting, or managing topic configurations [1][2][4]. The available endpoints under the /topics resource include: GET /topics: Used to retrieve a list of topics [1][2][4]. POST /topics/{topicname}: Used to send one or more records to a specified topic [1][2][4]. GET /topics/{topicname}: Used to retrieve metadata for a specific topic [1][5][6]. GET /topics/{topicname}/partitions: Used to retrieve information about partitions for a specific topic [1][5][6]. POST /topics/{topicname}/partitions/{partitionid}: Used to send records to a specific partition [1][2][4]. GET /topics/{topicname}/partitions/{partitionid}: Used to retrieve information about a specific partition [1][5][6]. GET /topics/{topicname}/partitions/{partitionid}/offsets: Used to retrieve begin and end offsets for a specific partition [1][5][6]. Administrative operations in a Kafka cluster, such as creating or deleting topics, are typically handled by the Kafka Admin API (often via the Kafka client libraries or the Strimzi Kafka Operator's custom resources) rather than the HTTP Bridge [7][8]. A proposal for a dedicated Strimzi Admin API was previously considered but was ultimately archived and not implemented [7].
Citations:
- 1: https://strimzi.io/docs/bridge/0.21.3/full
- 2: https://strimzi.io/docs/bridge/latest/
- 3: https://strimzi.io/docs/bridge/latest
- 4: https://strimzi.io/docs/bridge/latest/full
- 5: https://strimzi.io/docs/bridge/0.20.2/full
- 6: https://strimzi.io/docs/bridge/0.20.3/full
- 7: [Enhancement] Strimzi-admin API strimzi/strimzi-kafka-operator#2540
- 8: https://kafka.apache.org/39/javadoc/org/apache/kafka/clients/admin/Admin.html
🏁 Script executed:
# Check the actual content around lines 324-332 in the file
sed -n '310,343p' docs/en/how_to/37-kafka-bridge.mdxRepository: alauda/kafka-docs
Length of output: 1213
Remove the "Create a Topic" section—the /admin/topics endpoint does not exist in Strimzi Kafka Bridge.
The Strimzi Kafka Bridge API does not provide administrative endpoints for topic creation. The Bridge is designed only for producing and consuming messages. Topic creation must be handled through Kafka administrative tools (such as kafka-topics.sh) or the Strimzi Operator, not through the Bridge HTTP API. Remove lines 324-335 and update the content types table (line 340) to remove the reference to "admin API requests such as topic creation."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/en/how_to/37-kafka-bridge.mdx` around lines 324 - 332, Remove the entire
"Create a Topic" section that shows POST to /admin/topics (the Bridge does not
expose an /admin/topics endpoint) and update the content types table to delete
the row or cell that claims the Bridge supports "admin API requests such as
topic creation"; instead keep only producing/consuming behavior in examples and
ensure no examples reference /admin/topics or "admin API" in the content types
table.
Deploying alauda-kafka with
|
| Latest commit: |
0b52161
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://8703a255.alauda-kafka.pages.dev |
| Branch Preview URL: | https://middleware-31069.alauda-kafka.pages.dev |
2 participants
Summary by CodeRabbit
Release Notes