microsoft / vscode-extension-telemetry

Node module to help VS Code extensions send telemetry using application insights

@vscode/extension-telemetry

This module provides a consistent way for extensions to report telemetry over Application Insights. The module respects the user's decision about whether or not to send telemetry data. See telemetry extension guidelines for more information on using telemetry in your extension.

Follow guide to set up Application Insights in Azure and get your key. Don't worry about hardcoding it, it is not sensitive.

Install

With npm: npm install @vscode/extension-telemetry With yarn: yarn add @vscode/extension-telemetry

Usage

Setup

import * as vscode from 'vscode';
import TelemetryReporter from '@vscode/extension-telemetry';

// the application insights key (also known as instrumentation key)
const key = '<your key>';

// telemetry reporter
let reporter;

function activate(context: vscode.ExtensionContext) {
   // create telemetry reporter on extension activation
   reporter = new TelemetryReporter(key);
   // ensure it gets properly disposed. Upon disposal the events will be flushed
   context.subscriptions.push(reporter);
}

Sending Events

Use this method for sending general events to App Insights.

// send event any time after activation
reporter.sendTelemetryEvent('sampleEvent', { 'stringProp': 'some string' }, { 'numericMeasure': 123 });

Sending Errors as Events

Use this method for sending error telemetry as traditional events to App Insights. This method will automatically drop error properties in certain environments for first party extensions. The last parameter is an optional list of case-sensitive properties that should be dropped. If no array is passed, we will drop all properties but still send the event.

// send an error event any time after activation
reporter.sendTelemetryErrorEvent('sampleErrorEvent', { 'stringProp': 'some string', 'stackProp': 'some user stack trace' }, { 'numericMeasure': 123 }, [ 'stackProp' ]);

Common Properties

• Extension Name common.extname - The extension name
• Extension Version common.extversion - The extension version
• Machine Identifier common.vscodemachineid - A common machine identifier generated by VS Code
• Session Identifier common.vscodesessionid - A session identifier generated by VS Code
• VS Code Version common.vscodeversion - The version of VS Code running the extension
• OS common.os - The OS running VS Code
• Platform Version common.platformversion - The version of the OS/Platform
• Product common.product - What Vs code is hosted in, i.e. desktop, github.dev, codespaces.
• UI Kind common.uikind - Web or Desktop indicating where VS Code is running
• Remote Name common.remotename - A name to identify the type of remote connection. other indicates a remote connection not from the 3 main extensions (ssh, docker, wsl).
• Architecture common.nodeArch - What architecture of node is running. i.e. arm or x86. On the web it will just say web.

License

MIT

vscode-extension-telemetry's Issues

Only 1st party extensions means only Microsoft extensions?

I'd like to leverage monitoring in my VS Code extension and this looks like a perfect choice, but from reading the README it seems this is only for MS extensions? I know I could plug in my Application Insights key and just try it to find out, but I don't want to create an Azure account with a CC only to find I can't use this.

Extension fails to activate if minimum engine is less than 1.40.0

We get this error if we test on our minimum VS Code engine (1.37.0 - which is still less than a year old) with the latest telemetry package:

TypeError: Cannot read property 'Web' of undefined
at TelemetryReporter.module.exports.TelemetryReporter.getCommonProperties

I'm guessing the check for vscode.UIKind.Web is what's causing problems. We're not blocked because we can just bump to 1.40.0, but thought this was worth filing because it's pretty nasty (completely prevents extension activation in our case) and is difficult to find.

A few possible improvements:

1. Support older versions of VS Code
2. Somehow enforce your minimum VS Code version (not sure if an npm package can do this)
3. Better document your minimum VS Code version
4. In the future, consider a bump to your VS Code version as a breaking change and reflect it in your version. I know pre-1.0.0 versions are somewhat subjective, but I think the common pattern would be to use "0.2.0" to reflect breaking changes

Exception thrown if an array is given as a telemetry property

This line throws an exception if an array is given as a telemetry property. I'm going to convert ours to a string so it is not a blocker for us, but probably all array properties should be converted to a string internally.

Enable event reporting immediately after TelemetryReporter is constructed

