wdalmut/opentelemetry-plugin-mongoose

OpenTelemetry Mongoose Plugin

Just a mongoose plugin for opentelemetry

Installation

npm install --save @wdalmut/opentelemetry-plugin-mongoose

Usage

const provider = new NodeTracerProvider({
  plugins: {
    mongoose: {
      enabled: true,
      path: '@wdalmut/opentelemetry-plugin-mongoose',
    },
  }
});

Status

This project is in alpha state. Do not use in production if your are not sure about what are you doing...

opentelemetry-plugin-mongoose's Issues

Span placement and timing error

Collection information is wrong

Currently the span property db.collection expose the string collection instead of the collection name (tested with find operation)

Prepare a better test suite base

I need few base things

• initial database fixtures (few initial already inserted models, etc.)
• Unique indexes to generate errors
• Add jasmine span matcher
• Test attributes attachments
• Test error generations (uniquiness for example)

Add correct tracking information for all methods

Need test case and verification for every mongoose middleware

• save
• remove
• updateOne
• deleteOne
• count
• countDocuments
• estimatedDocumentCount
• deleteMany
• deleteOne
• find
• findOne
• findOneAndDelete
• findOneAndRemove
• findOneAndUpdate
• update
• updateMany

Others?

cannot install v0.2.1 with npm/yarn

When executing npm install --save @wdalmut/opentelemetry-plugin-mongoose I get this error:

> @wdalmut/[email protected] postinstall /Users/amirblum/repos/mongoose-test/node_modules/@wdalmut/opentelemetry-plugin-mongoose
> npm run build


> @wdalmut/[email protected] build /Users/amirblum/repos/mongoose-test/node_modules/@wdalmut/opentelemetry-plugin-mongoose
> tsc

Version 3.8.3
Syntax:   tsc [options] [file...]

Examples: tsc hello.ts
          tsc --outFile file.js file.ts
          tsc @args.txt
          tsc --build tsconfig.json


...

Operation `remove` handle `callback` structure (like `save`)

Promise.all structures produce unlinked spans

If i use a structure like

Promise.all([
  ModelName
  .find(where)
  .skip(0)
  .limit(25)
  .sort({ fieldName: 'asc' }),
  ModelName.countDocuments(where)
])

Spans are correctly generated but not linked with main root span (appears as two separated spans).

Database OpenTelemetry specification conventions

We have to check that we are respecting OpenTelemetry specification for databases: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/overview.md#semantic-conventions.md

Added code coverage with codecov

"Incomplete: No specs found" when running tests

I cloned the project, then npm install and npm run test.
Got output:

➜  opentelemetry-plugin-mongoose git:(master) npm run test

> @wdalmut/[email protected] test /Users/amirblum/repos/opentelemetry-plugin-mongoose
> node --no-deprecation ./node_modules/jasmine/bin/jasmine.js

Randomized with seed 96266
Started


