Is there a way to get only some of the enhanced database reporting?

[evanlucas]

In the pg plugin, the query and the values are added to the span only if enhanced database reporting is enabled. (https://github.com/GoogleCloudPlatform/cloud-trace-nodejs/blob/master/src/plugins/plugin-pg.js#L36-L41). While we would like to have the queries reported, reporting the values and rows from the response could end up being a little too much information (think of changing a password or access token).

Is there a way around this without manually patching pg and disabling the experimental plugin?

Thanks!

[matthewloring]

There is not currently a way to print queries/values without database results. I see a few possible ways to remedy this:

1. We could determine that queries are not sensitive and remove them from being gated behind enhancedDatabaseReporting. I think this may be too simplistic and will not cover similar use cases for non-database plugins.

2. We could have a notion of sensitivity levels (similar to log levels) that would allow labels to be added at a particular privacy level. I'm not aware of other apis with this functionality so it could be unintuitive. It may also be restrictive to impose a global privacy level on all plugins (maybe you want queries and values for redis but not pg).

3. We could accept a list of allowed labels at configuration time for each plugin and only report data associated with allowed labels. This would address the issue at hand but it could be difficult to determine the set of possible label names for a particular plugin. It would also be brittle to plugin changes that modify label names or add new ones.

4. We could allow plugins to specify their own arbitrary configuration that users of the trace agent could provide when they specify plugins. This would complicate the configuration process but would offer the most flexibility.

Do you have any other ideas or thoughts on these approaches?

[evanlucas]

Personally, I think 4 is going to be the way to go. We will always want errors, queries, and rowCount, but not parameters or output. I guess the hard part would be how to enable/change configuration at the environment level. Would that mean that they have to be passed to the plugin? Seems like that would be a backwards-incompatible change with how the plugin format is currently { name: file }?

[kjin]

I also like (4), because it opens the door to other fields that can passed to a single plugin. We discussed this in the past for limiting label sizes. While it would complicate the interface, I think we can avoid a backward-incompatible change by checking the value type (either string or now also object)? Which makes it, to me, the option with the smallest downside.

[kjin]

#826 adds a getConfig option on the Tracer object which can allow plugins to access the entire, normalized config object. While this doesn't directly add support for multiple levels of database reporting, this makes it possible for a fork of a given plugin to read arbitrary values as set from the user-provided configuration object.

Apologies for the delay here -- we should have acted sooner on this.