-
Notifications
You must be signed in to change notification settings - Fork 835
Generic version of src_inc_gpc with key parameter #2423
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
Comments
Interesting use-case, thanks for sharing it :) Despite most sticky counters actions and fetches like I can't tell if implementing a whole new set of generic fetches based on But maybe providing an optional argument to ie: http-request track-sc0(0) var(txn.api_key) table blocked-clients # don't create if not found
acl already_killed sc_get_gpc0(0) gt 0
http-request reject if already_killed
http-request track-sc0 var(txn.api_key) table blocked-clients # make sure to create the entry if missing
acl abuse src_http_req_rate gt 10
acl kill sc_inc_gpc0(0) gt 0
http-request reject if abuse kill Although it seems this can already be achieved (in a not so convenient way) by making use of the optional something like that (not tested though, I might be wrong): http-request track-sc0 var(txn.api_key) table temp-clients
acl already_killed sc_get_gpc0(0, blocked-clients) gt 0
http-request reject if already_killed
acl abuse src_http_req_rate gt 10
acl kill sc_inc_gpc0(0, blocked-clients) gt 0
http-request reject if abuse kill Edit: forget about this last example, it is not a viable workaround: |
I think that what Philipp would like in fact, is that we'd provide a split version of src_inc_gpc0(): that one combines two operations at one, a sample fetch function (src) and a converter (inc_gpc0). I don't see any reason why we couldn't have a set of get_gpc0(), inc_gpc0() and clr_gpc0() as converters that apply on the input sample. In fact there's already table_gpc0() which does the get_gpc0() one. We'd in fact need to implement table_inc_gpc*() and table_clr_gpc*(). I don't see any technical showstopper against this and it makes a lot of sense to me. It would even allow to simplify the doc by referring to the canonical converters everywhere ;-) |
As discussed in GH #2423, there are some cases where src_{inc,clr}_gpc* is not sufficient because we need to perform the lookup on a specific key. Indeed, just like we did in e642916 ("MEDIUM: stktable: leverage smp_fetch_* helpers from sample conv"), we can easily implement new table converters based on existing fetches. This is what we do in this patch. Also the doc was updated so that src_{inc,clr}_gpc* fetches now point to their generic equivalent table_{inc,clr}_gpc*. Indeed, src_{inc,clr}_gpc* are simply aliases. This should fix GH #2423.
Your Feature Request
Hi,
the fetch method
src_inc_gpc
can be used to put an entry for the source IP address of the current request into a stick table if a condition is met. The docs show the following example:Now let me modify this a little bit to show my use-case:
This is almost functionally the same but the counter has been moved to another table and the expiry of that table determines how long the client will be rejected. The advantage is that the number of entries in
blocked-clients
reflects the number of currently blocked unique IP addresses. Since the number of entries is visible in the Prometheus metrics generated by HAProxy we can have a nice graph about the number of currently blocked clients.This works well when the key of the stick table is an IPv4/6 address. But as far is I know there is no way to have an equivalent of
src_inc_gpc
if the tables from the example had an API key as table keys. The key feature ofsrc_inc_gpc
in this example is to only create the entry in theblocked-clients
table if the client has been flagged a abusive.So given that there is a variable
txn.api_key
something like this would be nice:What are you trying to do?
Implement rate-limiting with something different that a source IP address as key.
Output of
haproxy -vv
The text was updated successfully, but these errors were encountered: