MadhuTiwari-345 commented on issue #13027: URL: https://github.com/apache/apisix/issues/13027#issuecomment-4041221264
Thank you for the detailed feedback, @Baoyuantop . These are very helpful points. Let me address the concerns you raised: **1. False Positive Handling** You are correct that simple EMA-based detection could misclassify legitimate traffic patterns such as promotions, scheduled jobs, or daily peaks. To reduce false positives, the spike detection logic could include additional safeguards, for example: * A configurable **multiplier threshold** (e.g., trigger only if `current_rate > multiplier × EMA`, where multiplier defaults to something like 3–5). * A **minimum observation window** before detection becomes active. * Optional **cooldown periods** to prevent repeated triggering. The goal would be to keep the algorithm simple enough to run efficiently inside the gateway while still filtering obvious abnormal spikes. **2. Cold Start Behavior** For new consumers with no baseline: * The plugin could operate in a **warm-up mode** for the first N windows (e.g., 30–60 seconds). * During this period, it would only collect data and initialize the EMA baseline. * Spike detection would be disabled until sufficient historical data is available. This should prevent incorrect early enforcement. **3. Value of Phase 1** I understand your point that a baseline-only plugin may act mostly as a metrics collector. My intention with Phase 1 was mainly to validate: * Shared memory storage behavior * Per-consumer metric tracking * Performance impact inside the request path However, I agree that providing **basic spike detection and temporary limit tightening in the first version** would make the feature immediately useful. I am open to adjusting the scope so the initial implementation includes: * Baseline tracking (EMA) * Basic spike detection * Temporary rate tightening while keeping the logic intentionally simple. **4. Intended Use Case** The goal is not to replace external anomaly detection systems (such as WAFs or monitoring platforms), but to **add lightweight adaptive protection directly at the gateway layer**. This can help in scenarios where: * A normally well-behaved API consumer suddenly sends a burst of traffic due to misconfiguration or abuse. * Operators want **automatic first-line protection** without relying entirely on external systems. So the feature would complement existing infrastructure rather than replace it. **5. External Plugin PoC** Starting as an **external plugin** to validate the algorithm and performance impact makes sense. That would allow experimentation without affecting the core plugins. I can begin with a minimal PoC external plugin that includes: * per-consumer request tracking * EMA baseline calculation * simple spike detection * temporary rate tightening Once we gather feedback and performance observations, we could evaluate whether it makes sense to move it into core. Please let me know if this direction sounds reasonable. If so, I will proceed with a small PoC external plugin and share the implementation for review. -- 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]