In my use case, I want to do something like this:

   // create telemetry reporter on extension activation
   reporter = new TelemetryReporter(extensionId, extensionVersion, key);
   // ensure it gets properly disposed. Upon disposal the events will be flushed
   context.subscriptions.push(reporter);
   
   reporter.sendTelemetryEvent("activated", <some additional properties>);

Since I want to see those properties for each start of the extension. However, that does not seem to work. I think, that the problem is dynamic loading of the applicationinsights module in node/telemetryReporter.ts. It loads asynchronously and is not yet available when sendTelemetryEvent is called immediately after the construction.

It does work, when I use setTimeout for the telemetry event for 1 second, but that is a sketchy workaround. Is there any better solution? Am I doing something wrong?

I suggest that either the import should be done synchronously, or add an event, that is triggered once the InsightsAppender is ready.

prevent require() patching

By using APPLICATION_INSIGHTS_NO_PATCH_MODULES

via #12 (comment)

Telemetry reporter is not a Construtor

I followed the README example and got this error. Could you help me?

help protect user anonymity

I don't understand why #32 was closed. Yes, the change is not stricy necessary. But it helps protect the users anonymity and a lot of developers are concerned about their privacy. If they find out that their names are being logged via telemetry they could turn off telemetry which would defeat the entire point of the library.

Add additional optOut key

This is a feature request to add an additional, optional optOut key. My understanding is that the recommended way to use this extension is to ensure two configuration options are enabled before sending any telemetry. The first one is the global telemetry.telemetryEnabled option and the second one is specific to your extension. This enables someone to opt out of your telemetry while still opting in to vscode's global telemetry.

My proposal is to add an extra optional string parameter to the TelemetryReporter constructor. This parameter points to a config option that must also be enabled in order for telemetry to be sent.

The change is fairly straight forward and I'm happy to submit a PR if you think this is a reasonable direction to go.

Filter out file paths form telemetry exception call stack

We get the user's file path information when it comes as a part of the telemetry exception. Is there any possibility to filter out these file paths from the call stack?

On Linux

Error:
   at <no_method> (at /home/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246at /home/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246: /home/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.jsat /home/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246: 1)

On Windows

AssertionError:
   at new AssertionError (at new AssertionError (internal/assert/assertion_error.js:433:11)at new AssertionError (internal/assert/assertion_error.js:433:11): internal/assert/assertion_error.jsat new AssertionError (internal/assert/assertion_error.js:433:11): 433)
   at getVersion.then.catch.t (at getVersion.then.catch.t (c:\Users\<username>\.vscode\extensions\<extension-name>-<extension-version>\dist\extension.js:1:187675)at getVersion.then.catch.t (c:\Users\<username>\.vscode\extensions\<extension-name>-<extension-version>\dist\extension.js:1:187675): c:\Users\<username>\.vscode\extensions\<extension-name>-<extension-version>\dist\extension.jsat getVersion.then.catch.t (c:\Users\<username>\.vscode\extensions\<extension-name>-<extension-version>\dist\extension.js:1:187675): 1)
   at processTicksAndRejections (at processTicksAndRejections (internal/process/task_queues.js:97:5)at processTicksAndRejections (internal/process/task_queues.js:97:5): internal/process/task_queues.jsat processTicksAndRejections (internal/process/task_queues.js:97:5): 97)

On MacOS

Error:
   at <no_method> (at /Users/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246at /Users/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246: /Users/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.jsat /Users/<username>/.vscode/extensions/<extension-name>-<extension-version>/dist/extension.js:1:188246: 1)

Regression: "cannot read property 'length' of undefined"

This line has caused a regression resulting in an error popup, "cannot read property 'length' of undefined". The stack variable is undefined.

Found via microsoft/vscode-docker#1925.

@EricJizbaMSFT FYI

Distinguish optOut from lost users

Hi,

My understanding is that when users optOut from telemetry in VSCode, no more events will be sent to the server. This means users having already been counted as active users will count as lost users, making retention analysis polluted.

I understand users having already optedOut before our extension is installed should not being tracked at all. But for users changing their mind in after some pings have already been sent, why not sending a last ping to record they opted out?

Linux OS version property send with telemetry events can contain PII

This is the case for self-compiled kernels.

question about the sample in the readme

The following code snippet resides in the readme file:

// telemetry reporter 
let reporter;

