CONTRIB: opentracing: add the OpenTracing filter
This commit adds the OpenTracing filter (hereinafter we will use the
abbreviated name 'the OT filter') to the contrib tree.
The OT filter adds native support for using distributed tracing in HAProxy.
This is enabled by sending an OpenTracing compliant request to one of the
supported tracers; such as Datadog, Jaeger, Lightstep and Zipkin tracers.
Please note: tracers are not listed by any preference, but alphabetically.
The OT filter is a standard HAProxy filter, so what applies to others also
applies to this one (of course, by that I mean what is described in the
documentation, more precisely in the doc/internals/filters.txt file).
The OT filter activation is done explicitly by specifying it in the HAProxy
configuration. If this is not done, the OT filter in no way participates
in the work of HAProxy.
As for the impact on HAProxy speed, this is documented with several tests
located in the test directory, and the result is found in the README-speed-*
files. In short, the speed of operation depends on the way it is used and
the complexity of the configuration, from an almost immeasurable impact to
a significant deceleration (5x and more). I think that in some normal use
the speed of HAProxy with the filter on will be quite satisfactory with a
slowdown of less than 4%.
The OT filter allows intensive use of ACLs, which can be defined anywhere in
the configuration. Thus, it is possible to use the filter only for those
connections that are of interest to us.
More detailed documentation related to the operation, configuration and use
of the filter can be found in the contrib/opentracing directory.
To make the OpenTracing filter easier to configure and compile, several
entries have been added to the Makefile. When running the make utility,
it is possible to use several new arguments:
USE_OT=1 : enable the OpenTracing filter
OT_DEBUG=1 : compile the OpenTracing filter in debug mode
OT_INC=path : force the include path to libopentracing-c-wrapper
OT_LIB=path : force the lib path to libopentracing-c-wrapper
OT_RUNPATH=1 : add libopentracing-c-wrapper RUNPATH to haproxy executable
If USE_OT is set, then an additional Makefile from the contrib/opentracing
directory is included in the compilation process.
2020-12-09 15:54:31 +00:00
|
|
|
Used pools:
|
|
|
|
|
|
|
|
|
|
-------------------------------+-----------------------------+-----------------------------
|
|
|
|
|
head / name | size | define
|
|
|
|
|
-------------------------------+-----------------------------+-----------------------------
|
|
|
|
|
pool_head_ buffer | global.tune.bufsize = 16384 | USE_POOL_BUFFER
|
|
|
|
|
pool_head_ trash | 32 + 16384 | USE_TRASH_CHUNK
|
|
|
|
|
-------------------------------+-----------------------------+-----------------------------
|
|
|
|
|
pool_head_ ot_scope_span | 96 | USE_POOL_OT_SCOPE_SPAN
|
|
|
|
|
pool_head_ ot_scope_context | 64 | USE_POOL_OT_SCOPE_CONTEXT
|
|
|
|
|
pool_head_ ot_runtime_context | 128 | USE_POOL_OT_RUNTIME_CONTEXT
|
|
|
|
|
pool_head_ ot_span_context | 96 | USE_POOL_OT_SPAN_CONTEXT
|
|
|
|
|
-------------------------------+-----------------------------+-----------------------------
|
|
|
|
|
|
|
|
|
|
By defining individual definitions in file include/config.h, it is possible to
|
|
|
|
|
switch individual pools on / off. If a particular pool is not used, memory is
|
|
|
|
|
used in a 'normal' way instead, using malloc()/free() functions.
|
|
|
|
|
|
2020-12-20 20:16:17 +00:00
|
|
|
This is made only from the aspect of debugging the program, i.e. comparing the
|
CONTRIB: opentracing: add the OpenTracing filter
This commit adds the OpenTracing filter (hereinafter we will use the
abbreviated name 'the OT filter') to the contrib tree.
The OT filter adds native support for using distributed tracing in HAProxy.
This is enabled by sending an OpenTracing compliant request to one of the
supported tracers; such as Datadog, Jaeger, Lightstep and Zipkin tracers.
Please note: tracers are not listed by any preference, but alphabetically.
The OT filter is a standard HAProxy filter, so what applies to others also
applies to this one (of course, by that I mean what is described in the
documentation, more precisely in the doc/internals/filters.txt file).
The OT filter activation is done explicitly by specifying it in the HAProxy
configuration. If this is not done, the OT filter in no way participates
in the work of HAProxy.
As for the impact on HAProxy speed, this is documented with several tests
located in the test directory, and the result is found in the README-speed-*
files. In short, the speed of operation depends on the way it is used and
the complexity of the configuration, from an almost immeasurable impact to
a significant deceleration (5x and more). I think that in some normal use
the speed of HAProxy with the filter on will be quite satisfactory with a
slowdown of less than 4%.
The OT filter allows intensive use of ACLs, which can be defined anywhere in
the configuration. Thus, it is possible to use the filter only for those
connections that are of interest to us.
More detailed documentation related to the operation, configuration and use
of the filter can be found in the contrib/opentracing directory.
To make the OpenTracing filter easier to configure and compile, several
entries have been added to the Makefile. When running the make utility,
it is possible to use several new arguments:
USE_OT=1 : enable the OpenTracing filter
OT_DEBUG=1 : compile the OpenTracing filter in debug mode
OT_INC=path : force the include path to libopentracing-c-wrapper
OT_LIB=path : force the lib path to libopentracing-c-wrapper
OT_RUNPATH=1 : add libopentracing-c-wrapper RUNPATH to haproxy executable
If USE_OT is set, then an additional Makefile from the contrib/opentracing
directory is included in the compilation process.
2020-12-09 15:54:31 +00:00
|
|
|
speed of operation using different methods of working with memory.
|
|
|
|
|
|
|
|
|
|
In general, it would be better to use memory pools, due to less fragmentation
|
|
|
|
|
of memory space after long operation of the program. The speed of operation
|
|
|
|
|
is similar to when using standard allocation functions (when testing it was
|
|
|
|
|
shown that pool use was fast by about 1%).
|
