Replace instrumentation module/package instances with instrumentation library (#4727)
Signed-off-by: svrnm <neumanns@cisco.com> Co-authored-by: Piotr Kiełkowicz <pkiekowicz@splunk.com> Co-authored-by: Tiffany Hrabusa <30397949+tiffany76@users.noreply.github.com> Co-authored-by: opentelemetrybot <107717825+opentelemetrybot@users.noreply.github.com>
This commit is contained in:
		
							parent
							
								
									d711d33d3a
								
							
						
					
					
						commit
						6d6021a166
					
				| 
						 | 
				
			
			@ -158,3 +158,6 @@ rules:
 | 
			
		|||
      - ['screen[- ]shot(s)?', screenshot$1]
 | 
			
		||||
      - ['time[- ]stamp(s)?', timestamp$1]
 | 
			
		||||
      - ["uid['’]?(s)?", UID$1]
 | 
			
		||||
      # Enable the following to find and replace "instrumentation module/package" with "instrumentation library":
 | 
			
		||||
      # - ["(auto(matic)?[- ])?instrumentation (module|package)", "instrumentation library"]
 | 
			
		||||
      # - ["(auto(matic)?[- ])?instrumentation (modules|packages)", "instrumentation libraries"]
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -12,9 +12,9 @@ of the
 | 
			
		|||
[OpenTelemetry .NET Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation)
 | 
			
		||||
project!
 | 
			
		||||
 | 
			
		||||
Without this project, .NET developers need to use instrumentation packages to
 | 
			
		||||
Without this project, .NET developers need to use instrumentation libraries to
 | 
			
		||||
automatically generate telemetry data. For example, to instrument inbound
 | 
			
		||||
ASP.NET Core requests, you need to use the ASP.NET Core instrumentation package
 | 
			
		||||
ASP.NET Core requests, you need to use the ASP.NET Core instrumentation library
 | 
			
		||||
and initialize it with the OpenTelemetry SDK.
 | 
			
		||||
 | 
			
		||||
Now, developers can use
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -122,7 +122,7 @@ such as serverless, can import packages before the instrumentation code has a
 | 
			
		|||
chance to run. This can be easily missed.
 | 
			
		||||
 | 
			
		||||
To diagnose this issue, enable logging and verify you are seeing your
 | 
			
		||||
instrumentation package being loaded. For example:
 | 
			
		||||
instrumentation library being loaded. For example:
 | 
			
		||||
 | 
			
		||||
```nocode
 | 
			
		||||
@opentelemetry/instrumentation-http Applying patch for https@12.22.9
 | 
			
		||||
| 
						 | 
				
			
			@ -337,7 +337,7 @@ provider.shutdown();
 | 
			
		|||
## Package Versions Compatibility
 | 
			
		||||
 | 
			
		||||
Some issues can be a result of incompatible or old versions of SDK and
 | 
			
		||||
instrumentation packages.
 | 
			
		||||
instrumentation libraries.
 | 
			
		||||
 | 
			
		||||
### SDK versions
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -154,8 +154,8 @@ Additional suggestions:
 | 
			
		|||
 | 
			
		||||
- Start with dev or testing environments first to build trust in the software
 | 
			
		||||
- Choose a stack where OTel is more robust, such as Java and Node.js
 | 
			
		||||
- For countering developer resistance, using auto-instrumentation modules to
 | 
			
		||||
- start with is a good step
 | 
			
		||||
- For countering developer resistance, using automatic instrumentation to start
 | 
			
		||||
  with is a good step
 | 
			
		||||
 | 
			
		||||
#### 2 - Starting and scaling
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -275,7 +275,7 @@ any suggestions for improvement!
 | 
			
		|||
There is also a huge focus on
 | 
			
		||||
[stabilizing semantic conventions](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#),
 | 
			
		||||
and as part of that effort, maintainers plan to go through the existing
 | 
			
		||||
instrumentation packages and to make sure that they’re all up to date with the
 | 
			
		||||
instrumentation libraries and to make sure that they’re all up to date with the
 | 
			
		||||
latest conventions. While it’s very well-maintained for certain languages, such
 | 
			
		||||
as Java, that is not the case for other languages, such as Node.js.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -123,7 +123,7 @@ considerations to help you decide how to minimize dependency hell:
 | 
			
		|||
  package, so that will never cause issues for users who don't use it. You can
 | 
			
		||||
  keep it in your repository, or
 | 
			
		||||
  [add it to OpenTelemetry](https://github.com/open-telemetry/oteps/blob/main/text/0155-external-modules.md#contrib-components),
 | 
			
		||||
  so it will ship with other instrumentation packages.
 | 
			
		||||
  so it will ship with other instrumentation libraries.
 | 
			
		||||
- Semantic Conventions are [stable, but subject to evolution][]: while this does
 | 
			
		||||
  not cause any functional issues, you may need to update your instrumentation
 | 
			
		||||
  every once in a while. Having it in a preview plugin or in OpenTelemetry
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -87,8 +87,7 @@ and the package on [PyPi](https://pypi.org/project/opentelemetry-api/).
 | 
			
		|||
Change the entry point of your application by setting
 | 
			
		||||
`AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler` for Node.js or Java, and
 | 
			
		||||
`AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument` for Python. These wrapper scripts
 | 
			
		||||
will invoke your Lambda application with the auto instrumentation package
 | 
			
		||||
applied.
 | 
			
		||||
will invoke your Lambda application with the automatic instrumentation applied.
 | 
			
		||||
 | 
			
		||||
### Add the ARN of Instrumentation Lambda Layer
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -33,8 +33,8 @@ end
 | 
			
		|||
 | 
			
		||||
Where `{package}` is the name of the instrumentation.
 | 
			
		||||
 | 
			
		||||
Note that some instrumentation packages might have prerequisites. Check the
 | 
			
		||||
documentation of each instrumentation package for further instructions.
 | 
			
		||||
Note that some instrumentation libraries might have prerequisites. Check the
 | 
			
		||||
documentation of each instrumentation library for further instructions.
 | 
			
		||||
 | 
			
		||||
## Available instrumentation libraries
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -147,7 +147,7 @@ First, install the Node SDK and autoinstrumentations package.
 | 
			
		|||
The Node SDK lets you initialize OpenTelemetry with several configuration
 | 
			
		||||
defaults that are correct for the majority of use cases.
 | 
			
		||||
 | 
			
		||||
The `auto-instrumentations-node` package installs instrumentation packages that
 | 
			
		||||
The `auto-instrumentations-node` package installs instrumentation libraries that
 | 
			
		||||
will automatically create spans corresponding to code called in libraries. In
 | 
			
		||||
this case, it provides instrumentation for Express, letting the example app
 | 
			
		||||
automatically create spans for each incoming request.
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -59,7 +59,7 @@ npm install --save @opentelemetry/auto-instrumentations-web
 | 
			
		|||
{{% /tab %}} {{< /tabpane >}}
 | 
			
		||||
 | 
			
		||||
Note, that using those metapackages increases your dependency graph size. Use
 | 
			
		||||
individual instrumentation packages if you know exactly which ones you need.
 | 
			
		||||
individual instrumentation libraries if you know exactly which ones you need.
 | 
			
		||||
 | 
			
		||||
### Registration
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -32,7 +32,7 @@ creating a [TracerProvider](/docs/concepts/signals/traces/#tracer-provider).
 | 
			
		|||
## Note on Versioning
 | 
			
		||||
 | 
			
		||||
The Semantic Conventions (Standards) for attribute names are not currently
 | 
			
		||||
stable therefore the instrumentation package is currently not in a released
 | 
			
		||||
stable therefore the instrumentation library is currently not in a released
 | 
			
		||||
state. That doesn't mean that the functionality itself is not stable, only that
 | 
			
		||||
the names of some of the attributes may change in the future, some may be added,
 | 
			
		||||
some may be removed. This means that you need to use the `--prerelease` flag, or
 | 
			
		||||
| 
						 | 
				
			
			@ -51,7 +51,7 @@ dotnet add package OpenTelemetry.Extensions.Hosting
 | 
			
		|||
dotnet add package OpenTelemetry.Exporter.Console
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Then you can install the Instrumentation packages
 | 
			
		||||
Then you can install the instrumentation libraries:
 | 
			
		||||
 | 
			
		||||
```sh
 | 
			
		||||
dotnet add package OpenTelemetry.Instrumentation.AspNetCore --prerelease
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -142,7 +142,7 @@ Next, you’ll use the OpenTelemetry PHP extension to
 | 
			
		|||
     open-telemetry/opentelemetry-auto-slim
 | 
			
		||||
   ```
 | 
			
		||||
 | 
			
		||||
With the OpenTelemetry PHP extension set up and an auto-instrumentation package
 | 
			
		||||
With the OpenTelemetry PHP extension set up and an instrumentation library
 | 
			
		||||
installed, you can now run your application and generate some traces:
 | 
			
		||||
 | 
			
		||||
```sh
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -30,7 +30,7 @@ pip install opentelemetry-exporter-{exporter}
 | 
			
		|||
pip install opentelemetry-instrumentation-{instrumentation}
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
These are for exporter and instrumentation packages respectively. The Jaeger,
 | 
			
		||||
These are for exporter and instrumentation libraries respectively. The Jaeger,
 | 
			
		||||
Zipkin, Prometheus, OTLP and OpenCensus Exporters can be found in the
 | 
			
		||||
[exporter](https://github.com/open-telemetry/opentelemetry-python/blob/main/exporter/)
 | 
			
		||||
directory of the repository. Instrumentations and additional exporters can be
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -51,7 +51,7 @@ By default, all
 | 
			
		|||
[supported instrumentation libraries](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/metapackages/auto-instrumentations-node/README.md#supported-instrumentations)
 | 
			
		||||
are enabled, but you can use the environment variable
 | 
			
		||||
`OTEL_NODE_ENABLED_INSTRUMENTATIONS` to enable only certain instrumentations by
 | 
			
		||||
providing a comma-separated list of the instrumentation package names without
 | 
			
		||||
providing a comma-separated list of the instrumentation library names without
 | 
			
		||||
the `@opentelemetry/instrumentation-` prefix.
 | 
			
		||||
 | 
			
		||||
For example, to enable only
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -38,8 +38,8 @@ is the case-sensitive name of the instrumentation.
 | 
			
		|||
## Traces instrumentations
 | 
			
		||||
 | 
			
		||||
**Status**: [Mixed](/docs/specs/otel/versioning-and-stability). Traces are
 | 
			
		||||
stable, but particular instrumentation are in Experimental status due to lack of
 | 
			
		||||
stable semantic convention.
 | 
			
		||||
stable, but particular instrumentation libraries are in Experimental status due
 | 
			
		||||
to lack of stable semantic convention.
 | 
			
		||||
 | 
			
		||||
| ID                    | Instrumented library                                                                                                                                                                                               | Supported versions     | Instrumentation type | Status                                                    |
 | 
			
		||||
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------- | -------------------- | --------------------------------------------------------- |
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -42,14 +42,14 @@ dotnet add [<PROJECT>] package OpenTelemetry.AutoInstrumentation
 | 
			
		|||
 | 
			
		||||
If the application references packages that can be instrumented, but, require
 | 
			
		||||
other packages for the instrumentation to work the build will fail and prompt
 | 
			
		||||
you to either add the missing instrumentation package or to skip the
 | 
			
		||||
you to either add the missing instrumentation library or to skip the
 | 
			
		||||
instrumentation of the corresponding package:
 | 
			
		||||
 | 
			
		||||
```terminal
 | 
			
		||||
~packages/opentelemetry.autoinstrumentation.buildtasks/1.6.0/build/OpenTelemetry.AutoInstrumentation.BuildTasks.targets(29,5): error : OpenTelemetry.AutoInstrumentation: add a reference to the instrumentation package 'MongoDB.Driver.Core.Extensions.DiagnosticSources' version 1.4.0 or add 'MongoDB.Driver.Core' to the property 'SkippedInstrumentations' to suppress this error.
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
To resolve the error either add the recommended instrumentation package or skip
 | 
			
		||||
To resolve the error either add the recommended instrumentation library or skip
 | 
			
		||||
the instrumentation of the listed package by adding it to the
 | 
			
		||||
`SkippedInstrumentation` property, example:
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -31,8 +31,8 @@ example, if you already installed the `flask` package, running
 | 
			
		|||
`opentelemetry-instrumentation-flask` for you.
 | 
			
		||||
 | 
			
		||||
> **NOTE:** If you leave out `-a install`, the command will simply list out the
 | 
			
		||||
> recommended auto-instrumentation packages to be installed. More information
 | 
			
		||||
> can be found
 | 
			
		||||
> recommended instrumentation libraries to be installed. More information can be
 | 
			
		||||
> found
 | 
			
		||||
> [here](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/opentelemetry-instrumentation#opentelemetry-bootstrap).
 | 
			
		||||
 | 
			
		||||
## Configuring the agent
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -6,7 +6,7 @@ tags:
 | 
			
		|||
  - Node.js
 | 
			
		||||
  - fastify
 | 
			
		||||
license: Apache 2.0
 | 
			
		||||
description: OpenTelemetry fastify automatic instrumentation package
 | 
			
		||||
description: OpenTelemetry fastify automatic instrumentation library
 | 
			
		||||
authors:
 | 
			
		||||
  - name: OpenTelemetry Authors
 | 
			
		||||
urls:
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -7,7 +7,7 @@ tags:
 | 
			
		|||
  - instrumentation
 | 
			
		||||
  - nestjs
 | 
			
		||||
license: Apache 2.0
 | 
			
		||||
description: OpenTelemetry NestJS automatic instrumentation package
 | 
			
		||||
description: OpenTelemetry NestJS automatic instrumentation library
 | 
			
		||||
authors:
 | 
			
		||||
  - name: OpenTelemetry Authors
 | 
			
		||||
urls:
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue