Skip to content

Conversation

@trentm
Copy link
Member

@trentm trentm commented Oct 6, 2023

This refactors how module patch handlers are loaded and the Instrumentation class file. There is now a PatcherRegistry that is a little smarter than the _patches object before it.

The main change is that we now use RITM's internals:true option so that our onRequire hook is called with module sub-paths. This will allow #3657 to hook both "mongodb" and "mongodb/lib/cmap/connection_pool.js", and avoid a RITM bug where "mongodb" &
"mongodb/lib/cmap/connection_pool" (no extension, indicating a "sub-module") don't work together.

Benefits and other changes:

  • With the smarter "PatcherRegistry" the module name can be used in disableInstrumentations to disable any patchers for that module. E.g. disableInstrumentations=next will disable all four next-related patchers.
  • A custom "lambda" name is now usable to disable the Lambda instr, FWIW.
  • (Note: we could also add custom disableInstrumentations keys for other modules, e.g. perhaps "aws-sdk" for all those.)
  • Some edge cases with the (rare, and undocumented) config.addPatch config var have been cleaned up.
  • Loading of the lambda-handler has been refactored a bit to no longer need to know internal details of the instrumentation module.

Refs: #3657
Closes: #2992

This refactors how module patch handlers are loaded and the
Instrumentation class file. There is now a PatcherRegistry that is
a little smarter than the `_patches` object before it.

The main change is that we now use RITM's internals:true option
so that our `onRequire` hook is called with module sub-paths. This will
allow #3657 to hook both "mongodb" and "mongodb/lib/cmap/connection_pool.js",
and avoid a RITM bug where "mongodb" &
"mongodb/lib/cmap/connection_pool" (no extension, indicating a
"sub-module") don't work together.

Benefits and other changes:
- With the smarter "PatcherRegistry" the module name can be used in
  `disableInstrumentations` to disable any patchers for that module.
  E.g. `disableInstrumentations=next` will disable all four
  `next`-related patchers.
- A custom "lambda" name is now usable to disable the Lambda instr,
  FWIW.
- (Note: we *could* also add custom disableInstrumentations keys for
  other modules, e.g. perhaps "aws-sdk" for all those.)
- Some edge cases with the (rare, and undocumented) `config.addPatch`
  config var have been cleaned up.
- Loading of the lambda-handler has been refactored a bit to no longer
  need to know internal details of the instrumentation module.

Refs: #3657
Closes: #2992
@trentm trentm requested a review from david-luna October 6, 2023 23:24
@trentm trentm self-assigned this Oct 6, 2023
@github-actions github-actions bot added the agent-nodejs Make available for APM Agents project planning. label Oct 6, 2023
david-luna
david-luna previously approved these changes Oct 9, 2023
@david-luna
Copy link
Member

Looks good. I'm leaving already the approval so you can merge when you finish the the caching of module versions

@trentm trentm merged commit 1eae1b5 into main Oct 11, 2023
@trentm trentm deleted the trentm/instr-refactor branch October 11, 2023 16:34
PeterEinberger pushed a commit to fpm-git/apm-agent-nodejs that referenced this pull request Aug 20, 2024
…ic#3658)

This refactors how module patch handlers are loaded and the
Instrumentation class file. There is now a PatcherRegistry that is
a little smarter than the `_patches` object before it.

The main change is that we now use RITM's internals:true option
so that our `onRequire` hook is called with module sub-paths. This will
allow elastic#3657 to hook both "mongodb" and "mongodb/lib/cmap/connection_pool.js",
and avoid a RITM bug where "mongodb" &
"mongodb/lib/cmap/connection_pool" (no extension, indicating a
"sub-module") don't work together.

Benefits and other changes:
- With the smarter "PatcherRegistry" the module name can be used in
  `disableInstrumentations` to disable any patchers for that module.
  E.g. `disableInstrumentations=next` will disable all four
  `next`-related patchers.
- A custom "lambda" name is now usable to disable the Lambda instr,
  FWIW.
- (Note: we *could* also add custom disableInstrumentations keys for
  other modules, e.g. perhaps "aws-sdk" for all those.)
- Some edge cases with the (rare, and undocumented) `config.addPatch`
  config var have been cleaned up.
- Loading of the lambda-handler has been refactored a bit to no longer
  need to know internal details of the instrumentation module.

Refs: elastic#3657
Closes: elastic#2992
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agent-nodejs Make available for APM Agents project planning.

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Allow Logical Grouping of Instrumentation by Name

3 participants