-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apache Kafka Scaler: Implementation for Excluding Persistent Lag #3965
Conversation
/run-e2e kafka* |
@JosephABC the e2e test failed :( |
I think the kafka e2e tests was taking longer than 20 mins and timedout. I changed the AssertReplicaCountNotChangeDuringTimePeriod from 3 mins to 1 min. The testPersistentLag test passed in 150 sec on local cluster Can we increase the timeout for the go test in run-all.sh? |
Made changes to kafka test for persistent lag to reduce testing duration. Total Testing duration for kafka_test.go was 1109.934s on local cluster. Hope this helps to get the e2e test to pass |
/run-e2e kafka* |
@JosephABC thanks I started the e2e tests, could you please rebase this PR and merge changes? We merged another PR in the meantime that caused conflicts, should be simple though. |
@JosephABC I can see that you have again a lot of commits here, that's why the DCO fails. could you fix that? |
Signed-off-by: JosephABC <[email protected]>
Signed-off-by: JosephABC <[email protected]>
/run-e2e kafka* |
Summary
Add implementation for excluding consumer lag from partitions with persistent lag.
Use Case
In situations where consumer is unable to process / consume from partition due to errors etc., committed offset will not change, and consumer lag on that partition will be increasing and never be decreased. KEDA trigger scaling towards the maxReplicaCount.
If partition lag is deemed as persistent, excluding its consumer lag will allow KEDA to trigger scaling appropriately based on the consumer lag observed on other topics and partition, and not be affected by this consumer lag which will not be resolved by scaling.
Logic
Upon each polling cycle, check if current consumer offset is same as previous consumer offset.
Different: return endOffset - consumerOffset (No different from current implementation)
Same: return 0 (To exclude this partition's consumer lag from the total lag)
Checklist
Relates to #3904
Relates to kedacore/keda-docs#984