function activate(context: vscode.ExtensionContext) {
   ...
   // create telemetry reporter on extension activation
   reporter = new TelemetryReporter(extensionId, extensionVersion, key);
   // ensure it gets property disposed
   context.subscriptions.push(reporter);
   ...
}

function deactivate() {
  // This will ensure all pending events get flushed
   reporter.dispose();
}

Is the manual dispose() in deactivate necessary? I thought that adding the reporter to context.subscriptions would automatically result in dispose() being called when VS Code cleans up.

Guard for multiple AI reporters in the same process

Update to [email protected]

We need to update [email protected] in order to get a fix for microsoft/ApplicationInsights-node.js#458 so that the following error message in the console goes away:

This issue is for updating our built in extensions to this newer version. I filed microsoft/vscode#64849 for updating VSCode core.

[baseTelemetryReporter.ts] vscode.env.isNewAppInstall.toString(); throws on older versions of VS Code

Hi!

I was investigating an issue on MacOS where the Live Share extension was failing to activate with the following exception:

cannot read property toString of undefined

It was due to the following change:

572a113

This line throws on older versions of VS Code (ex: 1.53.0) as isNewAppInstall doesn't appear to be defined:

commonProperties["common.isnewappinstall"] = vscode.env.isNewAppInstall.toString();

When I updated to the latest VS Code (1.60.2) it resolved the issue.

Should this have an undefined check to be backwards compatible for users with older VS Code versions?

Will it wrap appInsights.defaultClient.trackException() ?

Currently it seems to leverage appInsights.defaultClient.trackEvent(...) API, so all the usage data are located in customEvents category.

Any plan to wrap other APIs like trackException(), so data can be placed into exception category. Then I don't have to mannually add additional properties. e.g. { "type": "exception"} in the customEvents.

sendTelemetryErrorEvent missing errorProps parameter

ff39cb3 removed errorProps from the signature of the sendTelemetryErrorEvent function, even though the implementation has it. Can this be restored?

(We use this in the Python extension, so if we upgrade, this fails to typecheck even though it should be valid.)

Use `vscode.env.isTelemetryEnabled` when possible

Beginning in VSCode 1.55.0, there is a new property, vscode.env.isTelemetryEnabled. This is mostly equivalent to the telemetry enablement setting, but accounts for CLI arguments as well.

When vscode-extension-telemetry is able to update to @types/vscode 1.55.0+, that API should be used instead of the setting.

This would apply here.

Can you add a way to determine if the telemetry was successfully sent or not?

We observe that a certain percentage of telemetry events are somehow lost. For some of our telemetry, we only want to send it only 1 time, but if the telemetry is "lost" then we want to resend it, but we don't have any way to determine if the telemetry was lost or not.

Not all paths should be anonymized

The path anonymization that happens on all properties on all events here and here is too aggressive. Our extension already anonymizes user paths, but does so by hashing the directory name and the file name so we can know when two events are referring to the same file or files in the same directory, without leaking sensitive info. These paths look like /79762eff/ddba19d2.txt. The logic linked above detects these as paths and throws away this extra info.

It should at least be possible to opt-out of anonymizing paths. And I think it should probably be opt-in to anonymize them in the first place. A model like errorProps on sendTelemetryErrorEvent may be more appropriate.

Telemetry stopped to work this monday

Telemetry events are not being received by Azure since monday. Did they change the API?

Add option to remove location data from telemetry events

For our extension, we want to gather as little information as we can about our users while still being able to answer the questions we have.

With this in mind, we do not need any location data. I would like to add an option to remove this from the payload. I can see several possible solutions:

1. add a new flag to disable collecting location data (easy for users, but not very flexible if users also want to void sending other data, like client IP).
2. expose the internal applicationInsight instance and allow users to customize in any way they want.
3. Allow users to add custom TelemetryProcessors to the applicationInsight instance.

Any of these solutions would be fine by me.

No events logged with MWE

I have the following (copy-pasting relevant bits from my extension)

...

import TelemetryReporter from 'vscode-extension-telemetry'

let extension: Extension
export function activate(context: vscode.ExtensionContext) {
    extension = new Extension()
     ...
     context.subscriptions.push(extension.telemetryReporter)
}

export function deactivate() {
    extension.telemetryReporter.dispose()
}

