Re: [PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
> >> Yes sure :-) Feel free to send a patch regarding this otherwise I may > >> forget > >> just like I forgot to remove "1.5" from the stats page before releasing > >> 1.7.1. > > Attached. > > Marcin > --- doc/configuration.txt.old 2016-12-12 22:57:04.0 +0100 > +++ doc/configuration.txt 2016-12-13 12:34:47.385694584 +0100 > @@ -13182,7 +13182,7 @@ > > fe_id : integer >Returns an integer containing the current frontend's id. It can be used in > - backends to check from which backend it was called, or to stick all users > + backends to check from which frontend it was called, or to stick all users >coming via a same frontend to the same server. > > fe_name : string Applied, thanks Marcin. Willy
Re: [PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
On 12/13/2016 11:25 AM, Willy Tarreau wrote: >> I think we'll definitely need to have some string-oriented operators. We >> could implement them using converters (eg: append and compare mostly), but >> we also thought that we could replace every sample fetch with a converter >> and allow all expressions to be simplified (eg: a fetcher would just be >> like a converter except that it doesn't affect the existing stack and >> pushes a new value). >> >> With all that in mind, I'm not much tempted to implement too many things >> if we have to redesign them a short time later! Makes sense. Any ETA when this is going to arrive ? >> Yes sure :-) Feel free to send a patch regarding this otherwise I may forget >> just like I forgot to remove "1.5" from the stats page before releasing >> 1.7.1. Attached. Marcin --- doc/configuration.txt.old 2016-12-12 22:57:04.0 +0100 +++ doc/configuration.txt 2016-12-13 12:34:47.385694584 +0100 @@ -13182,7 +13182,7 @@ fe_id : integer Returns an integer containing the current frontend's id. It can be used in - backends to check from which backend it was called, or to stick all users + backends to check from which frontend it was called, or to stick all users coming via a same frontend to the same server. fe_name : string
Re: [External] Re: [PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
Hi Marcin, On Tue, Dec 13, 2016 at 10:53:05AM +0100, Marcin Deranek wrote: > On 12/12/2016 03:14 PM, Willy Tarreau wrote: > > Just merged now, thanks. A few weeks ago someone needed it, I guess it > > was for logging, and I thought we had it though it was not the case, so > > I realized we were missing it. In fact we still have quite a number of > > fields available as log tags which do not have an equivalent sample fetch > > function. It would be nice to ensure we have all of them and document the > > equivalence as well in the logformat table. > Thank you Willy. For logging you can use %f (which is already there) > although in some places fetcher is required and then you are stuck. > BTW: Once I can "extract" frontend name is there a way to compare > "dynamic" data (eg. frontend name) with another "dynamic" data (eg. host > header) ? From what I can see we can easily compare "dynamic" data with > "static" data (eg. some predefined string), but not eg. 2 variables. No there's no such thing unfortunately. Thierry implemented support for variables in the arithmetic operators to allow *some* manipulation to be performed (eg: in order to compare a and b, you can subtract b to a and compare the result), but there's nothing similar with strings. We wanted to implement something like an RPN engine, a stack-based evaluator a bit like forth or various such languages, which require very few tricks and can be very fast. But it was not done by lack of time. I think we'll definitely need to have some string-oriented operators. We could implement them using converters (eg: append and compare mostly), but we also thought that we could replace every sample fetch with a converter and allow all expressions to be simplified (eg: a fetcher would just be like a converter except that it doesn't affect the existing stack and pushes a new value). With all that in mind, I'm not much tempted to implement too many things if we have to redesign them a short time later! > Side note: In docs/configuration.txt I came across this: > > fe_id : integer > Returns an integer containing the current frontend's id. It can be used in > backends to check from which backend it was called, or to stick all users > coming via a same frontend to the same server. > > shouldn't this contain: > ...It can be used in backends to check from which FRONTEND it was > called... ? Yes sure :-) Feel free to send a patch regarding this otherwise I may forget just like I forgot to remove "1.5" from the stats page before releasing 1.7.1. Thanks, Willy
Re: [External] Re: [PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
On 12/12/2016 03:14 PM, Willy Tarreau wrote: > Just merged now, thanks. A few weeks ago someone needed it, I guess it > was for logging, and I thought we had it though it was not the case, so > I realized we were missing it. In fact we still have quite a number of > fields available as log tags which do not have an equivalent sample fetch > function. It would be nice to ensure we have all of them and document the > equivalence as well in the logformat table. Thank you Willy. For logging you can use %f (which is already there) although in some places fetcher is required and then you are stuck. BTW: Once I can "extract" frontend name is there a way to compare "dynamic" data (eg. frontend name) with another "dynamic" data (eg. host header) ? From what I can see we can easily compare "dynamic" data with "static" data (eg. some predefined string), but not eg. 2 variables. Regards, Marcin Side note: In docs/configuration.txt I came across this: fe_id : integer Returns an integer containing the current frontend's id. It can be used in backends to check from which backend it was called, or to stick all users coming via a same frontend to the same server. shouldn't this contain: ...It can be used in backends to check from which FRONTEND it was called... ?
Re: [PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
Hi Marcin, On Mon, Dec 12, 2016 at 02:08:05PM +0100, Marcin Deranek wrote: > Hi, > These 2 patches add ability to fetch frontend/backend name in your > logic, so they can be used later to make routing decisions (fe_name) or > taking some actions based on backend which responded to request (be_name). > In our case we needed a fetcher to be able to extract information we > needed from frontend name. Just merged now, thanks. A few weeks ago someone needed it, I guess it was for logging, and I thought we had it though it was not the case, so I realized we were missing it. In fact we still have quite a number of fields available as log tags which do not have an equivalent sample fetch function. It would be nice to ensure we have all of them and document the equivalence as well in the logformat table. Thanks, Willy
[PATCH] Add fe_name/be_name fetchers next to existing fe_id/be_id
Hi,
These 2 patches add ability to fetch frontend/backend name in your
logic, so they can be used later to make routing decisions (fe_name) or
taking some actions based on backend which responded to request (be_name).
In our case we needed a fetcher to be able to extract information we
needed from frontend name.
Regards,
Marcin Deranek
--- haproxy-1.7.0/src/backend.c.old 2016-11-25 16:39:17.0 +0100
+++ haproxy-1.7.0/src/backend.c 2016-12-12 12:57:24.683678340 +0100
@@ -1679,6 +1679,24 @@
return 1;
}
+/* set string to the name of the backend */
+static int
+smp_fetch_be_name(const struct arg *args, struct sample *smp, const char *kw, void *private)
+{
+ if (!smp->strm)
+ return 0;
+
+ smp->data.u.str.str = (char *)smp->strm->be->id;
+ if (!smp->data.u.str.str)
+ return 0;
+
+ smp->data.type = SMP_T_STR;
+ smp->flags = SMP_F_CONST;
+ smp->data.u.str.len = strlen(smp->data.u.str.str);
+
+ return 1;
+}
+
/* set temp integer to the id of the server */
static int
smp_fetch_srv_id(const struct arg *args, struct sample *smp, const char *kw, void *private)
@@ -1801,6 +1819,7 @@
{ "avg_queue", smp_fetch_avg_queue_size, ARG1(1,BE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "be_conn", smp_fetch_be_conn,ARG1(1,BE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "be_id", smp_fetch_be_id, 0, NULL, SMP_T_SINT, SMP_USE_BKEND, },
+ { "be_name", smp_fetch_be_name,0, NULL, SMP_T_STR, SMP_USE_BKEND, },
{ "be_sess_rate", smp_fetch_be_sess_rate, ARG1(1,BE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "connslots", smp_fetch_connslots, ARG1(1,BE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "nbsrv", smp_fetch_nbsrv, ARG1(1,BE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
--- haproxy-1.7.0/doc/configuration.txt.old 2016-11-25 16:39:17.0 +0100
+++ haproxy-1.7.0/doc/configuration.txt 2016-12-12 13:35:32.542340475 +0100
@@ -13072,6 +13072,10 @@
Returns an integer containing the current backend's id. It can be used in
frontends with responses to check which backend processed the request.
+be_name : string
+ Returns a string containing the current backend's name. It can be used in
+ frontends with responses to check which backend processed the request.
+
dst : ip
This is the destination IPv4 address of the connection on the client side,
which is the address the client connected to. It can be useful when running
--- haproxy-1.7.0/src/frontend.c.old 2016-11-25 16:39:17.0 +0100
+++ haproxy-1.7.0/src/frontend.c 2016-12-12 12:44:05.573873525 +0100
@@ -167,6 +167,20 @@
return 1;
}
+/* set string to the name of the frontend */
+static int
+smp_fetch_fe_name(const struct arg *args, struct sample *smp, const char *kw, void *private)
+{
+ smp->data.u.str.str = (char *)smp->sess->fe->id;
+ if (!smp->data.u.str.str)
+ return 0;
+
+ smp->data.type = SMP_T_STR;
+ smp->flags = SMP_F_CONST;
+ smp->data.u.str.len = strlen(smp->data.u.str.str);
+ return 1;
+}
+
/* set temp integer to the number of HTTP requests per second reaching the frontend.
* Accepts exactly 1 argument. Argument is a frontend, other types will cause
* an undefined behaviour.
@@ -213,6 +227,7 @@
static struct sample_fetch_kw_list smp_kws = {ILH, {
{ "fe_conn", smp_fetch_fe_conn, ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "fe_id",smp_fetch_fe_id,0, NULL, SMP_T_SINT, SMP_USE_FTEND, },
+ { "fe_name", smp_fetch_fe_name, 0, NULL, SMP_T_STR, SMP_USE_FTEND, },
{ "fe_req_rate", smp_fetch_fe_req_rate, ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ "fe_sess_rate", smp_fetch_fe_sess_rate, ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
{ /* END */ },
--- haproxy-1.7.0/doc/configuration.txt.old 2016-11-25 16:39:17.0 +0100
+++ haproxy-1.7.0/doc/configuration.txt 2016-12-12 13:38:05.235730351 +0100
@@ -13164,6 +13168,11 @@
backends to check from which backend it was called, or to stick all users
coming via a same frontend to the same server.
+fe_name : string
+ Returns a string containing the current frontend's name. It can be used in
+ backends to check from which frontend it was called, or to stick all users
+ coming via a same frontend to the same server.
+
sc_bytes_in_rate([,]) : integer
sc0_bytes_in_rate([]) : integer
sc1_bytes_in_rate([]) : integer
