opentelemetry-specification

opentelemetry-specification copied to clipboard

See https://github.com/open-telemetry/opentelemetry-specification/pull/263#issuecomment-544441748 and https://github.com/open-telemetry/opentelemetry-specification/pull/263#discussion_r329281769.

We should find a way to represent information about the HTTP application (proposed name semantic attribute name http.app) somewhere, ideally somewhere where for each incoming HTTP request a different application can be selected (even though the most common case is that of one app per process)

Currently there is already a spec on what an HTTP app is in the semantic conventions, but no way to represent it, see https://github.com/open-telemetry/opentelemetry-specification/blob/4ab7c2fb4964c14fe972b03b5bb6825573bafb24/specification/data-http.md#http-server-definitions:

Within a single virtual host, some servers support the concepts of an HTTP application (for example in Java, the Servlet JSR defines an application as "a collection of servlets, HTML pages, classes, and other resources that make up a complete application on a Web server" -- SRV.9 in JSR 53; in a deployment of a Python application to Apache, the application would be the PEP 3333 conformant callable that is configured using the WSGIScriptAlias directive of mod_wsgi).

An application can be "mounted" under some application root (also know as context root context prefix, or document base) which is a fixed path prefix of the URL that determines to which application a request is routed (e.g., the server could be configured to route all requests that go to an URL path starting with /webshop/ at a particular virtual host to the com.example.webshop web application).

We also need to hash out differences to the service Resource https://github.com/open-telemetry/opentelemetry-specification/blob/4ab7c2fb4964c14fe972b03b5bb6825573bafb24/specification/data-resource-semantic-conventions.md#service

Previous implementation: https://github.com/open-telemetry/opentelemetry-specification/pull/263/commits/93643578c22b8b35d581551ddb62575391011ec9 (http.app span attribute), https://github.com/open-telemetry/opentelemetry-specification/pull/263/commits/a8685ca058a464c95bf67c261627d231b55b070c (http.app_root).

The use-case where a single application is mounted on multiple (virtual host, root path) pairs seems pretty obscure to me, but not unreasonable.

Agree, I also had that thought when re-reading the spec quoted above. But I think that's a minor detail here.

service.name doesn't imply process-level isolation, just the logical name of a service.

Logical name of the service. MUST be the same for all instances of horizontally scaled services.

Is there anything unique to HTTP? What about RPC processes, AMQP processes, etc.

The initial problem here is not that service.name in particular would imply process-level isolation, but that the Resource concept itself allows only one resource per process (technically per TracerProvider, but usually there is at least one static/global variable that references this, so it's effectively per process).

This might be solvable by https://github.com/open-telemetry/oteps/issues/78.

In some application servers, you can run multiple applications. We need a way to separate spans created by them and properly export them as multiple services. See https://github.com/open-telemetry/opentelemetry-java/issues/1109. This can be done currently in OpenTracing. It is important to have this capability in OpenTelemetry 1.0.