Opentracing differentiate operations

[gnunn1]

[provide a description of the issue]

When using opentracing with apicast there does not appear to be any differentiation of operations. All operations are lumped under '/' or 'apicast'. This makes finding and viewing operations challenging from the apicast service since everything is combined together. Is it possible to have the operation name be set to some concatenation of 3scale service plus mapping or metric name associated with the mapping?

If opentracing is used with the back-end services being managed by apicast then finding things is easier since you can just search on the backend service. However in many organizations it's quite likely that they will want to leverage opentracing across a mix of greenfield and legacy systems and those legacy systems would not be using opentracing leaving only the apicast service.

Version

nginx version: openresty/1.13.6.2 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) built with OpenSSL 1.1.0h 27 Mar 2018 TLS SNI support enabled configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt='-O2 -DNGX_LUA_ABORT_AT_PANIC -I/usr/local/openresty/zlib/include -I/usr/local/openresty/pcre/include -I/usr/local/openresty/openssl/include' --add-module=../ngx_devel_kit-0.3.0 --add-module=../echo-nginx-module-0.61 --add-module=../xss-nginx-module-0.06 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.32 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.08 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.13 --add-module=../ngx_lua_upstream-0.07 --add-module=../headers-more-nginx-module-0.33 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.19 --add-module=../redis2-nginx-module-0.15 --add-module=../redis-nginx-module-0.3.7 --add-module=../ngx_stream_lua-0.0.5 --with-ld-opt='-Wl,-rpath,/usr/local/openresty/luajit/lib -L/usr/local/openresty/zlib/lib -L/usr/local/openresty/pcre/lib -L/usr/local/openresty/openssl/lib -Wl,-rpath,/usr/local/openresty/zlib/lib:/usr/local/openresty/pcre/lib:/usr/local/openresty/openssl/lib' --with-pcre-jit --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_auth_request_module --with-http_secure_link_module --with-http_random_index_module --with-http_gzip_static_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-threads --with-dtrace-probes --with-stream --with-stream_ssl_module --with-http_ssl_module

Steps To Reproduce

Follow instructions in blog here: https://itnext.io/adding-opentracing-support-to-apicast-api-gateway-a8e0a38347d2

Current Result

All operations are grouped under apicast or /

Expected Result

Operations should be mapped to a concatenation of service plus mapping or metric name associated with mapping if not set to 'hits'.

[mikz]

That / is what nginx location is getting executed. We can rename it to something more obvious like policy-chain. I'd not go for templating the operation name with a service name, id or metrics. We can use tags for that.

[jmprusi]

@mikz I don't know if ServiceID/Metric is available at the nginx context, if we can access that info or make it available we can add that as an OpenTracing TAG:

Like:

opentracing_tag http_user_agent $http_user_agent;

[mikz]

@jmprusi It is. I tried locally adding opentracing_tag apicast.service_id $service_id; and it works just fine. We have nginx variables populated with some info.

[jmprusi]

@mikz that's cool! :)

Now we need to define the desired variables:

• service_id
• metric ?
• mapping ? (Beware with the regex and high cardinality...)

[mikz]

@jmprusi several metrics and several mappings can match. The matched metrics is a product of matched mappings and their "delta" property. I'd try to not add stuff just because we can, so it would be nice to know the use case, so we can export the correct data. You can already get matched metrics and mapping rules by using the debug header 3scale-debug.

[jmprusi]

@mikz I can see the metric names matched (not with the delta etc..) being useful to filter some request etc.. as hyphen-separated values?

But I don't really have a strong opinion on this...