Adding webengine definition under resources semantic conventions (#1293)

This commit is contained in:
ivomagi 2021-04-01 17:29:36 +03:00 committed by GitHub
parent c94d2d1498
commit 4aa113a9f1
3 changed files with 45 additions and 0 deletions

View File

@ -0,0 +1,22 @@
groups:
- id: webengine_resource
prefix: webengine
brief: >
Resource describing the packaged software running the application code. Web engines are typically executed using process.runtime.
attributes:
- id: name
type: string
required: always
brief: >
The name of the web engine.
examples: ['WildFly']
- id: version
type: string
brief: >
The version of the web engine.
examples: ['21.0.0']
- id: description
type: string
brief: >
Additional description of the web engine (e.g. detailed version and edition information).
examples: ['WildFly Full 21.0.0.Final (WildFly Core 13.0.1.Final) - 2.2.2.Final']

View File

@ -124,6 +124,7 @@ Attributes defining a compute unit (e.g. Container, Process, Function as a Servi
- [Container](./container.md)
- [Function as a Service](./faas.md)
- [Process](./process.md)
- [Web engine](./webengine.md)
## Compute Instance

View File

@ -0,0 +1,22 @@
# Webengine
**type:** `webengine`
**Description:** Resource describing the packaged software running the application code. Web engines are typically executed using process.runtime.
<!-- semconv webengine_resource -->
| Attribute | Type | Description | Examples | Required |
|---|---|---|---|---|
| `webengine.name` | string | The name of the web engine. | `WildFly` | Yes |
| `webengine.version` | string | The version of the web engine. | `21.0.0` | No |
| `webengine.description` | string | Additional description of the web engine (e.g. detailed version and edition information). | `WildFly Full 21.0.0.Final (WildFly Core 13.0.1.Final) - 2.2.2.Final` | No |
<!-- endsemconv -->
Information describing the web engine SHOULD be captured using the values acquired from the API provided by the web engine, preferably during runtime, to avoid maintenance burden on engine version upgrades. As an example - Java engines are often but not always packaged as application servers. For Java application servers supporting Servlet API the required information MAY be captured by invoking `ServletContext.getServerInfo()` during runtime and parsing the result.
A resource can be attributed to at most one web engine.
The situations where there are multiple candidates, it is up to instrumentation library authors to choose the web engine. To illustrate, let's look at a Python application using Apache HTTP Server with mod_wsgi as the server and Django as the web framework. In this situation:
* Either Apache HTTP Server or `mod_wsgi` MAY be chosen as `webengine`, depending on the decision made by the instrumentation authors.
* Django SHOULD NOT be set as an `webengine` as the required information is already available in insrumentation library and setting this into `webengine` would duplicate the information.