Need for Application-Specific HTTP Tracing in Web Gateway

1️⃣ Description of the idea

Enhance the Web Gateway to support HTTP Trace at the web application level, rather than globally. This means developers and administrators could enable and tracing the individual web applications (e.g., /myapp, /api/myapi) while debugging, rather than capturing all traffic across all apps.

2️⃣ Who is the target audience?

Backend/API developers troubleshooting specific applications

Support teams investigating production issues
3️⃣ What problem does it solve?

Currently, enabling HTTP Trace logs all traffic passing through the Web Gateway, including SMP, system apps, internal APIs, and unrelated services. This leads to High log volume with lots of irrelevant data

Application-level tracing allows for:

• More focused debugging for specific application

• Smaller, cleaner trace logs and improved performance during trace sessions

4️⃣ How does this impact the efficiency, stability, reliability, etc., of the product?

• Reduces trace file size and processing time by capturing only relevant traffic

• improves accuracy in identifying problems with less noise in logs

• Speeds up debugging and root cause analysis

5️⃣ Provide a specific use case or scenario that illustrates how this idea could be used in practice

A developer is debugging an issue with a custom REST API hosted at /api/myapi, but enabling global HTTP Trace in the Web Gateway captures additional traffic from system applications like /api/atelier, /api/iam, and /csp/sys.

Current Challenge:
The trace log is large, hard to analyze and not recommendable in high traffic Production

With Per-Application HTTP Trace:

Enables trace only for /api/myapi, reducing the log size and focusing solely on the API and Lower risk during trace in production environments.