Le 6/1/21 à 8:26 PM, Aleksandar Lazic a écrit :
On 01.06.21 14:23, Tim Düsterhus wrote:
Aleks,
On 6/1/21 10:30 AM, Aleksandar Lazic wrote:
This phrasing is understandable to me, but now I'm wondering if this is the
best solution. Maybe the already existing user-configurable unique request ID
should instead be sent to the SPOE and then logged?
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#7.3.6-unique-id
The request_counter (%rt) you mentioned could be embedded into this unique-id.
Well this uniqe-id is not send as Stream ID to SPOA receiver, due to this fact
can't you debug which stream is the troubled one.
Yes, that's why I suggested that the SPOE is extended to also include this
specific ID somewhere (just) for logging purposes.
Yep.
Any opinion from the other community Members?
The SID provided in the SPOE log message is the one used in the SPOP frame
header. This way it is possible to match a corresponding log message emitted by
the agent.
Regarding the format for this log message, its original purpose was to diagnose
problems. Instead of adding custom information, I guess the best would be to
have a "log-format" directive. At least to not break existing tools parsing
those log messages. But to do so, all part of the current message must be
available via log variables and/or sample fetches. And, at first glance, it will
be hard to achieve (sample fetches are probably easier though).
Regarding the stream_uniq_id sample fetch, it is a good idea to add it. In fact,
when it makes sense, a log variable must also be accessible via a sample fetch.
Tim's remarks about the patch are valid. For the scope, INTRN or L4CLI, I don't
know. I'm inclined to choose INTRN.
--
Christopher Faulet