No specs found
Finished in 0.003 seconds
Incomplete: No specs found
Randomized with seed 96266 (jasmine --random=true --seed=96266)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @wdalmut/[email protected] test: `node --no-deprecation ./node_modules/jasmine/bin/jasmine.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @wdalmut/[email protected] test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/amirblum/.npm/_logs/2020-05-20T15_30_26_325Z-debug.log

Enable attribute DB_MODEL on DEBUG

Currently we append DB_MODEL (query results) for every query... Results should not be appended to the tracking (too much details and effort)

you could replace that by `thisPlugin._tracer.bind(this._otContext, originalThen)` (interally it does almost the same but it would be clearer for you i think)

you could replace that by thisPlugin._tracer.bind(this._otContext, originalThen) (interally it does almost the same but it would be clearer for you i think)

Originally posted by @vmarchaud in https://github.com/wdalmut/opentelemetry-plugin-mongoose/pull/34/files/4974498d305857fcbe8829f9c0253d45e4387dee

Integrate as OpenTelemetry plugin

Integrate in the plugin registry (https://opentelemetry.io/get-involved/#registry)

Method `Model.create` fails with error

If we use the method Model.create the library breaks the flow

ModelName.create({/** payload */}).then(/** logic */)

Integrate CI/CD with travis-ci

Just integrate CI/CD with travis-ci

• integrate build spec
• integrate build status in README

Handle unwrap methods

We have to handle the unwrap methods that currently are not managed (because of #8 we have to unwrap all methods...)

[Question] Trace aggregate

Does this plugin support tracing of aggregate queries?

I have noticed that it is not included on the filter in https://github.com/wdalmut/opentelemetry-plugin-mongoose/blob/master/src/mongoose.ts#L11-L26

compilation errors in tests with latest mongoose version

The mongoose dependencies are set in package.json as

  "devDependencies": {
    ....
    "@types/mongoose": "^5.7.8",
    "mongoose": "^5.9.7",
    ....
  }

On my setup it, using yarn and the latest versions of the packages, it installs:

    "name": "@types/mongoose",
    "version": "5.10.3",

and

  "name": "mongoose",
  "version": "5.11.7",

which fails yarn test due to many compilation errors.

Model save add test suite with callbacks

Model save/create do not trace the request input data

Currently in our span there are no information about the structure stored (AttributeNames.DB_STATEMENT)

Using with express async-await controller creates unlinked spans

Hey! First thing, thanks for taking the time and effort for creating this plugin.

I noticed using async-await on the query does not link the mongoose span with the express span unless the query is executed with exec().

Here are some example:

Using then() - Links correctly

app.get('/mongo-then', (_req, res) => {
  userCollection.findOne({}).then((u) => res.status(200).send(u));
});

Using async-await with exec - Links correctly

app.get('/mongo-exec', async (_req, res) => {
  const user = await userCollection.findOne({}).exec();
  res.status(200).send(user);
});

---

Using async-await - Created 2 separate spans

• 1 span called get /mongo-async-await.
• 1 span called mongoose.users.findOne.

app.get('/mongo-async-await', async (_req, res) => {
  const u = await userCollection.findOne({});
  res.status(200).send(u);
});

Zipkin Screenshot:

---

I'm using TypeScript, attaching my set up for reference:
Typescript version: 3.8.3
tsconfig:

{
    "compilerOptions": {
        "target": "ES2017",
        "lib": ["ES2019", "DOM"],
        "rootDir": "lib",
        "outDir": "dist",
        "module": "commonjs",
        "moduleResolution": "node",
        "strict": false,
        "declaration": true,
        "sourceMap": true,
        "inlineSources": true,
        "types": ["node"],
        "allowSyntheticDefaultImports": true,
        "esModuleInterop": true
    }
}

api v0.13.0

In know this plugin is in the process of migrating to the contrib repo, but I'll ask here since I'm not sure when it will be available there.

This plugin is currently using dependency

    "@opentelemetry/api": "^0.6.0",
    "@opentelemetry/core": "^0.6.0"

Which are quite old (released on Apr 2).
It looks like v0.13.0 had breaking changes which broke the async context propagation somehow. This line no longer works in v0.13.0.
It's kind of strange, as the plugin should install it's own version of the api / tracing packages to node_modules, but somehow it doesn't work after upgrading from v0.12.0 to v0.13.0.

In additional, the Span status code has changed in a non-backward compatible way, which means plugins using api version of <0.12.0 will use the old GRPC CanonicalCode enum and thus report wrong value with exporter Collector.

Was wondering what your plans are for supporting v0.13.0.
I can create a PR here to fix the issues if you like and willing to review and publish new plugin verison. Or do you plan to do further releases from the contrib repo? (the review-publish cycle there can take many many weeks in my experience).
We are blocked on this issue currently and not able to upgrade to otel latest.

Add connection information and other collection related structures

Add at least those information

• collection name
• database name
• db connection info (host, user, port)

Wrap Model methods with shimmer

Because of #4 we have to wrap every model method to connect the request with the response.

Probably it is possible to handle also #1

• save
• find
• findOne