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

Possibility to support Application in Resource Conventions #1410

Open
wdengw opened this issue Feb 9, 2021 · 4 comments
Open

Possibility to support Application in Resource Conventions #1410

wdengw opened this issue Feb 9, 2021 · 4 comments
Labels
spec:resource Related to the specification/resource directory

Comments

@wdengw
Copy link

wdengw commented Feb 9, 2021

What are you trying to achieve?
Many Java web applications host multiple services. For example, a SpringBoot application can have multiple RestController components, each RestController is a Rest Service. A SpringBoot application usually starts as a JVM process. The OpenTelemetry Log Data model has semantic resource attributes for Service, like service.name, service version, etc. It also has semantic resource attributes for processes, like process.pid, process.command, etc. However, it is lacking the application resource to associate services with the processes. The basic attributes that application resources should have includes: the application’s id, the application’s version, and the application’s group id.

What did you expect to see?
Should we consider to add application as a resource in OpenTelemtry’s Resource Semantic Conventions?
Additional context.

@wdengw wdengw added the spec:resource Related to the specification/resource directory label Feb 9, 2021
@Oberon00
Copy link
Member

Oberon00 commented Feb 9, 2021

Many Java web applications host multiple services.

I think the technology in OTel might be reversed. The service would be the whole running entity that is instrumented with OTel. The application would be something running inside that service. See also #335

@wdengw
Copy link
Author

wdengw commented Feb 10, 2021

@Oberon00 Are you suggesting to consider this springboot application as a HTTP server inside HTTP Service? There are a couple of concerns with this approach:

  1. The HTTP Server has no attribute to capture the version, and the groupId of this built springboot artifact;
  2. The real problem is from developer's point of view, this springboot app is key entity of their focus for observability. The use case documented in this issue is multiple services components, it would be multiple other componenets, for example, message consumers. The springboot application (or its built deployment artifact with artifactId, groupId, and version) is their deployment unit. Wrapping this important resources deep inside another HTTP service as HTTP server is not a favorable solution in my opinion.

@iNikem
Copy link
Contributor

iNikem commented Feb 10, 2021

@wdengw Spring Boot is only of the possible deployment models. If you want to bring the notion of the application into spec, you have to consider other models as well. From the top of my head:

  • Several war files deployed to Java application server like
  • Several hosts defined Apache httpd or Nginx

In general the relation between "process" and "application" is at least "one to many"

@wdengw
Copy link
Author

wdengw commented Feb 16, 2021

@iNikem you are right, SpringBoot is just one each example, there are many other possible deployment models for developer to deploy their application. Like what you pointed out, the key is that we deploy applications to deployment environment and applications are what we monitoring. Therefore, Application is a key resource to be considered.

And yes, the relation between "process" and "application" is at least "one to many", and in addition, the relation between "application" and "service" is also at least "one to many".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:resource Related to the specification/resource directory
Projects
None yet
Development

No branches or pull requests

3 participants