Fix: Add TCPMon usage with WSO2 Micro Integrator#2251
Conversation
|
|
📝 WalkthroughOverviewThis PR adds comprehensive documentation on how to use TCPMon with WSO2 Micro Integrator, addressing the gap in existing guidance where users lacked clear instructions for integrating TCPMon into their MI setups. ChangesAdded a new section "Using TCPMon with WSO2 Micro Integrator" to the TCPMon documentation that provides two practical scenarios:
Both scenarios include step-by-step configuration instructions for TCPMon settings and the required integration artifact modifications. File modified: WalkthroughThis PR adds a new documentation section to the TCPMon message monitoring guide for WSO2 Micro Integrator. The addition covers two practical use cases: (1) monitoring inbound traffic from clients to MI by positioning TCPMon between the client and MI service, and (2) monitoring outbound traffic from MI to backend services by redirecting the MI endpoint configuration to TCPMon. Each scenario includes step-by-step instructions for configuration and traffic capture. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md (1)
59-82:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd an explicit HTTP-only reminder in the MI-specific section.
This section should restate that TCPMon monitoring here applies to HTTP traffic, so readers do not assume HTTPS interception is supported in these flows.
Suggested edit
When developing integrations with WSO2 Micro Integrator (MI), you can use TCPMon to monitor messages in two main ways: intercepting messages sent to the MI, and intercepting messages sent from the MI to an external backend. +These examples assume HTTP traffic; TCPMon does not support viewing HTTPS-encrypted message content.🤖 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 `@en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md` around lines 59 - 82, Add a clear HTTP-only reminder to the MI-specific TCPMon monitoring sections: insert a concise sentence at the start of both "Monitoring Messages Sent TO WSO2 MI (Client -> TCPMon -> MI)" and "Monitoring Messages Sent FROM WSO2 MI (MI -> TCPMon -> Backend)" stating that these steps apply only to HTTP traffic and that TCPMon does not intercept HTTPS/SSL traffic (so HTTPS endpoints or secure backends will not be captured). Also mention that if the integration uses an <endpoint> with HTTPS, users must disable TLS or use a TLS‑aware proxy instead.
🤖 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
`@en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md`:
- Line 80: The example hardcodes localhost in the Micro Integrator `<endpoint>`
target URL which breaks setups where MI and TCPMon are on different hosts;
update the `<endpoint>` example target URL to use a placeholder or the TCPMon
host/IP (e.g., http://<TCPMON_HOST>:8081/...) instead of
http://localhost:8081/... and add a short note clarifying that "localhost" is
valid only when MI and TCPMon run on the same host so readers must replace it
with the actual TCPMon host/IP when remote.
---
Outside diff comments:
In
`@en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md`:
- Around line 59-82: Add a clear HTTP-only reminder to the MI-specific TCPMon
monitoring sections: insert a concise sentence at the start of both "Monitoring
Messages Sent TO WSO2 MI (Client -> TCPMon -> MI)" and "Monitoring Messages Sent
FROM WSO2 MI (MI -> TCPMon -> Backend)" stating that these steps apply only to
HTTP traffic and that TCPMon does not intercept HTTPS/SSL traffic (so HTTPS
endpoints or secure backends will not be captured). Also mention that if the
integration uses an <endpoint> with HTTPS, users must disable TLS or use a
TLS‑aware proxy instead.
🪄 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: a034a881-d04f-424d-9f79-6d83a0f52d89
📒 Files selected for processing (1)
en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md
| 2. Open TCPMon and add a listener on an unused local port (e.g., `8081`). | ||
| 3. Set the **Target Hostname** to the backend's hostname (`backend.com`). | ||
| 4. Set the **Target Port** to the backend's port (`80`). | ||
| 5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL. |
There was a problem hiding this comment.
Avoid hardcoding localhost for MI endpoint redirection.
Line 80 can misroute traffic when MI and TCPMon run on different hosts. Use the TCPMon host/IP in the example and note that localhost applies only to same-host setups.
Suggested edit
-5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL.
+5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://<TCPMON_HOST>:8081/...`) instead of the actual backend URL. Use `localhost` only when MI and TCPMon run on the same machine.📝 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.
| 5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL. | |
| 5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://<TCPMON_HOST>:8081/...`) instead of the actual backend URL. Use `localhost` only when MI and TCPMon run on the same machine. |
🤖 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
`@en/docs/observe-and-manage/classic-observability-tcp/message-monitoring-with-tcpmon.md`
at line 80, The example hardcodes localhost in the Micro Integrator `<endpoint>`
target URL which breaks setups where MI and TCPMon are on different hosts;
update the `<endpoint>` example target URL to use a placeholder or the TCPMon
host/IP (e.g., http://<TCPMON_HOST>:8081/...) instead of
http://localhost:8081/... and add a short note clarifying that "localhost" is
valid only when MI and TCPMon run on the same host so readers must replace it
with the actual TCPMon host/IP when remote.
|
|
||
|  | ||
|
|
||
| ## Using TCPMon with WSO2 Micro Integrator |
There was a problem hiding this comment.
| ## Using TCPMon with WSO2 Micro Integrator | |
| ## Using TCPMon with WSO2 Integrator: MI |
|
|
||
| When developing integrations with WSO2 Micro Integrator (MI), you can use TCPMon to monitor messages in two main ways: intercepting messages sent to the MI, and intercepting messages sent from the MI to an external backend. | ||
|
|
||
| ### 1. Monitoring Messages Sent TO WSO2 MI (Client -> TCPMon -> MI) |
There was a problem hiding this comment.
| ### 1. Monitoring Messages Sent TO WSO2 MI (Client -> TCPMon -> MI) | |
| ### Monitoring messages sent to WSO2 MI (Client -> TCPMon -> MI) |
| 5. Update your client application to send its requests to the TCPMon listener port (`http://localhost:8291/...`) instead of directly to the MI. | ||
| 6. TCPMon will capture the incoming request, display it, and forward it to the Micro Integrator. | ||
|
|
||
| ### 2. Monitoring Messages Sent FROM WSO2 MI (MI -> TCPMon -> Backend) |
There was a problem hiding this comment.
| ### 2. Monitoring Messages Sent FROM WSO2 MI (MI -> TCPMon -> Backend) | |
| ### Monitoring messages sent from WSO2 MI (MI -> TCPMon -> Backend) |
|
|
||
| ## Using TCPMon with WSO2 Micro Integrator | ||
|
|
||
| When developing integrations with WSO2 Micro Integrator (MI), you can use TCPMon to monitor messages in two main ways: intercepting messages sent to the MI, and intercepting messages sent from the MI to an external backend. |
There was a problem hiding this comment.
| When developing integrations with WSO2 Micro Integrator (MI), you can use TCPMon to monitor messages in two main ways: intercepting messages sent to the MI, and intercepting messages sent from the MI to an external backend. | |
| When developing integrations with WSO2 Integrator: MI, you can use TCPMon to monitor messages in two main ways: intercepting messages sent to the MI, and intercepting messages sent from the MI to an external backend. |
|
|
||
| ### 1. Monitoring Messages Sent TO WSO2 MI (Client -> TCPMon -> MI) | ||
|
|
||
| If you want to inspect the requests sent from a client application before they reach a proxy service or API hosted on the Micro Integrator: |
There was a problem hiding this comment.
| If you want to inspect the requests sent from a client application before they reach a proxy service or API hosted on the Micro Integrator: | |
| If you want to inspect the requests sent from a client application before they reach a proxy service or API hosted in MI: |
|
|
||
| ### 2. Monitoring Messages Sent FROM WSO2 MI (MI -> TCPMon -> Backend) | ||
|
|
||
| To inspect the outgoing payload the Micro Integrator sends to an external backend service: |
There was a problem hiding this comment.
| To inspect the outgoing payload the Micro Integrator sends to an external backend service: | |
| To inspect the outgoing payload that MI sends to an external backend service: |
| 2. Open TCPMon and add a listener on an unused local port (e.g., `8081`). | ||
| 3. Set the **Target Hostname** to the backend's hostname (`backend.com`). | ||
| 4. Set the **Target Port** to the backend's port (`80`). | ||
| 5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL. |
There was a problem hiding this comment.
| 5. In your Micro Integrator integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL. | |
| 5. In your MI integration artifact (e.g., the `<endpoint>` definition), change the target URL to point to the TCPMon listener (`http://localhost:8081/...`) instead of the actual backend URL. |
3 participants
Resolves #1622 by adding a section on how to specifically configure and use TCPMon with WSO2 Micro Integrator (monitoring both incoming and outgoing messages).