...
export class Extension {
    ...
    constructor() {
        ...
        const self = vscode.extensions.getExtension('tecosaur.latex-utilities') as vscode.Extension<any>
        this.telemetryReporter = new TelemetryReporter(
            'tecosaur.latex-utilities',
            self.packageJSON.version,
            '015dde22-1297-4bc0-8f8d-6587f3c192ec'
        )
    }
}

...

this.extension.telemetryReporter.sendTelemetryEvent('formattedPaste', { type: 'text' })

However I don't see anything in azure.

Debugging the extension there don't seem to be any issues.

[Browser TelemetryReporter] Report common browser properties (browserName, browserVersion, etc)

Does the browser telemetryReporter already include common browser properties that every extension can consume?

[ex] browserName, browserVersion, hostLocation (excluding subdomain), etc.

I'm currently adding it as follows from our extension but it would be great if this was built-in:

import { detect } from 'detect-browser';
const info = detect();
const version = (info && info.version) || '');
const name = (info && info.name) || '',);

Maintain corresponding tags and/or GitHub releases for NPM package versions

It seems that published versions on NPM do not correspond with tags on this repository.

https://www.npmjs.com/package/vscode-extension-telemetry

https://github.com/microsoft/vscode-extension-telemetry/tags

This makes it hard to trust that the code being published corresponds with any code in this repository and even if we trust it then it's impossible to tell what NPM package versions correspond with what revision of code.

Could you please make the publishing process more transparent and trustworthy? I guess ideally the process would be automated and publishing triggered by tag push, but at least manually pushing the corresponding tags to this repo would be helpful.

e.exports is throwing exception

I receive this event but I don't know what is causing it. A lot of my users are having this.

Error:
at e.exports (at e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:32549)at e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:32549): /Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.jsat e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:32549): 1)
at e.exports (at e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:64527)at e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:64527): /Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.jsat e.exports (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:64527): 1)
at IncomingMessage. (at IncomingMessage. (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:129497)at IncomingMessage. (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:129497): /Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.jsat IncomingMessage. (/Users/mikhail/.vscode/extensions/allanoricil.salesforce-soql-editor-0.2.32/dist/extension.js:1:129497): 1)
at IncomingMessage.emit (at IncomingMessage.emit (events.js:208:15)at IncomingMessage.emit (events.js:208:15): events.jsat IncomingMessage.emit (events.js:208:15): 208)
at endReadableNT (at endReadableNT (_stream_readable.js:1168:12)at endReadableNT (_stream_readable.js:1168:12): _stream_readable.jsat endReadableNT (_stream_readable.js:1168:12): 1168)
at processTicksAndRejections (at processTicksAndRejections (internal/process/task_queues.js:77:11)at processTicksAndRejections (internal/process/task_queues.js:77:11): internal/process/task_queues.jsat processTicksAndRejections (internal/process/task_queues.js:77:11): 77)

vscodemachineid not unique

In application insights i can see a user that has submitted over 10,000 events, this seemed unusually high so i looked more into this and found that the location for the user shows around 20 different countries. They all have the same OS (Darwin) but at different versions. This cannot be the same user for some reason the machine id is being duplicated and is not unique for each user

What's meant by "common properties"?

There are examples of common properties such as common.vscodesessionid but I don't know what this common module is.
Could you explain it more clearly?

Result is succeeded even if the execution is canceled

In the scenario where some API calls are made post a user input, and nothing is there at the user end for interaction, if we start another flow, (say, using Ctrl+Shift+P), a new flow begins and a telemetry log with Result : Succeeded get created even if we cancel or if there comes an error when the flow returns from the API call.

This is a typical behavior when a new flow gets started when something else is happening in the background. At that stage, even pressing Esc isn't considered.

Repro steps (with deploy-to-azure extension) :

1. Begin an execution flow to deploy a ci/cd pipeline.
2. In middle of the flow, start a new flow (using Ctrl+SHift+P)post the input of GitHubPat/Azure resource.
   At these stages, certain things are happening in the background and no user input is expected.
   The observation is whenever the first flow returns, irrespective of it's output, a telemetry log with Result = succeeded gets created.

Warning when running webpack: Can't resolve 'applicationinsights-native-metrics'

