-
Notifications
You must be signed in to change notification settings - Fork 762
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
haproxy 2.4 opentracing not send span if daemon option is configured #1204
Comments
Hello @bandrea83, thank you for reporting the bug. The problem is that the OpenTracing library is initialized before HAProxy initialize the daemon mode. Establishing this mode kills the OpenTracing thread, after which the correct operation of the OpenTracing filter is no longer possible. Also, HAProxy crashes on deinitialization of the OpenTracing library. That will be resolved tomorrow. |
This patch solves the problem reported in github issue #1204, where the OpenTracing filter cannot communicate with the selected tracer if HAProxy is run in daemon mode. The author of the reported issue uses Zipkin tracer, while in this example Jaeger tracer is used (see gdb output below). The problem is that the OpenTracing library is initialized before HAProxy initialize the daemon mode. Establishing this mode kills the OpenTracing thread, after which the correct operation of the OpenTracing filter is no longer possible. Also, HAProxy crashes on deinitialization of the OpenTracing library. The initialization of the OpenTracing library has been moved from the flt_ot_init() function (which is started before switching the HAProxy to daemon mode) to the flt_ot_init_per_thread() function (which is run after switching the HAProxy to daemon mode). Gdb output of crashed HAProxy process: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `../../../haproxy -f sa/haproxy.cfg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8131fd5629 in pthread_join (threadid=140192831239936, thread_return=0x0) at pthread_join.c:45 45 pthread_join.c: No such file or directory. (gdb) where #0 0x00007f8131fd5629 in pthread_join (threadid=140192831239936, thread_return=0x0) at pthread_join.c:45 #1 0x00007f812f15abc7 in std::thread::join() () from /tmp/haproxy-os-master/contrib/opentracing/test/libjaeger_opentracing_plugin-0.5.0.so #2 0x00007f812f0fb6f7 in jaegertracing::reporters::RemoteReporter::close() () from /tmp/haproxy-os-master/contrib/opentracing/test/libjaeger_opentracing_plugin-0.5.0.so #3 0x00007f812f0b7055 in jaegertracing::reporters::CompositeReporter::close() () from /tmp/haproxy-os-master/contrib/opentracing/test/libjaeger_opentracing_plugin-0.5.0.so #4 0x00007f812f0b9136 in jaegertracing::Tracer::Close() () from /tmp/haproxy-os-master/contrib/opentracing/test/libjaeger_opentracing_plugin-0.5.0.so #5 0x00007f81309def32 in ot_tracer_close (tracer=0x55fb48057390) at ../../src/tracer.cpp:91 #6 0x000055fb41785705 in ot_close (tracer=0x55fb48061168) at contrib/opentracing/src/opentracing.c:208 #7 0x000055fb4177fc64 in flt_ot_deinit (p=<optimized out>, fconf=<optimized out>) at contrib/opentracing/src/filter.c:215 #8 0x000055fb418bc038 in flt_deinit (proxy=proxy@entry=0x55fb4805ce50) at src/filters.c:360 #9 0x000055fb41893ed1 in free_proxy (p=0x55fb4805ce50) at src/proxy.c:315 #10 0x000055fb41888809 in deinit () at src/haproxy.c:2217 #11 0x000055fb41889078 in deinit_and_exit (status=0) at src/haproxy.c:2343 #12 0x000055fb4173d809 in main (argc=<optimized out>, argv=<optimized out>) at src/haproxy.c:3230 This patch should be backported to all branches where the OpenTracing filter is located.
Hello @bandrea83, have you tried whether the OpenTracing filter now sends data to the tracer? |
Hi @zaga00 , seem to work as expected now Nice work and thank you so much! haproxy team is doing a so great work ;) |
…d/or chroot mode This patch solves the problem reported in github issue #1204, where the OpenTracing filter cannot communicate with the selected tracer if HAProxy is run in daemon mode. This commit also solves github issue #1274, where the problem manifests itself when using the 'chroot' keyword in the HAProxy configuration. This is solved so that the initialization of the OpenTracing plugin is split into two operations, first the plugin (dynamic library) is loaded before switching the HAProxy to daemon mode (or chroot) and then the tracer thread is started. This means that nothing is retrieved from the file system in runtime. After applying this commit, opentracing C wrapper version 1.1.0 should be used because the earlier version does not have separated initialization functions. This resolves GitHub issues #1204 and #1274.
…d/or chroot mode This patch solves the problem reported in github issue haproxy#1204, where the OpenTracing filter cannot communicate with the selected tracer if HAProxy is run in daemon mode. This commit also solves github issue haproxy#1274, where the problem manifests itself when using the 'chroot' keyword in the HAProxy configuration. This is solved so that the initialization of the OpenTracing plugin is split into two operations, first the plugin (dynamic library) is loaded before switching the HAProxy to daemon mode (or chroot) and then the tracer thread is started. This means that nothing is retrieved from the file system in runtime. After applying this commit, opentracing C wrapper version 1.1.0 should be used because the earlier version does not have separated initialization functions. This resolves GitHub issues haproxy#1204 and haproxy#1274. (cherry picked from commit 9425ed4) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Detailed description of the problem
if in global section you enable daemon option trace is not sended to zipkin endpoint
Expected behavior
it also send span to zipkin server if daemon option is configured
Steps to reproduce the behavior
enable daemon in [global] section
Do you have any idea what may have caused this?
Do you have an idea how to solve the issue?
What is your configuration?
Output of
haproxy -vv
anduname -a
The text was updated successfully, but these errors were encountered: