open-telemetry / opentelemetry-cpp-contrib Goto Github PK

License: Apache License 2.0

CMake 2.33% Shell 1.78% C++ 37.87% C 6.74% Dockerfile 1.68% PHP 0.04% JavaScript 0.04% Elixir 1.04% Starlark 0.34% Makefile 1.75% Batchfile 0.05% XSLT 0.15% Python 44.98% Emacs Lisp 0.52% Kaitai Struct 0.33% Java 0.27% PowerShell 0.09%

opentelemetry-cpp-contrib's Introduction

OpenTelemetry C++ Contrib

This repository contains set of components extending functionality of the OpenTelemetry SDK. Instrumentation libraries, exporters, and other components can find their home here.

Contributing

See CONTRIBUTING.md

We meet weekly, and the time of the meeting alternates between Monday at 13:00 PT and Wednesday at 9:00 PT. The meeting is subject to change depending on contributors' availability. Check the OpenTelemetry community calendar for specific dates and Zoom meeting links.

Meeting notes are available as a public Google doc. For edit access, get in touch on Slack.

Maintainers (@open-telemetry/cpp-contrib-maintainers):

Ehsan Saei
Lalit Kumar Bhasin, Microsoft
Marc Alff, Oracle
Tom Tan, Microsoft

Approvers (@open-telemetry/cpp-contrib-approvers):

DEBAJIT DAS, Cisco
Johannes Tax, Grafana Labs
Josh Suereth, Google
Kumar Pratyush, Cisco
Max Golovanov, Microsoft
Siim Kallas, Splunk
Tobias Stadler
Tomasz Rojek

Emeritus Maintainer/Approver/Triager:

None

Thanks to all the people who have contributed

Support

This repository accepts public contributions. Individual components are developed by numerous contributors. Approvers and maintainers of the main OpenTelemetry C++ SDK repository are not expected to directly contribute to every component.

GitHub CODEOWNERS file is a simple way to automate away some of the pain associated with the review system on github, by automatically assigning reviewers to a pull request based on which files were modified. Individual components are encouraged to propose changes to CODEOWNERS file following the process described here.

This repository is great for community supported components. Vendor specific code that requires a higher supportability guarantees needs to be placed in vendor's repository. Packages in vendor repositories would be prefixed with the vendor name to signify the difference from community-supported components.

opentelemetry-cpp-contrib's People

Contributors

Stargazers

Watchers

Forkers

seemk seantbooker graphaelli tomrosystems lalitb isabella232 madhusudanas anshulkumar19 eyjohn alexanderwert johanneswuerbach open-o11y mxiamxia anoyli tippexs bpmm9012 prashant-scienaptic tobiasstadler phillipuniverse dgeorges kpratyus e-morency ae07177 jvilhuber absolutesoftware rcjsuen vijaynjvr mehiel tiithansen kayzzzz x-qdo shivp0616 debajitdas arbiv esigo sfc-gh-jallie gnm444 elementalwarrior samueladamczak symbianx cedricziel alfianabdi pondidum maxgolov jecofang01 fanzhenzhen1 ahrefs fuctor debasis9dash lizfeed owent aharmlesspyro revpoint eduardohf-ciandt fdiskbrain saschabrechmannvhv svrnm es eguzki cyrilsicard jefferbrecht rsvancara sahilganguly vsouza fabiocicerchia dpiddock kmai pddg raphberube timvtinsa gaffneyd4 tangx-labs thomsontan fludo niande-xbox hs13960 vlad1805 wangtaotao0524 dkulig 0xd34d10cc kentxxq datadog matlab-plus-plus bykiss mfrw txomon gscalderonl swamidass alex1704 resokk pnvnd jessie2023git papapiya cloudnativeleague nemoshlag ketacea johnbayo yl12138 php53unit metodiobetsanov

opentelemetry-cpp-contrib's Issues

11#0: 26934686 Unable to get trace context when expanding tracecontext var, client: ..., server: _server, request: "GET /api/ HTTP/1.1", host: ".."

Hi Team, I find an error message in Nginx when I set opentelemetry off in http block

The error message is as follow:

9#0: *4 connect() failed (111: Connection refused) while connecting to upstream, client: *.*.*.*, server: *_server, request: "GET /api/* HTTP/1.1", upstream: "http://*.*.*.*:10001/hello", host: "*.*.*.*"

11#0: *26934686 Unable to get trace context when expanding tracecontext var, client: *.*.*.*, server: *_server, request: "GET /api/v1/address/default HTTP/1.1", host: "*.*.*"

is there any configuration i miss?

thank you!

Httpd traces missing service name

Running a compiled-from-source apache httpd 2.4.51 (latest), with the downloaded mod-otel (0.1.0):

Configs:

OpenTelemetryExporter   otlp
OpenTelemetryEndpoint otel-collector.default.svc.cluster.local:4317
OpenTelemetryPropagators trace-context
OpenTelemetryIgnoreInbound off
OpenTelemetrySetResource service.name test.service

I configured the otel-collector to push traces to a grafana-tempo instance as well as a jaeger server:

receivers:
  jaeger:                            # the receives all come from the OpenTelemetry collector.  more configuration information can
    protocols:                       # be found there: https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver
      thrift_http:                   #
      grpc:                          # for a production deployment you should only enable the receivers you need!
      thrift_binary:
      thrift_compact:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
extensions:
  health_check:
  pprof:
  zpages:
exporters:
  otlp:
    endpoint: tempo-otlp.observability.example.com:443
  jaeger:
    endpoint: "jaeger.example.com:14250"
    tls:
      insecure: true
service:
  extensions: [health_check,pprof,zpages]
  pipelines:
    traces/1:
      receivers: [otlp,jaeger]
      processors: [batch]
      exporters: [otlp,jaeger]
  telemetry:
    logs:
      level: "info"

In tempo, the traces seem to exist but show absolutely no data at all.
In jaeger, The trace shows up, but jaeger says Service: OTLPResourceNoServiceName

Side-note: I can't tell what resource the otel module is sending, as the build doesn't seem to use the later opentelemetry-cpp library (1.0.0) which should include open-telemetry/opentelemetry-cpp#906 So it's hard to say what's going on here. As far as I can tell (newbie to telemetry!) service.name resource is required, but I suspect it's not being sent.

Steps to reproduce
Describe exactly how to reproduce the error. Include a code sample if applicable.

apache-http 2.4.51 + mod-otel 0.1.0 -> otel-collector (otlp) -> tempo(otlp) and or jaeger

Given the right opentelemetry-cpp ostream output (see library version 1.0.0 and the PR above) this should be testable via the instrumentation/http/tests in some way.

What is the expected behavior?
What did you expect to see?

I expected to see valid traces in both grafana-tempo and jaeger.

What is the actual behavior?
What did you see instead?

"empty" traces in tempo (no data at all) and traces with OTLPResourceNoServiceName as the service name in jaeger.

Additional context
Add any other context about the problem here.

Add test-case for ApiUtils to increase code-coverage

nginx module

Hi,

I would like to contribute an nginx module which is based on opentelemetry-cpp. Would this repository be the right place?

What would the the directory structure be - each contribution in a subdirectory or would each contrib be a submodule?

With each contrib's code in a separate directory (i.e. a huge monorepo) my hunch is that handling issues might be a bit more complicated down the line. Any suggestions appreciated 🙂

Regarding setup of OTEL HTTPD instrumentation with Zipkin backend

I am trying to setup the HTTPD instrumentation module. These are the steps I followed

Running the Dockerfile
Loading the libstdc++.so.6 module, otel.so module and OpenTelemetry.conf file in the apache.conf

This is my Opentelemetry.conf file

<IfModule mod_otel.cpp>
# OpenTelemetryExporter set exporter type:
# file - means put spans into file
# otlp - means use otlp

# OpenTelemetryExporter   file
# if you don't specify path for exporter by default standard error will be used
# which is just simply apache error log
# OpenTelemetryPath /tmp/output-spans

OpenTelemetryExporter   otlp
OpenTelemetryEndpoint docker.for.mac.localhost:51103

# OpenTelemetryBatch for batch configuration. Takes 3 arguments:
# Max Queue Size
# Delay (in milliseconds, 1000 = 1s)
# Max Export Batch Size

# OpenTelemetryBatch 10 5000 5

# OpenTelemetryPropagators sets which context propagator should be used (defaults to none)
# currently supported values are (only one can be specified at the moment):
# trace-context - headers: tracestate, traceparent
# b3 - single header (b3)
# b3-multiheader - headers: X-B3-TraceId, X-B3-SpanId

OpenTelemetryPropagators b3-multiheader

# OpenTelemetryIgnoreInbound (defaults to true) indicates that we don't trust incoming context.
# This is safe when httpd is an edge server with traffic from Internet. Set it to false only
# if you run httpd in safe environment.

# OpenTelemetryIgnoreInbound off

OpenTelemetrySetResource service.name apache-web-server
OpenTelemetrySetAttribute foo bar

</IfModule>

I am running the dockerfile on Mac. I have a Zipkin instance running on a separate docker image which is mapped to localhost:51103. Whenever I use the "OpenTelemetryExporter file" I can see the output spans.
Could someone help me with the steps I am missing. Thanks!!

Nginx instrumentation: Base span start/end on `request_time`

Is your feature request related to a problem?
Yes: Span duration may not be as accurate as it could be. This is based on span starting/ending in such a way that start and end times are implicitly the "current" time. E.g., here's how the span is ended:

opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp

Line 277 in 32bcaf7

span->End();

The potentials for inaccuracy are:

the span isn't started exactly when the first request byte is received from the client
the span isn't ended exactly when the last response byte is sent to the client

Describe the solution you'd like
There might be a more accurate span duration to try and use: the request_time embedded variable:

request processing time in seconds with a milliseconds resolution (1.3.9, 1.2.6); time elapsed since the first bytes were read from the client

I'm not sure if that's a meaningfully different definition than the same-named variable available during request logging:

request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client

What I'm least sure about is what the span start or end times ought be chosen as such that their difference is request_time.

Describe alternatives you've considered
Just leave it as-is. I haven't quantified the size of inaccuracy that I'm alleging; it may be extremely negligible.

otel-nginx: Can this module be used for openresty?

Just curious if this module can be used for openresty? If not is there any plan to include openresty in future release?

Docker image on docker hub

Is it possible to have an docker image on dockerhub (or somewhere else)?
I am building an example of a system monitored with opentelemetry, but struggeling how to build this project, because I do not have that much experience with building Nginx from source (never done that).

Thanks in advance, both it it happens and if it does not happen.

Updating Build and install instructions after Apache Module contribution

The present Readme and Dockerfile have to be updated as the directory structure has changed for the newly contributed Otel-webserver-module

mod_apache_otel.cpp_handler span appearing in the traces.

Environment :
otel-webserver-module installed in centos6 with apache-2.2 with jaeger as backend

Steps to reproduce :

opentelemetry_module.conf :
`LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_common.so
LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_resources.so
LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_trace.so
LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_exporter_ostream_span.so
LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_exporter_otprotocol.so

#Load the ApacheModule SDK
LoadFile /opt/opentelemetry-webserver-sdk/sdk_lib/lib/libopentelemetry_webserver_sdk.so
#Load the Apache Module. In this example for Apache 2.2
LoadModule otel_apache_module /opt/opentelemetry-webserver-sdk/WebServerModule/Apache/libmod_apache_otel22.so
ApacheModuleEnabled ON

#ApacheModule Otel Exporter details
ApacheModuleOtelSpanExporter otlp
ApacheModuleOtelExporterEndpoint otel-collector-ip:port

ApacheModuleServiceName SERVICE_NAME_VQMGK
ApacheModuleServiceNamespace OT_WEBSERVER_APP_PTMZA
ApacheModuleServiceInstanceId 71410bDYKXO

ApacheModuleResolveBackends ON
ApacheModuleTraceAsError ON
ApacheModuleReportAllInstrumentedModules OFF
`

Issue :
mod_apache_otel.cpp_handler span coming up in the traces in jaegerUI.

Unused parameter warning when compiling the Nginx module

Describe your environment
I'm compiling inside a k8s.gcr.io/ingress-nginx/controller:v0.46.0 Docker image but the same thing can be seen in the output of the GitHub Actions so I don't think it's environment-specific here.

Steps to reproduce

$ mkdir build
$ cd build
$ cmake -DCMAKE_TYPE=RELEASE -DNGINX_BIN=/etc/nginx/nginx \
           -DCMAKE_PREFIX_PATH=/install -DCMAKE_INSTALL_PREFIX=/etc/nginx/modules \
           -DNGINX_VERSION=1.18.0 \
           -DCURL_LIBRARY=/usr/lib/libcurl.so.4 ..
$ make -j2

Follow the build instructions and build the library.
You'll see warnings about an unused parameter.

