Yilialinn opened a new issue, #792:
URL: https://github.com/apache/rocketmq-site/issues/792

   ## Feature request
   
   ### 1. Please describe the feature you are requesting
   
   Would the RocketMQ community be open to a short English integration guide 
showing how Apache APISIX sends structured API access logs to RocketMQ through 
its native `rocketmq-logger` plugin?
   
   The proposed guide would cover:
   
   - version-pinned prerequisites for RocketMQ and Apache APISIX;
   - creating a topic and starting a consumer for verification;
   - configuring an APISIX Route to send structured access logs to RocketMQ;
   - verifying single-entry and batched messages;
   - using message keys, tags, and a minimal custom log format;
   - documenting buffering, retry, drop, TLS/ACL, and sensitive-data boundaries 
without making unsupported delivery guarantees.
   
   This would be a documentation contribution only. It would not change 
RocketMQ or APISIX runtime behavior.
   
   Before opening a documentation PR, I would validate the complete example 
against Apache APISIX 3.17.0 and a RocketMQ version agreed on by the 
maintainers. APISIX's current integration tests use RocketMQ 4.6.0, so I do not 
want to assume compatibility with a newer RocketMQ release without reproducing 
it first.
   
   Relevant APISIX sources:
   
   - [`rocketmq-logger` documentation for APISIX 
3.17.0](https://github.com/apache/apisix/blob/3.17.0/docs/en/latest/plugins/rocketmq-logger.md)
   - [`rocketmq-logger` 
implementation](https://github.com/apache/apisix/blob/3.17.0/apisix/plugins/rocketmq-logger.lua)
   - [RocketMQ logger 
tests](https://github.com/apache/apisix/blob/3.17.0/t/plugin/rocketmq-logger.t)
   
   ### 2. Proposed use case
   
   APISIX users can already publish gateway access logs to RocketMQ, but the 
integration is currently documented only on the APISIX side. A RocketMQ-hosted 
guide would give RocketMQ users a reproducible example of an API gateway acting 
as a producer of structured operational events, including the expected message 
shape and relevant reliability boundaries.
   
   Would this content fit the RocketMQ website? If so, which documentation 
section and RocketMQ version should it target?
   
   ### 3. Importance
   
   Nice-to-have. The integration already exists; the goal is to make the 
supported workflow easier to discover and verify from the RocketMQ side.
   
   ### 4. Proposed subtasks
   
   - [ ] Confirm the target documentation section and RocketMQ version.
   - [ ] Run and record a version-pinned end-to-end validation.
   - [ ] Submit one focused English documentation PR with the tested 
configuration and expected output.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to