-
Notifications
You must be signed in to change notification settings - Fork 539
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
fix: remove unuseful patch message from instrumentations #2161
Changes from 17 commits
8a85f1c
5351954
eba86f2
ab58270
9811baa
53a4811
203f82d
2b105cc
d3e00f2
182405f
e602c3b
5cf1a43
c547835
b3cf029
7a7f69f
628471d
3c5ca76
124d1aa
00e3416
ee1e0fa
4d5050c
855d264
f84890d
5b22de0
0aa2cfe
cccc9ba
4bb5e16
928fe6a
0ade21f
8185fbd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -164,3 +164,36 @@ To support this use case, you can choose one of the following options: | |
}; | ||
... | ||
``` | ||
|
||
## Diag Channel | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The diag channel can be used to troubleshoot issues with instrumentation packages. | ||
|
||
### Patching Messages | ||
|
||
When OpenTelemetry is installed in a user application, and expected spans are missing from generated traces, it is often useful to differentiate between the following scenarios: | ||
|
||
- The instrumentation is not auto loaded - due to issue with the require/import interception, an unsupported version of the instrumented package, or some other issue. This knowledge can pin-point the issue to the instrumentation package. | ||
- The instrumentation patch was applied but expected spans are missing - this can spot the light on the instrumented package logic, configuration, limits, otel sdk, or other issues. | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
It can also be useful to know when the instrumentation is loaded and patched, to understand the order of operations in the application. | ||
|
||
Instrumentation packages should use the `@opentelemetry/instrumentation` package `BaseInstrumentation` class to register patches and unpatch callbacks for specific require/import of the instrumented package, it's dependency or an internal module file. When this mechanism is used, the base class will automatically emit a debug message on instrumentation diag component logger, looking like this: | ||
|
||
```shell | ||
@opentelemetry/instrumentation-foo Applying instrumentation patch for module on require hook { | ||
module: 'foo', | ||
version: '1.2.3', | ||
baseDir: '<your directory>/node_modules/mongoose' | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
``` | ||
|
||
Instrumentation should not add additional debug messages for triggering the patching and unpatching callbacks, as the base class will handle this. | ||
|
||
Instrumentation may add additional patch/unpatch messages for specific functions if it is expected to help in troubleshooting issues with the instrumentation. Few examples: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, another thought I had that I think will probably be updated in the follow-up PR that replaces inconsistent usages of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. certainly, I aim to first remove or hoist unneeded diag messages, and then will transform all remaining diag message to use open-telemetry/opentelemetry-js#4663 will also help in hosting many diag prints and remove the repeated code from dozens of places in contrib. |
||
|
||
- If the patch logic is conditional, and user can benefit from ensuring the condition is met and the patch happened. `koa` patching logic examine an object and branch between patching it as router vs middleware, which is applied at runtime. `awslambda` will aboard patching if the environment is not configured properly. | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- When the patch is not applied directly on a `moduleExports` object in the `BaseInstrumentation` callbacks, but rather from an event in the package, like creating new client instance, registering a listener, etc. `fastify` instrumentation applies a patch when an hook is added to the fastify app instance, which is patched from `moduleExports`. | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- In situations where the patch logic is not trivial and it helps to specify patch events in the right context and nuances. `aws-lambda` logs additional properties extracted from the labmda framework and exposes them for troubleshooting. | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The cases above are not covered by the base class and offer additional context to the user trouble shooting an issue with the instrumentation. | ||
blumamir marked this conversation as resolved.
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤩 Love having this guideline written out here