Hi!
I am doing something similar — in our case there is not single endpoint, but a
few of the endpoints behave differently depending on what the JSON payload is.
For that, I capture up to 256 bytes of the body. In our case that’s plenty to
find the json snippet I am looking for. Then, per ACLs I match regexes for each
action.
Finally, this ACL (and maybe others) are used to set a transaction variable
(txn.op) in our case.
In the log-format, I then log this operation as an additional field. That way,
I can see all the timing values and other stuff the regular logging contains,
and can then filter by the operation type.
The config looks something like this (the real thing is really long and I don’t
have enough time to strip it down to a working example right now)
...
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\
%tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %ID\ %sslv\ %sslc\ %{+Q}[var(txn.op)]\
%{+Q}[var(txn.host),lower,word(2,'.')]\ %{+Q}r
…
listen api_internal
...
option http-buffer-request
# Capture the body for the backends to inspect. This can only
# be done in the frontend. Declare a capture slot with the implicit id=0 for
256 bytes.
declare capture request len 256 # id 0
# Store up to 256 bytes of request body in the slot with id 0 for later
inspection.
http-request capture req.body id 0
# Content based ACLs to discern request types
acl EMPTY_BODY req.body_len -m int eq 0
acl rq_query_ids query -m beg -i ids=
…
acl rq_accept_wildcard req.hdr(Accept) -i '*/*'
acl rq_body_action_delete req.body -m reg -i '"action"\s*:\s*"delete"'
...
# Detect "relevant" operations and stick them in a variable for logging
# Set a default first in case nothing known matches
http-request set-var(txn.op) str(Unkwn)
...
http-request set-var(txn.op) str(DocDelMul) if METH_POST rq_path_documents
rq_content_type_json rq_body_action_delete # Delete Multiple Documents
…
Hope that helps.
Daniel
--
Daniel Schneller
Principal Cloud Engineer
CenterDevice GmbH | Hochstraße 11
| 42697 Solingen
tel: +49 1754155711 | Deutschland
daniel.schnel...@centerdevice.de | www.centerdevice.de
Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431
> On 20. Sep. 2017, at 09:46, Garbage <garb...@gmx.de> wrote:
>
>
>
> I know that haproxy exposes metrics like „Tr“ and “Tt”. My problem with the
> application I have to proxy is that this application hides all of her
> functionality behind one endpoint. To address the app I have to POST to (just
> an example) https://hpalm/endpoint.
> The payload that gets POSTed always has this shape:
>
> {
> 0: \0000001C\0:conststr:GetServerSettings,
> ....
>
>
> The string behind „conststr“ is the real API endpoint, there are 10s of
> different meanings.
>
> Is it possible to have haproxy or a “plugin” inspect the POST body, extract
> the string and create metrics like “Tr” and “Tt” for each of those values ?
>
>
>
>
