Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a resource (semantic convention) to distinguish HTTP applications (http.app attribute) #335

Open
Oberon00 opened this issue Oct 24, 2019 · 8 comments
Labels
area:semantic-conventions Related to semantic conventions release:after-ga Not required before GA release, and not going to work on before GA semconv:HTTP spec:resource Related to the specification/resource directory

Comments

@Oberon00
Copy link
Member

Oberon00 commented Oct 24, 2019

See #263 (comment) and #263 (comment).

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)

@Oberon00
Copy link
Member Author

Oberon00 commented Mar 17, 2020

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

@Oberon00
Copy link
Member Author

Previous implementation: 9364357 (http.app span attribute), a8685ca (http.app_root).

@jmacd
Copy link
Contributor

jmacd commented Mar 18, 2020

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

@Oberon00
Copy link
Member Author

Oberon00 commented Mar 18, 2020

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

@pauldraper
Copy link

pauldraper commented Mar 28, 2020

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.

@Oberon00
Copy link
Member Author

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).

@Oberon00
Copy link
Member Author

This might be solvable by open-telemetry/oteps#78.

@fmhwong
Copy link

fmhwong commented Apr 17, 2020

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 open-telemetry/opentelemetry-java#1109. This can be done currently in OpenTracing. It is important to have this capability in OpenTelemetry 1.0.

@carlosalberto carlosalberto added the spec:resource Related to the specification/resource directory label Jun 30, 2020
@reyang reyang added the release:after-ga Not required before GA release, and not going to work on before GA label Jul 6, 2020
@Oberon00 Oberon00 changed the title Consider adding a resource (semantic convention) to distinguish HTTP applications Consider adding a resource (semantic convention) to distinguish HTTP applications (http.app attribute) May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions release:after-ga Not required before GA release, and not going to work on before GA semconv:HTTP spec:resource Related to the specification/resource directory
Projects
None yet
Development

No branches or pull requests

8 participants