/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp: In function 'ngx_int_t OtelGetTraceId(ngx_http_request_t*, ngx_http_variable_value_t*, uintptr_t)':
/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:229:81: warning: unused parameter 'data' [-Wunused-parameter]
  229 | OtelGetTraceId(ngx_http_request_t* req, ngx_http_variable_value_t* v, uintptr_t data) {
      |                                                                       ~~~~~~~~~~^~~~
/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp: In function 'ngx_int_t OtelGetSpanId(ngx_http_request_t*, ngx_http_variable_value_t*, uintptr_t)':
/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:278:80: warning: unused parameter 'data' [-Wunused-parameter]
  278 | OtelGetSpanId(ngx_http_request_t* req, ngx_http_variable_value_t* v, uintptr_t data) {
      |                                                                      ~~~~~~~~~~^~~~

What is the expected behavior?
Compilation should be smooth without any warnings. Whenever the compiler prints something it raises alarms that there may be something wrong or misconfigured in the compilation process.

What is the actual behavior?
I see two warnings about some unused parameter.

Additional context
This can be seen in the build nginx docker step in a GitHub Action build output

Add build support for Ubuntu 20.04

Instruments here can't be search in https://opentelemetry.io/registry/

No result:
https://opentelemetry.io/registry/?s=nginx&component=&language=
https://opentelemetry.io/registry/?s=http&component=&language=

Add CI for otel-webserver-module

For the otel-webserver-module, we need to add CI, which should include build and running the unit tests initially. More steps could be added incrementally.

Updating the OpenTelemetry C++ SDK dependency for Otel webserver module

As requested by the community during the contribution process the old version of Opentelemetry C++ SDK has to be updated to the present version.

Add build support for Centos 7

Add CODEOWNERS file

This repo does not have CODEOWNERS file at the moment. Among other things this means that newly created PRs do not have any default reviewers assigned. Which leads, I believe, to a very long review process.

How to quickly deploy opentelemetry-cpp-contrib-nginx?

Hello everyone, I want to test the nginx opentracing+elastic apm solution, when I am building
I found it very troublesome when opentelemetry-cpp-contrib-nginx. Opentelemetry-cpp-contrib requires grpc, and grpc requires gcc 5.4+... The system I use is centos 7.7, and there are a lot of troubles in compiling grpc, in short, it’s a bit bad .

I am thinking that if the community can openly provide the otel_ngx_module.so file, I will directly compile it into nginx, which is much easier. Because I just want to test the effect of nginx + elastic apm.

By the way, I want to test the binary version of nginx.
If I am wrong, please correct me

failed to compile nginx accroding to instrumentation/nginx/README.md

build on Ubuntu 20, got the following error when compile nginx

In file included from /install/include/absl/synchronization/mutex.h:73,
                 from /install/include/grpcpp/impl/codegen/sync.h:32,
                 from /install/include/grpcpp/impl/codegen/client_context.h:55,
                 from /install/include/grpcpp/impl/codegen/call_op_set.h:34,
                 from /install/include/grpcpp/impl/codegen/server_context.h:35,
                 from /install/include/grpcpp/impl/codegen/async_stream.h:26,
                 from /install/include/grpcpp/impl/codegen/async_generic_service.h:26,
                 from /install/include/opentelemetry/proto/collector/trace/v1/trace_service.grpc.pb.h:25,
                 from /install/include/opentelemetry/exporters/otlp/otlp_grpc_exporter.h:10,
                 from /home/ljl/code/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:20:
/install/include/absl/synchronization/internal/per_thread_sem.h:84:10: error: reference to ‘base_internal’ is ambiguous
   84 |   friend absl::base_internal::ThreadIdentity* CreateThreadIdentity();
      |          ^~~~
In file included from /install/include/opentelemetry/nostd/absl/utility/utility.h:50,
                 from /install/include/opentelemetry/nostd/absl/types/variant.h:46,
                 from /install/include/opentelemetry/nostd/variant.h:52,
                 from /install/include/opentelemetry/common/attribute_value.h:10,
                 from /install/include/opentelemetry/sdk/trace/recordable.h:6,
                 from /install/include/opentelemetry/sdk/trace/processor.h:8,
                 from /home/ljl/code/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:1:
/install/include/opentelemetry/nostd/absl/base/internal/invoke.h:49:11: note: candidates are: ‘namespace absl::otel_v1::base_internal { }’
   49 | namespace base_internal {
      |           ^~~~~~~~~~~~~
In file included from /install/include/absl/synchronization/mutex.h:67,
                 from /install/include/grpcpp/impl/codegen/sync.h:32,
                 from /install/include/grpcpp/impl/codegen/client_context.h:55,
                 from /install/include/grpcpp/impl/codegen/call_op_set.h:34,
                 from /install/include/grpcpp/impl/codegen/server_context.h:35,
                 from /install/include/grpcpp/impl/codegen/async_stream.h:26,
                 from /install/include/grpcpp/impl/codegen/async_generic_service.h:26,
                 from /install/include/opentelemetry/proto/collector/trace/v1/trace_service.grpc.pb.h:25,
                 from /install/include/opentelemetry/exporters/otlp/otlp_grpc_exporter.h:10,
                 from /home/ljl/code/opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:20:

where the content of the build.make is

184 otel_ngx_module.so: CMakeFiles/otel_ngx_module.dir/src/propagate.cpp.o
185 otel_ngx_module.so: CMakeFiles/otel_ngx_module.dir/src/script.cpp.o
186 otel_ngx_module.so: CMakeFiles/otel_ngx_module.dir/build.make
187 otel_ngx_module.so: opentelemetry-cpp::version-NOTFOUND
188 otel_ngx_module.so: opentelemetry-cpp::common-NOTFOUND
189 otel_ngx_module.so: opentelemetry-cpp::trace-NOTFOUND
190 otel_ngx_module.so: opentelemetry-cpp::otlp_grpc_exporter-NOTFOUND
191 otel_ngx_module.so: opentelemetry-cpp::otlp_http_exporter-NOTFOUND
192 otel_ngx_module.so: opentelemetry-cpp::ostream_span_exporter-NOTFOUND
193 otel_ngx_module.so: opentelemetry-cpp::zpages-NOTFOUND
194 otel_ngx_module.so: opentelemetry-cpp::http_client_curl-NOTFOUND

script for build grpc

#!/bin/bash

mkdir -p cmake/build 
cd cmake/build

cmake -DgRPC_INSTALL=ON -DgRPC_BUILD_TESTS=OFF -DCMAKE_INSTALL_PREFIX=/install -DCMAKE_BUILD_TYPE=Release \
  -DgRPC_BUILD_GRPC_NODE_PLUGIN=OFF -DgRPC_BUILD_GRPC_OBJECTIVE_C_PLUGIN=OFF -DgRPC_BUILD_GRPC_PHP_PLUGIN=OFF \
  -DgRPC_BUILD_GRPC_PHP_PLUGIN=OFF -DgRPC_BUILD_GRPC_PYTHON_PLUGIN=OFF -DgRPC_BUILD_GRPC_RUBY_PLUGIN=OFF \
        ../..

make -j2 
sudo make install

script for building opentelemetry-cpp

#!/bin/bash

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/install \
-DCMAKE_PREFIX_PATH=/install -DWITH_OTLP=ON \
-DWITH_OTLP_HTTP=OFF -DBUILD_TESTING=OFF \
-DWITH_EXAMPLES=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
.. 

make -j6
sudo make install

script for build nginx

#!/bin/bash

mkdir -p build 
cd build 

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/install -DCMAKE_INSTALL_PREFIX=/usr/share/nginx/modules .. 
make -j2
sudo make install

Target "otel_ngx_module" links to target "CURL::libcurl" but the target was not found.

Hi,

I am working on a universal docker-build container image to build the NGINX OTEL module.

My baseimage is ubunut:20.04. After building grpc, cmake, googletest with benchmark and opentelemetry I was able to start building the NGINX Module.

While running cmake I received the following error:

root@825df8ee05d0:/opentelemetry-cpp-contrib/instrumentation/nginx/build# cmake ..
-- nginx: using version 1.19.9
-- nginx: --with-compat enabled
-- Configuring done
CMake Error at CMakeLists.txt:12 (add_library):
  Target "otel_ngx_module" links to target "CURL::libcurl" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?


-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

I have modified the CMakeLists.txt
and have added

find_package( CURL REQUIRED )

With this small fix its working just fine. Is this a docker issue? Have you seen this issue before?

Steps to reproduce
git clone inside the docker container and issue
cmake ..

What is the expected behavior?
No errors just my lovely NGINX Module file 💚

What is the actual behavior?
Error message shown above

nginx: `opentelemetry_propagate` in `http` block not honored

Describe your environment

$ nginx -V
nginx version: nginx/1.20.0
built by gcc 7.3.1 20180712 (Red Hat 7.3.1-13) (GCC)
built with OpenSSL 1.1.1g FIPS  21 Apr 2020
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'

$ uname -rs
Linux 4.14.248-189.473.amzn2.x86_64

EC2 AMI ID ami-060f1292334857878, name aws-elasticbeanstalk-amzn-2.0.20211001.64bit-eb_nodejs12_amazon_linux_2-hvm-2021-10-16T18-34

Using nginx instrumentation in https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/30e872e1d91cb696b48418300fddd8f9fc36b914/instrumentation/nginx, built after manually building grpc, then opentelemetry-cpp.

Steps to reproduce
See this gist for output of nginx -T and TOML config: https://gist.github.com/spencerwilson/3652d37a494710451afef9ee472ae7c3

What is the expected behavior?
Requests nginx makes to http://127.0.0.1:4000 include traceparent header (at least) in every request.

What is the actual behavior?
Application listening on port 4000 isn't getting any requests with any W3C Trace Context headers.

Additional context

The only lines in /var/log/nginx/error.log around nginx -s reload are like 2021/11/13 07:17:03 [notice] 12367#12367: signal process started; nothing about OpenTelemetry
In addition to nginx -s reload I also tried quitting and starting it again
Nothing in /var/log/nginx/access.log other than normal access logs
User root is the owner of the nginx master process, user nginx is owner of the worker processes. Both users can read both /etc/nginx/conf.d/opentelemetry.conf and /etc/nginx/conf.d/opentelemetry_config.toml
I'm not actually running any process on localhost:4317 (where the OTLP/gRPC exporter is configured in the TOML to connect to), in case that could cause a problem.

My expectation is that the include on L24 in the nginx config gist file would be putting my

opentelemetry_config /etc/nginx/conf.d/opentelemetry_config.toml;
opentelemetry_propagate;

directives into the http block—which the module's README says is a supported place to put them.

My C++ and Nginx skills are poor so I appreciate any suggestions of other things to check. Thank you!

Add link to opentelemetry.io under About section

Under the About section of this repo (which you can access from the main repo page -- click the gear icon next to the About title):

Under Website, add https://opentelemetry.io

We're looking to do this uniformly for all OTel org repos.

For example:

Support Debian Bullseye (11.3) in Github Action

Is your feature request related to a problem?

Debian Bullseye (11.3) was released not long ago, and this appears to be what the Dockerhub Nginx debian image now uses

Describe the solution you'd like
Add Debian 11.3 to the OS builds in the Github Action for the nginx module

Nginx Instrumentation: ld: symbol(s) not found for architecture x86_64

Hi Team, recently i want to make the nginx instrument, but i met some problems.
I have install grpc and opentelemetry-cpp(based on v0.7.0), but an error when during my make procedure.

cmake command

cmake .. -DCMAKE_PREFIX_PATH=~/Software/opentelemetry-cpp/      -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl

output of cmake

-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found opentelemetry-cpp: ~/Software/opentelemetry-cpp/include
-- Found Protobuf: /usr/local/lib/libprotobuf.a (found version "3.15.8")
-- Found ZLIB: /usr/local/lib/libz.dylib (found version "1.2.11")
-- Found OpenSSL: /usr/local/opt/openssl/lib/libcrypto.dylib (found version "1.1.1k")
-- Found c-ares: /usr/local/lib/cmake/c-ares/c-ares-config.cmake (found version "1.17.1")
-- Found RE2 via CMake.
-- Found CURL: /usr/lib/libcurl.dylib (found version "7.54.0")
-- Found nlohmann_json: /usr/local/lib/cmake/nlohmann_json/nlohmann_jsonConfig.cmake (found version "3.9.1")
-- nginx: using version 1.18.0
-- nginx: --with-compat enabled
-- Configuring done
-- Generating done
-- Build files have been written to: ~/Code/github/opentelemetry-cpp-contrib-main/instrumentation/nginx/build

but an error occur when i execute make command

[ 35%] No build step for 'project_nginx'
[ 41%] No install step for 'project_nginx'
[ 47%] Completed 'project_nginx'
[ 47%] Built target project_nginx
Scanning dependencies of target otel_ngx_module
[ 52%] Building CXX object CMakeFiles/otel_ngx_module.dir/src/nginx_config.cpp.o
[ 58%] Building C object CMakeFiles/otel_ngx_module.dir/src/toml.c.o
[ 64%] Building CXX object CMakeFiles/otel_ngx_module.dir/src/agent_config.cpp.o
[ 70%] Building CXX object CMakeFiles/otel_ngx_module.dir/src/trace_context.cpp.o
[ 76%] Building CXX object CMakeFiles/otel_ngx_module.dir/src/otel_ngx_module.cpp.o
~/Code/github/opentelemetry-cpp-contrib-main/instrumentation/nginx/src/otel_ngx_module.cpp:612:33: error: no matching constructor for initialization of 'otlp::OtlpExporterOptions'
      otlp::OtlpExporterOptions opts{endpoint};
                                ^   ~~~~~~~~~~
~/Software/opentelemetry-cpp/include/opentelemetry/exporters/otlp/otlp_exporter.h:22:8: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'std::string'
      (aka 'basic_string<char, char_traits<char>, allocator<char> >') to 'const opentelemetry::v0::exporter::otlp::OtlpExporterOptions' for 1st argument
struct OtlpExporterOptions
       ^
~/Software/opentelemetry-cpp/include/opentelemetry/exporters/otlp/otlp_exporter.h:22:8: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'std::string'
      (aka 'basic_string<char, char_traits<char>, allocator<char> >') to 'opentelemetry::v0::exporter::otlp::OtlpExporterOptions' for 1st argument
~/Software/opentelemetry-cpp/include/opentelemetry/exporters/otlp/otlp_exporter.h:22:8: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided
1 error generated.
make[2]: *** [CMakeFiles/otel_ngx_module.dir/src/otel_ngx_module.cpp.o] Error 1
make[1]: *** [CMakeFiles/otel_ngx_module.dir/all] Error 2
make: *** [all] Error 2

And i add a default constructor to otlp::OtlpExporterOptions in cpp of opentelemetry-cpp, but another error occur

[100%] Linking CXX shared library otel_ngx_module.dylib
Undefined symbols for architecture x86_64:
  "_ngx_array_create", referenced from:
      InitModule(ngx_conf_s*) in otel_ngx_module.cpp.o
      OtelNgxSetCustomAttribute(ngx_conf_s*, ngx_command_s*, void*) in otel_ngx_module.cpp.o
  "_ngx_array_push", referenced from:
      InitModule(ngx_conf_s*) in otel_ngx_module.cpp.o
      MergeLocConf(ngx_conf_s*, void*, void*) in otel_ngx_module.cpp.o
      OtelNgxSetCustomAttribute(ngx_conf_s*, ngx_command_s*, void*) in otel_ngx_module.cpp.o
  "_ngx_conf_log_error", referenced from:
      OtelNgxConfHandler(ngx_conf_s*, long) in nginx_config.cpp.o
  "_ngx_conf_set_flag_slot", referenced from:
      kOtelNgxCommands in otel_ngx_module.cpp.o
  "_ngx_http_add_variable", referenced from:
      CreateOtelNgxVariables(ngx_conf_s*) in otel_ngx_module.cpp.o
  "_ngx_http_core_module", referenced from:
      GetOperationName(ngx_http_request_s*) in otel_ngx_module.cpp.o
      NgxHttpModuleMainConf(ngx_http_request_s*) in otel_ngx_module.cpp.o
      GetNgxServerName(ngx_http_request_s const*) in otel_ngx_module.cpp.o
      InitModule(ngx_conf_s*) in otel_ngx_module.cpp.o
  "_ngx_http_get_indexed_variable", referenced from:
      GetTraceContext(ngx_http_request_s*) in otel_ngx_module.cpp.o
      StartNgxSpan(ngx_http_request_s*) in otel_ngx_module.cpp.o
  "_ngx_http_get_variable_index", referenced from:
      CreateOtelNgxVariables(ngx_conf_s*) in otel_ngx_module.cpp.o
  "_ngx_http_module", referenced from:
      OtelNgxStart(ngx_cycle_s*) in otel_ngx_module.cpp.o
  "_ngx_http_script_compile", referenced from:
      CompileScript(ngx_conf_s*, ngx_str_t, NgxCompiledScript*) in script.cpp.o
  "_ngx_http_script_run", referenced from:
      NgxCompiledScript::Run(ngx_http_request_s*, ngx_str_t*) in otel_ngx_module.cpp.o
  "_ngx_http_script_variables_count", referenced from:
      CompileScript(ngx_conf_s*, ngx_str_t, NgxCompiledScript*) in script.cpp.o
  "_ngx_log_error_core", referenced from:
      OtelAgentConfigLoad(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, ngx_log_s*, OtelNgxAgentConfig*) in agent_config.cpp.o
      SetupExporter(toml_table_t*, ngx_log_s*, OtelNgxAgentConfig*) in agent_config.cpp.o
      SetupProcessor(toml_table_t*, ngx_log_s*, OtelNgxAgentConfig*) in agent_config.cpp.o
      SetupSampler(toml_table_t*, ngx_log_s*, OtelNgxAgentConfig*) in agent_config.cpp.o
      SetupOtlpExporter(toml_table_t*, ngx_log_s*, OtelNgxAgentConfig*) in agent_config.cpp.o
      GetTraceContext(ngx_http_request_s*) in otel_ngx_module.cpp.o
      StartNgxSpan(ngx_http_request_s*) in otel_ngx_module.cpp.o
      ...
  "_ngx_palloc", referenced from:
      CreatePooledString(ngx_pool_s*, opentelemetry::v0::nostd::string_view) in trace_context.cpp.o
  "_ngx_pcalloc", referenced from:
      CreateOtelMainConf(ngx_conf_s*) in otel_ngx_module.cpp.o
      CreateOtelLocConf(ngx_conf_s*) in otel_ngx_module.cpp.o
  "_ngx_pool_cleanup_add", referenced from:
      StartNgxSpan(ngx_http_request_s*) in otel_ngx_module.cpp.o
  "_ngx_strncasecmp", referenced from:
      FindHeader(ngx_http_request_s*, opentelemetry::v0::nostd::string_view, opentelemetry::v0::nostd::string_view*) in propagate.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [otel_ngx_module.dylib] Error 1
make[1]: *** [CMakeFiles/otel_ngx_module.dir/all] Error 2
make: *** [all] Error 2

i don't have any idea about this error, could anyone help me? Thanks in advance!!!!!

How to report traces directly to jaeger.

Since the Otel implementation allows us to send spans directly to backend instances, how can we send spans directly to jaeger without setting up an OTel Collector?

Nginx worker thread dies in internal requests

Describe your environment

OpenTelemetry C++ 1.2.0
OpenTelemetry C++ Contrib at 3808bc3
Nginx 1.19.9

I haven't narrowed down how to reproduce the issue yet but I'm getting a segfault in the code that was added in #94. Looks like the insert call on line 402 is bad. :(

opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp

Lines 384 to 404 in 3808bc3

    
           TraceContext* CreateTraceContext(ngx_http_request_t* req, ngx_http_variable_value_t* val) { 
        
             ngx_pool_cleanup_t* cleanup = ngx_pool_cleanup_add(req->pool, sizeof(TraceContext)); 
        
             TraceContext* context = (TraceContext*)cleanup->data; 
        
             new (context) TraceContext(req); 
        
             cleanup->handler = TraceContextCleanup; 
        
             std::unordered_map<ngx_http_request_t*, TraceContext*>* map; 
        
             if (req->parent) { 
        
               // Subrequests will already have the map created so just retrieve it 
        
               map = (std::unordered_map<ngx_http_request_t*, TraceContext*>*)val->data; 
        
             } else { 
        
               ngx_pool_cleanup_t* cleanup = ngx_pool_cleanup_add(req->pool, sizeof(std::unordered_map<ngx_http_request_t*, TraceContext*>)); 
        
               map = (std::unordered_map<ngx_http_request_t*, TraceContext*>*)cleanup->data; 
        
               new (map) std::unordered_map<ngx_http_request_t*, TraceContext*>(); 
        
               cleanup->handler = RequestContextMapCleanup; 
        
               val->data = (unsigned char*)cleanup->data; 
        
               val->len = sizeof(std::unordered_map<ngx_http_request_t*, TraceContext*>); 
        
             } 
        
             map->insert({req, context}); 
        
             return context; 
        
           }

#0  0x00007f7aa2425d6a in std::_Hashtable<ngx_http_request_s*, std::pair<ngx_http_request_s* const, TraceContext*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> >, std::__detail::_Select1st, std::equal_to<ngx_http_request_s*>, std::hash<ngx_http_request_s*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_bucket_index (this=0x0, __k=@0x7f7a968c5cb8: 0x7f7a9e3aaa30, __c=140164617382448) at /usr/include/c++/10.3.1/bits/hashtable.h:714
#1  0x00007f7aa2425f81 in std::_Hashtable<ngx_http_request_s*, std::pair<ngx_http_request_s* const, TraceContext*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> >, std::__detail::_Select1st, std::equal_to<ngx_http_request_s*>, std::hash<ngx_http_request_s*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_emplace<std::pair<ngx_http_request_s* const, TraceContext*> > (this=0x0) at /usr/include/c++/10.3.1/bits/hashtable.h:1711
#2  0x00007f7aa241eefa in std::__detail::_Insert<ngx_http_request_s*, std::pair<ngx_http_request_s* const, TraceContext*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> >, std::__detail::_Select1st, std::equal_to<ngx_http_request_s*>, std::hash<ngx_http_request_s*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, false>::insert<std::pair<ngx_http_request_s* const, TraceContext*>, void> (this=0x0, __v=...) at /usr/include/c++/10.3.1/bits/hashtable_policy.h:1021
#3  0x00007f7aa2418cac in std::unordered_map<ngx_http_request_s*, TraceContext*, std::hash<ngx_http_request_s*>, std::equal_to<ngx_http_request_s*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> > >::insert (this=0x0, __x=...) at /usr/include/c++/10.3.1/bits/unordered_map.h:587
#4  0x00007f7aa240c6cb in CreateTraceContext (req=0x7f7a9e3aaa30, val=0x7f7a968ee240) at /opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:402
#5  0x00007f7aa240c7c5 in StartNgxSpan (req=0x7f7a9e3aaa30) at /opentelemetry-cpp-contrib/instrumentation/nginx/src/otel_ngx_module.cpp:418
#6  0x000055ed6f3beac5 in ngx_http_core_rewrite_phase (r=0x7f7a9e3aaa30, ph=0x7f7a9e6a3088) at src/http/ngx_http_core_module.c:922
#7  0x000055ed6f3b9d49 in ngx_http_core_run_phases (r=0x7f7a9e3aaa30) at src/http/ngx_http_core_module.c:868
#8  0x000055ed6f3b9e1a in ngx_http_handler (r=<optimized out>) at src/http/ngx_http_core_module.c:851
#9  0x000055ed6f3c3a2c in ngx_http_run_posted_requests (c=c@entry=0x7f7a97434298) at src/http/ngx_http_request.c:2435
#10 0x000055ed6f3c6ebe in ngx_http_process_request_headers (rev=rev@entry=0x7f7a972b2670) at src/http/ngx_http_request.c:1529
#11 0x000055ed6f3c72b2 in ngx_http_process_request_line (rev=rev@entry=0x7f7a972b2670) at src/http/ngx_http_request.c:1175
#12 0x000055ed6f3c74e1 in ngx_http_wait_request_handler (rev=0x7f7a972b2670) at src/http/ngx_http_request.c:503
#13 0x000055ed6f3c78f9 in ngx_http_ssl_handshake_handler (c=0x7f7a97434298) at src/http/ngx_http_request.c:848
#14 0x000055ed6f3aeaa4 in ngx_ssl_handshake_handler (ev=0x7f7a972b2670) at src/event/ngx_event_openssl.c:2095
#15 0x000055ed6f3a9103 in ngx_epoll_process_events (cycle=0x7f7aa2cc8580, timer=<optimized out>, flags=<optimized out>) at src/event/modules/ngx_epoll_module.c:901
#16 0x000055ed6f39c140 in ngx_process_events_and_timers (cycle=cycle@entry=0x7f7aa2cc8580) at src/event/ngx_event.c:257
#17 0x000055ed6f3a67c8 in ngx_worker_process_cycle (cycle=0x7f7aa2cc8580, data=<optimized out>) at src/os/unix/ngx_process_cycle.c:753
#18 0x000055ed6f3a4850 in ngx_spawn_process (cycle=cycle@entry=0x7f7aa2cc8580, proc=proc@entry=0x55ed6f3a66bf <ngx_worker_process_cycle>, data=data@entry=0x0, name=name@entry=0x55ed6f4cbf97 "worker process",
    respawn=respawn@entry=-4) at src/os/unix/ngx_process.c:199
#19 0x000055ed6f3a549e in ngx_start_worker_processes (cycle=cycle@entry=0x7f7aa2cc8580, n=8, type=type@entry=-4) at src/os/unix/ngx_process_cycle.c:373
#20 0x000055ed6f3a7369 in ngx_master_process_cycle (cycle=0x7f7aa2cc8580, cycle@entry=0x7f7aa2ccd210) at src/os/unix/ngx_process_cycle.c:234
#21 0x000055ed6f379af9 in main (argc=<optimized out>, argv=<optimized out>) at src/core/nginx.c:386

Open Telemetry Alpine Image

Hello,

Is your feature request related to a problem?
I created a docker image to run opentelemetry with alpine.
I had to install its dependencies, compile nginx with --with-compat, opentelemetry-cpp and opentelemetry-cpp-contrib and the result image gets only 52MB

Describe the solution you'd like

I want to contribute with opentelemetry project to add alpine in the build pipeline:

https://hub.docker.com/r/iquirino91/nginx-opentelemetry
https://github.com/iquirino/nginx-opentelemetry/

In case of opentelemetry team gets interested on this, I am open to help and contribute to it.

Some concerns about nginx module

Hi Team, for the nginx instrumentation, i met some problems recently.
for my nginx.conf config:

location / {
        opentelemetry_operation_name $uri;
        opentelemetry_propagate;

       ……

because my app has some urls which contains regex: such as /a/b/{c:[0-9]+}, so i found in my jaeger UI, there are so many operations which may exceed the threshold. So I wonder whether any good suggestions for location aggregation? And do i need to add each location which contains regex? o(╥﹏╥)o

Ubuntu 20.10 has reached end-of-life and should not be used in the builds

Describe your environment
Ubuntu 20.10 has reached end-of-life and apt-get update will not run as-is anymore. The only reason it's still working in GitHub Actions is because of caching.

Steps to reproduce

FROM docker.io/library/ubuntu:20.10@sha256:a7b08558af07bcccca994b01e1c84f1d14a2156e0099fcf7fcf73f52d082791e
RUN apt-get update

Create a Dockerfile with the above content.
Try to build it.

$ DOCKER_BUILDKIT=1 docker build .
[+] Building 1.0s (5/5) FINISHED
 => [internal] load build definition from Dockerfile.ubuntu                                                                                                  0.0s
 => => transferring dockerfile: 177B                                                                                                                         0.0s
 => [internal] load .dockerignore                                                                                                                            0.0s
 => => transferring context: 34B                                                                                                                             0.0s
 => [internal] load metadata for docker.io/library/ubuntu:20.10@sha256:a7b08558af07bcccca994b01e1c84f1d14a2156e0099fcf7fcf73f52d082791e                      0.0s
 => CACHED [1/2] FROM docker.io/library/ubuntu:20.10@sha256:a7b08558af07bcccca994b01e1c84f1d14a2156e0099fcf7fcf73f52d082791e                                 0.0s
 => ERROR [2/2] RUN apt-get update                                                                                                                           0.8s
------
 > [2/2] RUN apt-get update:
#5 0.558 Ign:1 http://archive.ubuntu.com/ubuntu groovy InRelease
#5 0.558 Ign:2 http://security.ubuntu.com/ubuntu groovy-security InRelease
#5 0.587 Err:3 http://security.ubuntu.com/ubuntu groovy-security Release
#5 0.587   404  Not Found [IP: 91.189.88.152 80]
#5 0.587 Ign:4 http://archive.ubuntu.com/ubuntu groovy-updates InRelease
#5 0.623 Ign:5 http://archive.ubuntu.com/ubuntu groovy-backports InRelease
#5 0.662 Err:6 http://archive.ubuntu.com/ubuntu groovy Release
#5 0.662   404  Not Found [IP: 91.189.88.142 80]
#5 0.690 Err:7 http://archive.ubuntu.com/ubuntu groovy-updates Release
#5 0.690   404  Not Found [IP: 91.189.88.142 80]
#5 0.718 Err:8 http://archive.ubuntu.com/ubuntu groovy-backports Release
#5 0.718   404  Not Found [IP: 91.189.88.142 80]
#5 0.725 Reading package lists...
#5 0.744 E: The repository 'http://security.ubuntu.com/ubuntu groovy-security Release' does not have a Release file.
#5 0.744 E: The repository 'http://archive.ubuntu.com/ubuntu groovy Release' does not have a Release file.
#5 0.744 E: The repository 'http://archive.ubuntu.com/ubuntu groovy-updates Release' does not have a Release file.
#5 0.744 E: The repository 'http://archive.ubuntu.com/ubuntu groovy-backports Release' does not have a Release file.
------
executor failed running [/bin/sh -c apt-get update]: exit code: 100

What is the expected behavior?
GitHub Actions should be green and working in forks of this repository.

What is the actual behavior?
The builds are broken without caching. GitHub Actions work here because of caching.

Run cd instrumentation/nginx
  cd instrumentation/nginx
  docker buildx build -t otel-nginx-test/nginx \
    --build-arg image=$(echo ubuntu-20.10 | sed s/-/:/) \
    -f test/Dockerfile.ubuntu-20.10.stable \
    --cache-from type=local,src=/tmp/buildx-cache/nginx \
    --cache-to type=local,dest=/tmp/buildx-cache/nginx-new \
    --load \
    .
  shell: /usr/bin/bash -e {0}
#1 [internal] load build definition from Dockerfile.ubuntu-20.10.stable
#1 transferring dockerfile: 2.06kB 0.0s done
#1 DONE 0.0s

#2 [internal] load .dockerignore
#2 transferring context: 2B done
#2 DONE 0.0s

#3 [internal] load metadata for docker.io/library/ubuntu:20.10
#3 ...

#4 [auth] library/ubuntu:pull token for registry-1.docker.io
#4 DONE 0.0s

#3 [internal] load metadata for docker.io/library/ubuntu:20.10
#3 DONE 0.7s

#6 [build 1/8] FROM docker.io/library/ubuntu:20.10@sha256:a7b08558af07bcccca994b01e1c84f1d14a2156e0099fcf7fcf73f52d082791e
#6 resolve docker.io/library/ubuntu:20.10@sha256:a7b08558af07bcccca994b01e1c84f1d14a2156e0099fcf7fcf73f52d082791e done
#6 DONE 0.0s

#5 importing cache manifest from local:16937082270918477830
#5 DONE 0.0s

#7 [build 2/8] RUN apt-get update && DEBIAN_FRONTEND=noninteractive TZ="Europe/London"    apt-get install --no-install-recommends --no-install-suggests -y    nginx build-essential autoconf libtool pkg-config ca-certificates gcc g++ git libcurl4-openssl-dev libpcre3-dev gnupg2 lsb-release curl apt-transport-https software-properties-common zlib1g-dev cmake
#7 CACHED

Releases, versioning

How should we release different contrib projects?

nginx now (#10) builds release binaries for different platforms and I'd like expose these artifacts via Github releases.
Should each project have it's own version tag? E.g. nginx-0.1.0 and httpd-0.1.0 so when the tag is created a GH release will be available.

Nginx worker thread dies if log_subrequest is enabled

Describe your environment
I'm using the iquirino91/nginx-opentelemetry Docker image from @iquirino. See #81 and the Dockerfile here.

Steps to reproduce
The steps below assume you have Docker installed. If you do not, you are welcome to just use the nginx.conf with log_subrequest and try to reproduce the issue.

Create a new folder named bug and put the following files into it.

otel-nginx.toml

exporter = "otlp"
processor = "simple"

[exporters.otlp]
host = "otel"
port = 4317

[service]
name = "nginx-test-crash"

nginx.conf

load_module /etc/nginx/modules/otel_ngx_module.so;

worker_processes   auto;
error_log          /var/log/nginx/error.log debug;
working_directory  /tmp/cores/;
worker_rlimit_core 500M;

events {
}
http {
  opentelemetry_config /conf/otel-nginx.toml;
  log_subrequest on;

  server {
    opentelemetry on;
    listen 80;
    server_name otel_example;

    location = / {
      opentelemetry on;

      auth_request /auth;
    }

    location = /auth {
    }

  }
}

Run the following command in the bug folder with the files.

docker run \
    -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf \
    -v $(pwd)/otel-nginx.toml:/conf/otel-nginx.toml \
    -v $(pwd):/tmp/cores \
    --rm \
    --name nginx-otel-bug \
    iquirino91/nginx-opentelemetry@sha256:008914fd4d4aa8e060e14d7a2af56e48418d95832251473a8cffb5c348681703

In another terminal, exec into Nginx with docker exec -it nginx-otel-bug /bin/sh.

# apk add curl
# curl localhost:80

Observe the crash in your original terminal.

2021/12/23 11:38:08 [error] 8#0: *1 open() "/etc/nginx/html/auth" failed (2: No such file or directory), client: 127.0.0.1, server: otel_example, request: "GET / HTTP/1.1", subrequest: "/auth", host: "localhost"
127.0.0.1 - - [23/Dec/2021:11:38:08 +0000] "GET / HTTP/1.1" 404 0 "-" "curl/7.80.0"
2021/12/23 11:38:08 [error] 8#0: *1 auth request unexpected status: 404, client: 127.0.0.1, server: otel_example, request: "GET / HTTP/1.1", host: "localhost"
[Error] File: /opentelemetry-cpp/exporters/otlp/src/otlp_grpc_exporter.cc:132[OTLP TRACE GRPC Exporter] Export() failed: DNS resolution failed for service: otel:4317
127.0.0.1 - - [23/Dec/2021:11:38:08 +0000] "GET / HTTP/1.1" 500 177 "-" "curl/7.80.0"
2021/12/23 11:38:09 [notice] 1#0: signal 17 (SIGCHLD) received from 8
2021/12/23 11:38:09 [alert] 1#0: worker process 8 exited on signal 11
2021/12/23 11:38:09 [notice] 1#0: start worker process 62
2021/12/23 11:38:09 [notice] 1#0: signal 29 (SIGIO) received

We can use gdb to check the crash in the Nginx terminal. The dump should be /tmp/cores/core. You can also just use your system since /tmp/cores is mounted to the working directory so the core file should be on your local disk as well. The SetAttribute call in FinishNgxSpan is causing the crash.

# apk add gdb
# gdb /etc/nginx/nginx /tmp/cores/core
(gdb) bt
#0  0x00007fac054e69b1 in opentelemetry::v1::sdk::trace::Span::SetAttribute(opentelemetry::v1::nostd::string_view, absl::lts_20210324::variant<bool, int, long, unsigned int, double, char const*, opentelemetry::v1::nostd::string_view, opentelemetry::v1::nostd::span<bool const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<int const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<long const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<unsigned int const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<double const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<opentelemetry::v1::nostd::string_view const, 18446744073709551615ul>, unsigned long, opentelemetry::v1::nostd::span<unsigned long const, 18446744073709551615ul>, opentelemetry::v1::nostd::span<unsigned char const, 18446744073709551615ul> > const&) () from /etc/nginx/modules/otel_ngx_module.so
#1  0x00007fac054b9a5b in FinishNgxSpan(ngx_http_request_s*) () from /etc/nginx/modules/otel_ngx_module.so
#2  0x000055655d74482d in ngx_http_log_request (r=r@entry=0x7fac04a49370) at src/http/ngx_http_request.c:3753
#3  0x000055655d74613f in ngx_http_free_request (r=r@entry=0x7fac04a49370, rc=rc@entry=0) at src/http/ngx_http_request.c:3699
#4  0x000055655d746228 in ngx_http_close_request (r=r@entry=0x7fac04a49370, rc=rc@entry=0) at src/http/ngx_http_request.c:3645
#5  0x000055655d746c10 in ngx_http_finalize_connection (r=r@entry=0x7fac04a49370) at src/http/ngx_http_request.c:2788
#6  0x000055655d7474a7 in ngx_http_finalize_request (r=r@entry=0x7fac04a49370, rc=<optimized out>) at src/http/ngx_http_request.c:2661
#7  0x000055655d7471ad in ngx_http_finalize_request (r=r@entry=0x7fac04a49370, rc=500) at src/http/ngx_http_request.c:2547
#8  0x000055655d741a49 in ngx_http_core_access_phase (r=0x7fac04a49370, ph=0x7fac04a29b38) at src/http/ngx_http_core_module.c:1148
#9  0x000055655d73cf77 in ngx_http_core_run_phases (r=0x7fac04a49370) at src/http/ngx_http_core_module.c:875
#10 0x000055655d745e99 in ngx_http_run_posted_requests (c=c@entry=0x7fac04a035a0) at src/http/ngx_http_request.c:2450
#11 0x000055655d748536 in ngx_http_process_request_headers (rev=rev@entry=0x7fac049f6490) at src/http/ngx_http_request.c:1521
#12 0x000055655d7488ca in ngx_http_process_request_line (rev=rev@entry=0x7fac049f6490) at src/http/ngx_http_request.c:1165
#13 0x000055655d748a8c in ngx_http_wait_request_handler (rev=0x7fac049f6490) at src/http/ngx_http_request.c:503
#14 0x000055655d72f91a in ngx_epoll_process_events (cycle=<optimized out>, timer=<optimized out>, flags=<optimized out>) at src/event/modules/ngx_epoll_module.c:901
#15 0x000055655d725e6b in ngx_process_events_and_timers (cycle=cycle@entry=0x7fac0554b200) at src/event/ngx_event.c:247
#16 0x000055655d72dc2d in ngx_worker_process_cycle (cycle=0x7fac0554b200, data=<optimized out>) at src/os/unix/ngx_process_cycle.c:721
#17 0x000055655d72c290 in ngx_spawn_process (cycle=cycle@entry=0x7fac0554b200, proc=proc@entry=0x55655d72db52 <ngx_worker_process_cycle>, data=data@entry=0x0, name=name@entry=0x55655d7ab53d "worker process", respawn=respawn@entry=-3)
    at src/os/unix/ngx_process.c:199
#18 0x000055655d72ce7e in ngx_start_worker_processes (cycle=cycle@entry=0x7fac0554b200, n=8, type=type@entry=-3) at src/os/unix/ngx_process_cycle.c:344
#19 0x000055655d72e336 in ngx_master_process_cycle (cycle=cycle@entry=0x7fac0554b200) at src/os/unix/ngx_process_cycle.c:130
#20 0x000055655d70623d in main (argc=<optimized out>, argv=<optimized out>) at src/core/nginx.c:383

What is the expected behavior?
Using log_subrequest on; should not cause the worker thread to crash.

What is the actual behavior?
The worker thread crashes with log_subrequest on; in the Nginx configuration.

[instrumentation][otel-webserver-module] Support Code Coverage as a part of gradle task

Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem?
If so, provide a concise description of the problem.

Describe the solution you'd like
What do you want to happen instead? What is the expected behavior?

Describe alternatives you've considered
Which alternative solutions or features have you considered?

Additional context
Add any other context about the feature request here.

Create initial layout of directories

As we are going to create some examples in the contrib repo, and planning to put more projects here, let's create the initial directories layout.

Adding Unit Test for Request Processing Engine

Please assign this issue to me @DebajitDas

Segfault in GetTraceContext with named @healthcheck location

I am experiencing a reproducible crash in nginx workers when opentelemetry_propagate is set, and a @healthcheck named location is defined.

Removing either from the config avoids the crash.

On a fresh build from head, I've managed to catch the crash in gdb, with the following stack

#0  0x00007ffff46e862c in std::_Hashtable<ngx_http_request_s*, std::pair<ngx_http_request_s* const, TraceContext*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> >, std::__detail::_Select1st, std::equal_to<ngx_http_request_s*>, std::hash<ngx_http_request_s*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_bucket_index (this=0x0, __k=@0x7fffffffd8e8: 0x555555940d80, __c=93824996347264) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/hashtable.h:643
#1  0x00007ffff46e2288 in std::_Hashtable<ngx_http_request_s*, std::pair<ngx_http_request_s* const, TraceContext*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> >, std::__detail::_Select1st, std::equal_to<ngx_http_request_s*>, std::hash<ngx_http_request_s*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::find (this=0x0, __k=@0x7fffffffd8e8: 0x555555940d80) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/hashtable.h:1440
#2  0x00007ffff46dca09 in std::unordered_map<ngx_http_request_s*, TraceContext*, std::hash<ngx_http_request_s*>, std::equal_to<ngx_http_request_s*>, std::allocator<std::pair<ngx_http_request_s* const, TraceContext*> > >::find (this=0x0, __x=@0x7fffffffd8e8: 0x555555940d80)
    at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/unordered_map.h:921
#3  0x00007ffff46d07c5 in GetTraceContext (req=0x555555940d80)
    at /tmp/tmp.cDN5gHeZCb/.build/opentelemetry-nginx-prefix/src/opentelemetry-nginx/instrumentation/nginx/src/otel_ngx_module.cpp:182
#4  0x00007ffff46d08d9 in OtelGetTraceContextVar (req=0x555555940d80, v=0x555555941bb0, data=93824997472152)
    at /tmp/tmp.cDN5gHeZCb/.build/opentelemetry-nginx-prefix/src/opentelemetry-nginx/instrumentation/nginx/src/otel_ngx_module.cpp:202
#5  0x00005555555da1b1 in ngx_http_get_indexed_variable ()
#6  0x00005555555db1a1 in ngx_http_script_copy_var_len_code ()
#7  0x0000555555624dcd in ngx_http_proxy_create_request ()
#8  0x00005555555e46a3 in ngx_http_upstream_init_request ()
#9  0x00005555555d76e2 in ngx_http_read_client_request_body ()
#10 0x00005555556274fe in ngx_http_proxy_handler ()
#11 0x00005555556569d2 in ngx_http_upstream_hc_handler ()
#12 0x00005555555aab5d in ngx_event_expire_timers ()
#13 0x00005555555aa6b3 in ngx_process_events_and_timers ()
#14 0x00005555555b2471 in ngx_worker_process_cycle ()
#15 0x00005555555b0cdb in ngx_spawn_process ()
#16 0x00005555555b2860 in ngx_start_worker_processes ()
#17 0x00005555555b3243 in ngx_master_process_cycle ()
#18 0x0000555555586edd in main ()

Looking at the context in frame #3

(gdb) frame 3
#3  0x00007ffff46d07c5 in GetTraceContext (req=0x555555940d80)
    at /tmp/tmp.cDN5gHeZCb/.build/opentelemetry-nginx-prefix/src/opentelemetry-nginx/instrumentation/nginx/src/otel_ngx_module.cpp:182
182     in /tmp/tmp.cDN5gHeZCb/.build/opentelemetry-nginx-prefix/src/opentelemetry-nginx/instrumentation/nginx/src/otel_ngx_module.cpp
(gdb) info locals
val = 0x555555941a30
map = 0x0
it = {<std::__detail::_Node_iterator_base<std::pair<ngx_http_request_s* const, TraceContext*>, false>> = {_M_cur = 0x7fffffffddb8}, <No data fields>}

Looking at the calling code in otel_ngx_module.cpp

 std::unordered_map<ngx_http_request_t*, TraceContext*>* map = (std::unordered_map<ngx_http_request_t*, TraceContext*>*)val->data;
auto it = map->find(req);

It seems like the map has been deleted? (or never initialized?)

I'm not overly familiar with the nginx memory management API, and I'm not entirely certain what the 'right' fix is here. It would be relatively easy to paper over this particular error with a null check on the map, but it's not clear to me if there is some more fundamental problem that deserves a better fix

Consider uploading the modules outside of github actions artifacts?

Is your feature request related to a problem?

I'm trying to download a "stable" version of the module in a way that doesn't rely on some developer putting the .so file on their desktop machine & uploading it somewhere else; thought I could use your github build artifacts in our build process for that, but unfortunately, that doesn't work: You need a github OAuth app with actions:read scope to do that:

:;    curl https://api.github.com/repos/open-telemetry/opentelemetry-cpp-contrib/actions/artifacts/121064851/zip
{
  "message": "You must have the actions scope to download artifacts.",
  "documentation_url": "https://docs.github.com/rest/reference/actions#download-an-artifact"
}

Describe the solution you'd like
Ideally, there would be a release with attached binaries that I could use (-8

Describe alternatives you've considered

Outside of a release, maybe there's a way to host these artifacts somewhere else; I guess I could also download them into an S3 bucket (but then, again: The data would hit developer machines before being passed on...), or build the module from source.

otel.so not loaded in http - GLIBC_2.29' not found

httpd image from dockerhub (2.4.46)
Using release for ubuntu 20.04
Added it in proper modules place

Steps to reproduce
Add module in image and execute
What is the expected behavior?
Apache running and using the module

What is the actual behavior?

Cannot load /usr/lib/apache2/modules/mod-otel.so into server: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib/apache2/modules/mod-otel.so)

Additional context

Getting version mismatch while loading the module - `version 1018000 instead of 1019003`

Describe your environment

Using nginx 1.19.3 that comes with --with-compat

$ nginx -V                                                                                                                                                                                                                 [gke_hasura-lux_us-east1_prod-k8s-cluster/default]
nginx version: nginx/1.19.3
built by gcc 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
built with OpenSSL 1.1.1  11 Sep 2018
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.3/debian/debuild-base/nginx-1.19.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

I used the module otel_ngx_module-ubuntu-18.04-stable.so downloaded from https://github.com/open-telemetry/opentelemetry-cpp-contrib/actions/runs/705078540

OS Version:

Ubuntu 18.04.3 LTS

nginx.conf

  user  nginx;
  worker_processes  1;  
  
  error_log  /var/log/nginx/error.log warn;
  pid        /var/run/nginx.pid;
  
  load_module /etc/nginx/modules/otel_ngx_module.so;
  
  events {
      worker_connections  1024;
  }
  
  
  http {
      include       /etc/nginx/mime.types;
      default_type  application/octet-stream;
  
      log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for"';
  
      access_log  /var/log/nginx/access.log  main;
  
      sendfile        on;
      #tcp_nopush     on; 
  
      keepalive_timeout  65; 
  
      #gzip  on; 
  
      include /etc/nginx/conf.d/*.conf;
      include /etc/nginx/sites-enabled/*.conf;
  }

Error

$ sudo nginx -t                                                                                                                                                                                                            
nginx: [emerg] module "/etc/nginx/modules/otel_ngx_module.so" version 1018000 instead of 1019003 in /etc/nginx/nginx.conf:8
nginx: configuration file /etc/nginx/nginx.conf test failed

Steps to reproduce
Refer description

What is the expected behavior?

$ sudo nginx -t                                                                                                                                                                                                       
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

What is the actual behavior?

$ sudo nginx -t                                                                                                                                                                                                            
nginx: [emerg] module "/etc/nginx/modules/otel_ngx_module.so" version 1018000 instead of 1019003 in /etc/nginx/nginx.conf:8
nginx: configuration file /etc/nginx/nginx.conf test failed

Additional context
Add any other context about the problem here.

nginx: expose traceparent via nginx vars

Accessing traceparent in nginx scripts can be done via $otel_ctxvar_traceparent, but this was initially intended for internal use and could have a better name. Should create an alias and document its usage (e.g. adding Server-Timing headers).

Add support for b3multi

Is your feature request related to a problem?
Need support for b3-multi for nginx module. https://github.com/openzipkin/b3-propagation#multiple-headers

Describe the solution you'd like
Implement b3-multi in similar fashion like it is with simple b3 just do not concat trace-span-sampled into on header.

Right now header looks like

"B3": "2605e09e4efca19056beee12767f6287-426bf077362e8477-1",

for b3-multi there should be 3 headers

X-B3-TraceId: 2605e09e4efca19056beee12767f6287
X-B3-SpanId: 426bf077362e8477
X-B3-Sampled: 1

nginx no OTLPResourceNoServiceName

Describe your environment
The nginx instrumentation is not configuring a service name when using an otlp exporter.

Steps to reproduce
Run the module from main and look at the output in jaeger

What is the expected behavior?
The configured service name or at least unknown:nginx

What is the actual behavior?

OTLPResourceNoServiceName

Additional context

I tried to already resolve this here, but it seems to be a bug in the SDK. Opened open-telemetry/opentelemetry-cpp#765 to track this.

CMakeFiles/otel_ngx_module.dir/build.make:187: *** target pattern contains no `%'. Stop.

Hi, recently i need to work on the nginx instrument. i execute
cmake .. -DCMAKE_PREFIX_PATH=~/Software/opentelemetry-cpp-new/ -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl/

and the output as follow:

-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found opentelemetry-cpp: ~/Software/opentelemetry-cpp-new/include
-- Found Protobuf: /usr/local/lib/libprotobuf.a (found version "3.15.8")
-- Found ZLIB: /usr/local/lib/libz.dylib (found version "1.2.11")
-- Found OpenSSL: /usr/local/opt/openssl/lib/libcrypto.dylib (found version "1.1.1k")
-- Found c-ares: /usr/local/lib/cmake/c-ares/c-ares-config.cmake (found version "1.17.1")
-- Found RE2 via CMake.
-- nginx: using version 1.18.0
-- nginx: --with-compat enabled
-- Configuring done
-- Generating done
-- Build files have been written to: ~/Code/github/otel-nginx/build

but the error will fail me during make

[ 35%] No build step for 'project_nginx'
[ 41%] No install step for 'project_nginx'
[ 47%] Completed 'project_nginx'
[ 47%] Built target project_nginx
CMakeFiles/otel_ngx_module.dir/build.make:187: *** target pattern contains no `%'.  Stop.
make[1]: *** [CMakeFiles/otel_ngx_module.dir/all] Error 2
make: *** [all] Error 2

and i found the code in otel_ngx_module.dir/build.make:187 as follow:

otel_ngx_module.dylib: opentelemetry-cpp::version-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::common-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::trace-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::otlp_grpc_exporter-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::otlp_http_exporter-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::ostream_span_exporter-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::zpages-NOTFOUND
otel_ngx_module.dylib: opentelemetry-cpp::http_client_curl-NOTFOUND

i have installed the opentelemetry-cpp to my local directory(~/Software/opentelemetry-cpp-new) followed by https://github.com/open-telemetry/opentelemetry-cpp/blob/main/INSTALL.md

and i can find include and lib directories in my local directory.

could anyone help me? i am dying...

HTTP or GRPC in config

Describe your environment
I am compiling from the source

Should I compile two different versions, on with gRPC and another with HTTP?

-DWITH_OTLP_GRPC=ON
-DWITH_OTLP_HTTP=ON

In case of compile with gRPC and HTTP = ON, how could I select which to use? or it is not necessary to?

What is the expected behavior?
A selector of which protocol use

coredump when openresty ngx.location.capture is call

Describe your environment
Mac docker run openresty/openresty:alpine

Steps to reproduce
1.
compile the otel so into image
Dockerfile content

FROM openresty/openresty:alpine AS builder
ENV HTTP_PROXY=http://host.docker.internal:7890
ENV HTTPS_PROXY=http://host.docker.internal:7890
ENV OPENTELEMETRY_VERSION v1.2.0
RUN echo 'https://mirrors.ustc.edu.cn/alpine/v3.15/main' > /etc/apk/repositories \
    && echo 'https://mirrors.ustc.edu.cn/alpine/v3.15/community' >> /etc/apk/repositories\
    && apk update \
    && apk add --update git alpine-sdk build-base cmake linux-headers libressl-dev pcre-dev zlib-dev grpc-dev curl-dev protobuf-dev c-ares-dev re2-dev
RUN git clone --shallow-submodules --depth 1 --recurse-submodules -b ${OPENTELEMETRY_VERSION} \
      https://github.com/open-telemetry/opentelemetry-cpp.git \
      && cd opentelemetry-cpp \
      && mkdir build \
      && cd build \
      && cmake -DCMAKE_BUILD_TYPE=Debug \
        -DCMAKE_INSTALL_PREFIX=/install \
        -DCMAKE_PREFIX_PATH=/install \
        -DWITH_OTLP=ON \
        -DWITH_OTLP_GRPC=ON \
        -DWITH_OTLP_HTTP=OFF \
        -DBUILD_TESTING=OFF \
        -DWITH_EXAMPLES=OFF \
        -DWITH_ABSEIL=ON \
        -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
        .. \
      && make -j2 \
      && make install
RUN git clone https://github.com/open-telemetry/opentelemetry-cpp-contrib.git \
      && cd opentelemetry-cpp-contrib/instrumentation/nginx \
      && mkdir build \
      && cd build \
      && cmake -DCMAKE_BUILD_TYPE=Debug \
        -DNGINX_BIN=/usr/local/openresty/bin/openresty \
        -DCMAKE_PREFIX_PATH=/install \
        -DCMAKE_INSTALL_PREFIX=/usr/local/openresty/nginx/modules \
        -DCURL_LIBRARY=/usr/lib/libcurl.so.4 \
        .. \
      && make -j2 \
      && make install

FROM openresty/openresty:alpine

RUN echo 'https://mirrors.ustc.edu.cn/alpine/v3.15/main' > /etc/apk/repositories \
    && echo 'https://mirrors.ustc.edu.cn/alpine/v3.15/community' >> /etc/apk/repositories\
    && apk update \
    && apk add --update alpine-sdk build-base cmake linux-headers libressl-dev pcre-dev zlib-dev grpc-dev curl-dev protobuf-dev c-ares-dev re2-dev

COPY --from=builder /usr/local/openresty/nginx/modules/otel_ngx_module.so /usr/local/openresty/nginx/modules/otel_ngx_module.so

WORKDIR /usr/local/openresty

ENV PATH=$PATH:/usr/local/openresty/luajit/bin:/usr/local/openresty/nginx/sbin:/usr/local/openresty/bin

# Copy nginx configuration files

EXPOSE 9080 9443 80 8080

CMD ["/usr/local/openresty/bin/openresty", "-g", "daemon off;"]

STOPSIGNAL SIGQUIT

docker build -t openresty-otel:v1 .
docker run -it --privileged openresty-otel:v1
go into the container and change nginx.conf

load_module /usr/local/openresty/nginx/modules/otel_ngx_module.so;

and then add location

location = /test1 {
        access_by_lua '
                ngx.log(ngx.ERR, "========== go here ===============")
                ngx.print("this is lua")
                ngx.print(ngx.var.uri)
        ';
    }

    location = /test2 {
        access_by_lua '
        local key = ngx.var.http_user_agent
        local res = ngx.location.capture(
                "/test1", { args = { key = key } }
        )
        ngx.print(res.body)
        ';
    }

openresty -s reload
curl 127.0.0.1/test2 -iv , coredump

What is the expected behavior?
output normaly

What is the actual behavior?
2022/03/26 06:02:35 [alert] 1#1: worker process 229 exited on signal 11
2022/03/26 06:02:59 [alert] 1#1: worker process 234 exited on signal 11
2022/03/26 06:03:54 [alert] 1#1: worker process 242 exited on signal 11

Additional context
Add any other context about the problem here.

Error loading module in Nginx

Describe your environment
I am running Ubuntu 20.04 LTS Stable and I downloaded the latest stable release of OpenTelemetry nginx module from the Github Actions artificats section.

I am using "nginx:latest" in docker container. I am running "otel/opentelemetry-collector:latest" as well in docker container and both are started with Docker compose. All config files here https://gist.github.com/FullStackIndie/d3fd2234e34348226b696758ba7bdbba

Steps to reproduce
I use my docker compose up -d and my webserver(Nginx) crashes almost instantly with the error below.

What is the expected behavior?
I expect Nginx to load the open telemtry module for nginx properly so I can start tracing requests.

What is the actual behavior?
I keep getting an error everytime I nginx tries to laod the Module for open telemetry.

2022/02/22 06:03:46 [emerg] 1#1: dlopen() "/etc/nginx/modules/otel_ngx_module.so" failed (/etc/nginx/modules/otel_ngx_module.so: undefined symbol: pcre_exec) in /etc/nginx/nginx.conf:1

nginx: [emerg] dlopen() "/etc/nginx/modules/otel_ngx_module.so" failed (/etc/nginx/modules/otel_ngx_module.so: undefined symbol: pcre_exec) in /etc/nginx/nginx.conf:1**

Any help is greatly appreciated, thanks!!!

fluentd forward exporter

I would like to implement fluentd forward exporter for OpenTelemetry C++ SDK for the following modes:

Forward
PackedForward
CompressedPackedForward

Output for the following transports - fluentd inputs :

in_forward - The in_forward Input plugin listens to a TCP socket to receive the event stream. It also listens to a UDP socket to receive heartbeat messages. See also the protocol section for implementation details.
in_unix - The in_unix Input plugin enables Fluentd to retrieve records from the Unix Domain Socket. The wire protocol is the same as in_forward, but the transport layer is different.

I started initial work on it. The idea is we can build it as an optional community contribution for OpenTelemetry C++ SDK.

Features

One aspect of exporter that I'd like to cover is semantic convention of the fields. By default the field names for spans, events, attributes, etc. - would follow semantics agreed for the other JSON-alike exporters in OpenTelemetry. But it would be great to add some extensibility. Such as a concept of decorator or transformer that allows to customize the destination attributes. This way the exporter can be used for other vendor destinations, that may need custom field names, positions, and custom tree structure of the actual events carried within the forward protocol.

logging trace headers in apache 2.4

Describe your environment Describe any aspect of your environment relevant to the problem, including your platform, build system, version numbers of installed dependencies, etc. If you're reporting a problem with a specific version of a library in this repo, please check whether the problem has been fixed on main branch.
Running with apache httpd 2.4.51 (latest at the time of this writing), using mod_proxy to forward requests. Using the mod-otel 0.1.0 from here https://github.com/open-telemetry/opentelemetry-cpp-contrib/releases/download/httpd%2Fv0.1.0/ubuntu-18.04_mod-otel.so.zip

I tried logging the trace header with '%{traceparent}i' but got nothing (a dash/'-' which in apache-speak means "not found"). I assume this is because the header is added by mod-otel AFTER the logging tried to capture it.

Steps to reproduce
Using one of the example opentelemetry.conf configs (let's say using 'file' and letting traces go to stderr, i.e. error.log), make a request to my echoserver, which is behind a ProxyPass:

ProxyPass "/echoserver" "http://echoserver:8080" enablereuse=off

I see the headers coming back from the echo server:

traceparent=00-e2cb9baa8199a41e746be690a48d6da2-3e2a317ff7539e46-01
tracestate=

Adding to the LogFormat:

traceparent=%{traceparent}i

Gets me:

10.32.3.1 [2021-12-06T11:22:09.329888Z] "GET /echoserver HTTP/1.1" 200 14009 22ms xff=- ua="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0" traceparent=- gw=10.32.3.1 inBytes=2163 OutBytes=14009

I assume this is likely just the way it works and not a bug. If anyone has suggestions how to get the traceID logged, that would be fantastic.

What is the expected behavior?
I was hoping to see the traceparent header in the logs.

What is the actual behavior?
A dash for the header (which in apache means it was not found).

Additional context
Nothing comes to mind.

Reduce the build time of "docker-compose build" command

Currently, "docker-compose build" takes around 1 hr time to build the image. It would be better to reduce the build time of this.

CMake Warning at /usr/lib/cmake/grpc/modules/Findre2.cmake:64

This is related to kubernetes/ingress-nginx#8381
This problem blocked our attempt at building a new base image for the ingress-nginx project
As mentioned, building opentelemetry with alpine:3.14.X works but failed with alpine:3.15.X .

Steps to reproduce

clone https://github.com/kubernetes/ingress-nginx/
Run cd /images/opentelemetry/rootfs
run docker build -t myimage .

What is the expected behavior?

build should succeed

What is the actual behavior?

build fails

Additional context

The linked issue has the details

	TraceContext* CreateTraceContext(ngx_http_request_t* req, ngx_http_variable_value_t* val) {
	ngx_pool_cleanup_t* cleanup = ngx_pool_cleanup_add(req->pool, sizeof(TraceContext));
	TraceContext* context = (TraceContext*)cleanup->data;
	new (context) TraceContext(req);
	cleanup->handler = TraceContextCleanup;

	std::unordered_map<ngx_http_request_t, TraceContext>* map;
	if (req->parent) {
	// Subrequests will already have the map created so just retrieve it
	map = (std::unordered_map<ngx_http_request_t, TraceContext>*)val->data;
	} else {
	ngx_pool_cleanup_t* cleanup = ngx_pool_cleanup_add(req->pool, sizeof(std::unordered_map<ngx_http_request_t, TraceContext>));
	map = (std::unordered_map<ngx_http_request_t, TraceContext>*)cleanup->data;
	new (map) std::unordered_map<ngx_http_request_t, TraceContext>();
	cleanup->handler = RequestContextMapCleanup;
	val->data = (unsigned char*)cleanup->data;
	val->len = sizeof(std::unordered_map<ngx_http_request_t, TraceContext>);
	}
	map->insert({req, context});
	return context;
	}

open-telemetry / opentelemetry-cpp-contrib Goto Github PK

opentelemetry-cpp-contrib's Introduction

OpenTelemetry C++ Contrib

Contributing

Thanks to all the people who have contributed

Support

opentelemetry-cpp-contrib's People

Contributors

Stargazers

Watchers

Forkers

opentelemetry-cpp-contrib's Issues

Recommend Projects

Recommend Topics

Recommend Org