PHP Developer Experience Survey

[julianocosta89]

• differences from upstream spec:
  • discrepancies - why?
  • extra convenience
• most requested features
  • API
  • SDK
  • Instrumentations/semantic conventions
• things to consider from other telemetry projects

[julianocosta89]

@brettmc brought up a couple of interesting points in the extra convenience that we currently have for PHP:

• "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)

Also, for the most requested features, he pointed the following:

• 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]

Adding more context from Brett:

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: open-telemetry/opentelemetry-specification#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.

After discussing during Wed, 23 Oct SIG EU meeting, we agreed that only the local root span would make sense to be discussed in this SIG.

The Transport and Async export cases are more like implementation choices