[Survey] Developer Experience

[julianocosta89]

Hello all (@open-telemetry/php-approvers) 👋🏽

As I've briefly explained during the SIG Meeting, the DevEx SIG is running a survey with other SIGs, to collect feedback from the approvers and maintainers of each programming language. We are initially focus on the topics below, so we'd love to have your insights on it.

After we collect everyone's opinion, I'll sum this up in the DevEx repo: https://github.com/open-telemetry/sig-developer-experience/issues/10.

Regarding the point 1, what we are looking for are the things that are extra in PHP, which are not defined in the upstream spec.

Collecting this info would help us find spots to improve throughout the whole OTel project.

Feel free to link issues/discussions/docs and so on.

Survey

1. Differences from upstream spec:
   • discrepancies - why?
   • extra convenience
2. Most requested features
   • API
   • SDK
   • Instrumentations/semantic conventions
3. Things to consider from other telemetry projects

[brettmc]

@julianocosta89 I had a think and a look about our repo, and here's my first attempt:

1. Differences from upstream spec:

   • discrepancies - why?
   • ?
   • extra convenience
   • "local root span" access (not in spec, but concept borrowed from Java)
   • invented some env vars to control a few core things: batch/simple processor, select resource detectors
   • we generate metrics from our batch span/log processors. I believe Java does also, but I don't think we are consistent in the metric names
   • we implement a Transport concept, which abstracts the sending of telemetry data from the exporters (and the same transport, eg "http", can be used by multiple exporters (eg otlp and zipkin)

2. Most requested features

   • API
   • SDK
   • async exporting
   • a way to auto-close "dangling spans"
   • Instrumentations/semantic conventions
   • the moratorium on SemConv is really painful. A lot of our -contrib CI is red because packages are using since-deprecated semconvs, and we have a few user issues complaining about this

[julianocosta89]

Thank you for that @brettmc! I'll bring that up to the DevEx SIG.

LMK if anything else pops-up in yours or any other approver's head.

[julianocosta89]

Hey @brettmc quick questions that popped up.

When you say "local root span" access are we able to get it and modify it while it is not closed yet?

Also, could you elaborate a bit more on the Transport concept and the async export?

[brettmc]

Local root span: yes that's right. It's something like global access to the root-most span in the current context. We'd use it for things like updating the name of the root span after creation, or adding extra attributes. Related: https://github.com/open-telemetry/opentelemetry-specification/issues/2109

Transport: in otel PHP, Transport is an interface that exporters (zipkin and otlp) require. We have a couple of implementations: GrpcTransport, HttpTransport, StreamTransport. By abstracting the exporter from the transport, we can:

• use the same transport for traces/metrics/logs
• switch transports for an exporter to, for example, export otlp via grpc, http or to file.

Async export: this is just a PHP-specific issue. Since our batch processors are not async, they only export the next time a span ends after the configured delay has passed. In a quiet system, that could be some time.