googleapis / cloud-trace-nodejs Goto Github PK

• MongoDB
• MySQL
• Redis
• Restify
• Hapi
• Express (deferred render spans)
• Http

For people running on Compute Engine, it would be useful to be able to do filtering of the traces by VM. Right now the trace backend has no knowledge of which VM a particular trace was captured on. We should add this as a label on the traces. Once that is available, the UI can offer a way to filter by it. This issue only tracks the former.

We patch modules that may not be on the load path for the app running the agent (mongodb-core may not be on the load path if the app is using mongoose). We need to load these uniformly.

Since hooks are loaded on module load, they are not reinstrumented when agent start is called a second time.

This fails:

agent.start();
var http = require('http');
assert(http.request.__unwrap);
agent.stop();
assert(!http.request.__unwrap);
agent.start();
assert(http.request.__unwrap);
agent.stop();
assert(!http.request.__unwrap);

Stack traces are not being formatted according to the associated protobuf and are not rendered by the ui.

Hey guys, is there any plan to merge this with gcloud-node rather than a new library.

Also support for logging is required gcloud-logging

• time guarantee in addition to the presence guarantee

When sampling is enabled, we should only create span objects for the traces we record.

Run into this just now. Seems like we need a test for the path where we fail to get a project number. We need to completely disable the agent in such cases.

~/src/bookshelf2/bookshelf 2-structured-data
❯ node app.js
App listening at http://:::8080
ERROR:@google/cloud-trace: Unable to acquire the project number from metadata service. Please provide a valid project number as an env. variable, or through config.projectId passed to start().Error: Could not auto-discover project-id. Please export GCLOUD_PROJECT_NUM with your numeric project id
TypeError: Cannot read property 'bindEmitter' of null
    at middleware (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/@google/cloud-trace/lib/hooks/userspace/hook-express.js:40:12)
    at Layer.handle [as handle_request] (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:312:13)
    at /Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:280:7
    at Function.process_params (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:330:12)
    at next (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:271:10)
    at expressInit (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/middleware/init.js:33:5)
    at Layer.handle [as handle_request] (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:312:13)
    at /Users/ofrobots/src/bookshelf2/bookshelf/node_modules/express/lib/router/index.js:280:7

Some spans "escape" when mongo does periodic health checks and these should not be reported as errors. We should also further investigate mongo spans escaping in onconnection.

Add the label "trace.cloud.google.com/agent" with format " " for tracking.

Test for span quality and memory leaks

This will be used to retrieve the agent at points after it has been initialized with agent#start.

Currently JS objects are used the mirror the structure of the protobufs. Using the protobufs directly will remove this duplication.

Here are the tutorial instructions on deploying to GCE: https://cloud.google.com/nodejs/getting-started/run-on-compute-engine

1. Make sure everything works for trace (e.g. the right scopes are added when the VM is created)
2. Update the tutorial above to include instructions on how to enable trace.

Presently we are patching lazyRouter which is an internal interface. We should patch at the public API level. We are going to be prone to breakages even on point release of express if they change how the lazyRouter works.

Marking this as a bug because unless we fix this we can't be sure that the next patch-level release of express is going to work with us.

• Query/Update parameter
• Result Size? Results?

Ran the Bookshelf example app and put load on it with ab -n 1000000 -c 20 "${url}?pageToken=333". It stabilized at 100% cpu usage and 400MB (1.21%) of RAM.

@ofrobots How does this look?

See: #33 (comment)

We want to do version checks to make, e.g. that we are patching express v4+. The current mechanism of looking for internal properties that we know have been removed in v4 is a bit too brittle for my taste. It would be much better if we can figure out where the package.json for a loaded module is, and do a check against the version there.

It would be nice to be able to disable the trace agent without having to modify the source. I am thinking an env. var. named GCLOUD_TRACE_DISABLE, which if set, would cause the trace agent to not start.

Similarly, it would be nice to have an environment variable that increases the log-level for the trace agent.

A good starting point would be to research what kinds of throttling options the Java trace agent exposes.
See PercentageTraceEnablingPolicy.java, RateLimiterTraceEnablingPolicy.java, as starting points.

Add regression test for #82

This will also allow us to test against multiple versions of each framework.

Right now the test exits with success and the rest of the suite isn't run.

It would be nice to have options to allow the traces to be directed to a file and/or a logger instead of sending them to the Cloud Trace API.

The trace API expects the project Id to be a string, but does accept the numeric project Id. Users get a confusing error message when we try to post the traces to the API if they specific a numeric project Id as a number rather than a string.