I'm developing an extension that takes as dependency vscode-extension-telemetry.
When running webpack to bundle my VS Code extension, I get the following warning:

WARNING in ./node_modules/applicationinsights/out/AutoCollection/NativePerformance.js
Module not found: Error: Can't resolve 'applicationinsights-native-metrics' in 'C:\Users\...\node_modules\applicationinsights\out\AutoCollection'  @ ./node_modules/applicationinsights/out/AutoCollection/NativePerformance.js
 @ ./node_modules/applicationinsights/out/applicationinsights.js
 @ ./node_modules/vscode-extension-telemetry/lib/telemetryReporter.js
 @ ./src/MyExtension.ts

I tried to take directly a dependency on applicationinsights-native-metrics, but then I get another error:

ERROR in ./node_modules/applicationinsights-native-metrics/out/main.js
Module not found: Error: Can't resolve '../build/Release/native_metrics' in 'C:\Users\...\node_modules\applicationinsights-native-metrics\out'

I had a look quickly at the cause of this error. Go here for more details: microsoft/ApplicationInsights-node.js-native-metrics#4 (comment)

From my understanding so far, all VS Code extensions using vscode-extension-telemetry and webpack will get this warning.
Is there any known workaround? Is it safe to ignore this warning?

Thanks!

Add support for web extensions

Currently this package is using the ApplicationInsights-node.js package which (as would be expected) relies on node.js. We should support an alternate build that uses the ApplicationInsights-JS package which works on the web.

Async way to send telemetry event

Hi, I am using the TelemetryReporter. And I was wondering are there any async way for the sendTelemetryEvent function?

In my scenario, I would like to ensure telemetry data is all sent before vscode instance is closed. There is sendTelemetryEvent function but no async one.

Please help. Thanks!

Clean install and use throws an error

I'm not sure why TypeScript isn't catching this, but baseTelemetryReporter.ts#L151 (commonProperties["common.isnewappinstall"] = vscode.env.isNewAppInstall;) is the source of an error because it is expected that the values of all commonProperties are of type string but this one is boolean. I was able to fix it by changing the line to commonProperties["common.isnewappinstall"] = vscode.env.isNewAppInstall ? "true" : "false";.

Happy to create a PR. Unfortunately, we can't use this package until the issue is fixed.

ApplicationInsights makes requests even when Telemetry is disabled (new vscode profile)

From @gima

• VSCode Version: 1.21.1
• OS Version: Arch Linux

Steps to Reproduce:

1. Open VSCode with fresh user profile (--user-data-dir /tmp/new-vscode-profile)
2. Specify the following User Settings and close VSCode

{
    "telemetry.enableTelemetry": false,
    "telemetry.enableCrashReporter": false,
    "update.channel": "none",
    "extensions.autoUpdate": false,
    "workbench.startupEditor": "none"
}

3. Capture network traffic and start VSCode
4. Observe DNS query to dc.services.visualstudio.com and TLS connection to returned IP on port 443.

Does this issue occur when all extensions are disabled?: Yes

Bug Description
Opening VSCode with telemetry disabled causes uncalled-for network requests.

The request is:
GET https://dc.services.visualstudio.com/api/profiles/AIF-d9b70cd4-b9f9-4d70-929b-a071c400b217/appId
Returned HTTP status code is 404.

• The request is being done by
  app/extensions/git/node_modules/applicationinsights
  (Empty window, no welcome screen, as it was disabled by user setting above).
  HTTP request caused by:

CorrelationIdManager.queryCorrelationId = function : Library/CorrelationIdManager.js
CorrelationIdManager.queryCorrelationId(..); : Library/Config.js
set: function : Library/Config.js
this.profileQueryEndpoint = : Library/Config.js

Stacktrace at function responsible for the HTTP request:

at Function.CorrelationIdManager.queryCorrelationId (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/Library/CorrelationIdManager.js:35:10)
at Config.set [as profileQueryEndpoint] (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/Library/Config.js:31:34)
at new Config (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/Library/Config.js:21:35)
at NodeClient.TelemetryClient (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/Library/TelemetryClient.js:24:22)
at new NodeClient (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/Library/NodeClient.js:25:42)
at Object.setup (/tmp/vsc/resources/app/extensions/git/node_modules/applicationinsights/out/applicationinsights.js:41:33)

