Skip to content
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

Closed
bandrea83 opened this issue Mar 31, 2021 · 3 comments
Closed
Labels
status: fixed This issue is a now-fixed bug. type: bug This issue describes a bug.

Comments

@bandrea83
Copy link

bandrea83 commented Mar 31, 2021

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

  1. enable OT
  2. in global section enable daemon option
  3. start haproxy

Do you have any idea what may have caused this?

Do you have an idea how to solve the issue?

What is your configuration?

global
    daemon
#   nbthread 1
    maxconn 5000
    hard-stop-after 10s
#   log localhost:514 local7 debug
#   debug
    stats socket /tmp/haproxy-fe.sock mode 666 level admin

defaults
    log     global
    option  httplog
    option  dontlognull
    retries 3
    maxconn 4000
    timeout connect 5000
    timeout client  50000
    timeout server  50000

listen stats
    mode http
    bind *:8001
    stats uri /
    stats admin if TRUE
    stats refresh 10s

frontend ot-test-fe-frontend
    filter opentracing id ot-test-fe config fe/ot.cfg
    bind *:10080
    mode http
    default_backend servers-backend


backend servers-backend
    mode http
    server server-1 127.0.0.1:11080

Output of haproxy -vv and uname -a

HA-Proxy version 2.4-dev13-09cc669 2021/03/19 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: Linux 3.10.0-1160.15.2.el7.x86_64 #1 SMP Thu Jan 21 16:15:07 EST 2021 x86_64
Build options :
  TARGET  = linux-glibc
  CPU     = generic
  CC      = cc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label -DTCP_USER_TIMEOUT=18
  OPTIONS = USE_EPOLL=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_THREAD=1 USE_LINUX_TPROXY=1 USE_OPENSSL=1 USE_LUA=1 USE_ZLIB=1 USE_DL=1 USE_OT=1
  DEBUG   =

Feature list : +EPOLL -KQUEUE +NETFILTER +PCRE +PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS +OT -QUIC

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=4).
Built with OpenSSL version : OpenSSL 1.1.1e  17 Mar 2020
Running on OpenSSL version : OpenSSL 1.1.1e  17 Mar 2020
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with network namespace support.
Built with OpenTracing support.
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 4.8.5 20150623 (Red Hat 4.8.5-44)

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
              h2 : mode=HTTP       side=FE|BE     mux=H2
            fcgi : mode=HTTP       side=BE        mux=FCGI
       <default> : mode=HTTP       side=FE|BE     mux=H1
       <default> : mode=TCP        side=FE|BE     mux=PASS

Available services : none

Available filters :
        [  OT] opentracing
        [SPOE] spoe
        [CACHE] cache
        [FCGI] fcgi-app
        [COMP] compression
        [TRACE] trace

$ uname -a
Linux 184260ebf98c 3.10.0-1160.15.2.el7.x86_64 #1 SMP Thu Jan 21 16:15:07 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
@bandrea83 bandrea83 added status: needs-triage This issue needs to be triaged. type: bug This issue describes a bug. labels Mar 31, 2021
@zaga00
Copy link
Contributor

zaga00 commented Apr 1, 2021

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.

haproxy-mirror pushed a commit that referenced this issue Apr 2, 2021
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.
@zaga00
Copy link
Contributor

zaga00 commented Apr 3, 2021

Hello @bandrea83,

have you tried whether the OpenTracing filter now sends data to the tracer?

@bandrea83
Copy link
Author

Hi @zaga00 , seem to work as expected now

Nice work and thank you so much! haproxy team is doing a so great work ;)

@TimWolla TimWolla added status: fixed This issue is a now-fixed bug. and removed status: needs-triage This issue needs to be triaged. labels Apr 4, 2021
haproxy-mirror pushed a commit that referenced this issue Jun 10, 2021
…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.
FireBurn pushed a commit to FireBurn/haproxy that referenced this issue Jun 11, 2021
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: fixed This issue is a now-fixed bug. type: bug This issue describes a bug.
Projects
None yet
Development

No branches or pull requests

3 participants