open-telemetry / open-telemetry/opentelemetry-cpp-contrib

Httpd traces missing service name

Open
#82 7 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
153
Forks
184
Avg merge
2d 9h
Merged PRs (30d)
26

Description

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 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"
  1. In tempo, the traces seem to exist but show absolutely no data at all.
  2. 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 https://github.com/open-telemetry/opentelemetry-cpp/pull/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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with instrumentation/http/tests and the mod-otel 0.1.0 setup described in the report. Compare the generated OpenTelemetry output with the opentelemetry-cpp 1.0.0 change referenced by the issue, focusing on whether the service.name resource is sent. Done means traces contain data in Tempo and Jaeger reports the configured service name instead of OTLPResourceNoServiceName.

Written by the indexing model from the issue text.

Assessment

Tech stack
apache, cpp
Domain
observability-sre
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.