• Additional request is being done by
  app/extensions/git/node_modules/applicationinsights
  (When User Settings is left open, and restored on VSCode startup).

References to dc.services.visualstudio.com can be found in the following files:

• app/node_modules/applicationinsights
• app/extensions/html/node_modules/applicationinsights
• app/extensions/git/node_modules/applicationinsights
• app/extensions/typescript/node_modules/applicationinsights
• app/extensions/markdown/node_modules/applicationinsight
• app/extensions/json/node_modules/applicationinsights

In my view this is not supposed to happen. Telemetry should not be sent when telemetry is disabled. I don't know whether this is a bug in each of the [base,html,git,typescript,markdown,json] extensions or in applicationinsights (https://github.com/Microsoft/ApplicationInsights-node.js)

Hopefully this was enough information to fix the problem.

Filter out email address from Error call stack

Hi DevDiv has updated the privacy policy:

Do we have a plan to filter out email address, oid etc. from Error call stack?

Send end of session events

End of session events for extensions appear to be being dropped during VS Code's termination process. It would be extremely helpful to make sure these get through (both from normal and abnormal shutdowns). For example, Live Share's “vsliveshare/coauthoring/close-buffer” event provides key information like number of edits but is getting dropped from many sessions.

We're getting 16 duplicate events for some users starting this Friday

As of Friday, we started getting 16 duplicate events appearing for some user, i.e. data that should only be sent once per user. All the 16 duplicate events have the exact same data and timestamp. This is with 0.1.1. I could move this to the applications insight issues page (https://github.com/Microsoft/ApplicationInsights-node.js/issues). On average, it causes around 7 times as much telemetry to be sent.

We don't believe anything in our app could be causing this (https://github.com/Microsoft/vscode-cpptools/tree/master/Extension ).

allow developer to set the sampling percentage

see https://github.com/Microsoft/ApplicationInsights-node.js#sampling

appInsights.defaultClient.config.samplingPercentage = 33; // 33% of all telemetry will be sent to Application Insights

Seems like it could be useful to prevent too many events.

trackMetric support

see https://docs.microsoft.com/en-us/azure/azure-monitor/app/api-custom-events-metrics#trackmetric

It would be nice to have this capability.

Use the `telemetry.enableTelemetry` setting

Before sending telemetry from this module we should check the telemetry.enableTelemetry" setting and only send if this is not false.

This would allow us to state that MSFT extensions [that use this library] respect this setting. Including our own internal extensions.

Sean

Console methods are patched by `diagnostic-channel-publishers`

This week @alexandrudima noticed some strange console.log messages coming up in devtools:

@bpasero Investigated and found diagnostic-channel-publishers patching up console methods. A fix to work around this was pushed: microsoft/vscode@a9b44c2

I then found this documentation in appinsights:

In order to track context across asynchronous calls, some changes are required in third party libraries such as mongodb and redis. By default ApplicationInsights will use diagnostic-channel-publishers to monkey-patch some of these libraries. This can be disabled by setting the APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL environment variable. Note that by setting that environment variable, events may no longer be correctly associated with the right operation. Individual monkey-patches can be disabled by setting the APPLICATION_INSIGHTS_NO_PATCH_MODULES environment variable to a comma separated list of packages to disable, e.g. APPLICATION_INSIGHTS_NO_PATCH_MODULES=console,redis to avoid patching the console and redis packages.

I verified that adding the following snippet right before importing applicationinsights works:

process.env['APPLICATION_INSIGHTS_NO_PATCH_MODULES'] = 'console';

@ramya-rao-a Do we use the console patching for anything, or can we simply disable it using that env? If so, let's publish that fix, update it in our extensions and then we can revert the workaround commit in VS Code.

cc @alexandrudima @bpasero

Update to the latest version of appinsights

Allow functionality to collect for unique user metrics

Currently, the extension collects custom telemetry data using the getCommonProperties() method. With custom metrics, the default Users and Sessions fields don't get populated with data, which makes tracking unique users and sessions in the AppInsights portal difficult. It would be helpful to have a feature to allow developers to collect unique user data, if desired, by populating the userID and sessionID fields.

Broken esbuild dependency since `0.4.2`

When cloned this repository locally to work on a PR, I noticed that esbuild dev dependency seems somehow broken as it requires a particular os/arch combination.

Specifically npm install on darwin/amd64 always fails:

npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for [email protected]: wanted {"os":"linux","arch":"ppc64"} (current: {"os":"darwin","arch":"x64"})
npm ERR! notsup Valid OS:    linux
npm ERR! notsup Valid Arch:  ppc64
npm ERR! notsup Actual OS:   darwin
npm ERR! notsup Actual Arch: x64

I believe the root cause is 81d78c6 but I can't tell how the change was generated.

I can only confirm that running npm install on 0.4.1 succeeds with some expectable warnings:

> [email protected] postinstall /Users/radeksimko/gopath/src/github.com/microsoft/vscode-extension-telemetry/node_modules/esbuild
> node install.js

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-windows-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"win32","arch":"arm64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-windows-64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"win32","arch":"x64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-windows-32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"win32","arch":"ia32"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-sunos-64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"sunos","arch":"x64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-ppc64le):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"ppc64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-openbsd-64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"openbsd","arch":"x64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-mips64le):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"mips64el"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-arm):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"arm"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"arm64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"x64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-linux-32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"linux","arch":"ia32"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-freebsd-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"freebsd","arch":"arm64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-darwin-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"arm64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-freebsd-64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"freebsd","arch":"x64"} (current: {"os":"darwin","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/esbuild-android-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"android","arch":"arm64"} (current: {"os":"darwin","arch":"x64"})

added 217 packages from 228 contributors and audited 232 packages in 8.678s

I don't have much experience with esbuild myself, but the problem seems fixable by just running npm install esbuild.

---

On a separate note there seems to be a discrepancy with the lockfile as Node.js v14 (LTS) comes with npm 6, but the lockfile uses v2 format introduced in npm 7, so I'd expect either higher Node.js version to be used or lower npm?

Allow tracking other data types than just `string`

The upstream applicationinsights library's contract allows for any data to be sent as event properties:

https://github.com/microsoft/ApplicationInsights-node.js/blob/52d3937bbb59d5bb29ecb04dc7fa1c06c04baafa/Library/TelemetryClient.ts#L100-L106

https://github.com/microsoft/ApplicationInsights-node.js/blob/c13a78d900be17f000992c2a2fbfb162062c5271/Declarations/Contracts/TelemetryTypes/Telemetry.ts#L9-L12

but this library seems to limit it to just strings, which means that non-string primitive data have to be converted to strings and more complex data to JSON as string, which in turn makes later querying more difficult.

Is there a strong reason for this limitation? If not, could this interface just mimic the upstream library's interface?

vscode-extension-telemetry/lib/telemetryReporter.d.ts

Lines 5 to 7 in bb8286d

	export interface TelemetryEventProperties {
	readonly [key: string]: string;
	}

i.e. { [key: string]: any; }?

[Discussion] versioning strategy

@ramya-rao-a just submitted several PRs to fix an out of date 'vscode-extension-telemetry' version in several of our repos. We noticed you only ever update the 'patch' version, which doesn't give us any info about your update.

Instead - could you use the minor version for breaking changes and the patch version for non-breaking changes? Admittedly there's no "official" versioning strategy for pre-1.0 packages, but I believe this is a common pattern. Once you release 0.1.0, that means we can automatically pick up any 0.1.x change without having to manually update.

Upgrade to latest version of applicationInsights (1.0.7)

microsoft/ApplicationInsights-node.js#444 was blocking the C# extension in on boarding to the latest version of vscode-extension-telemetry.

Now that the fix is out, we need to upgrade to the latest version of applicationInsights (1.0.7), publish a new version of vscode-exension-telemetry module, and notify the C# extension author

What's the recommended way to prevent telemetry during development and testing?

I don't want my usage during extension development and testing to make our usage seem significantly higher than it actually is. What's the recommended way to avoid this?

How do I also avoid this, when downloading the published extension from the marketplace when I want to test it from there?

Cut new version

Hi,
Thanks for all your work on the module.

Would you mind cutting a new version with the recent changes? The latest one was cut a month ago and we'd like to use some of the new functionality recently merged in our extension: hashicorp/vscode-terraform#823