Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gitpod] enable telemetry for testing #257

Merged
merged 1 commit into from
Dec 17, 2021
Merged

Conversation

jeanp413
Copy link
Member

@jeanp413 jeanp413 commented Dec 10, 2021

This PR fixes #

Logs can be found in ~/.vscode-remote/data/logs/<date>/telemetry.log

@jeanp413 jeanp413 force-pushed the gp-code/main branch 2 times, most recently from 0b66d21 to 4fe2a9f Compare December 11, 2021 09:59
@akosyakov akosyakov changed the title Enable telemetry for testing [gitpod] enable telemetry for testing Dec 13, 2021
@akosyakov
Copy link
Member

akosyakov commented Dec 13, 2021

@loujaybee with this PR you can see different telemetry events instrumented by MS, could you have a look please what can be interesting for us? We can add also additional instrumentation if needed.

To investigate:

  • https://gitpod.io#https://github.com/gitpod-io/openvscode-server/pull/257
  • await till another window on port location 9888 opens with with instrumented dev version, there can be multiple windows opened recursively, just close them
  • in this window do F1 -> Developer: Open Window Log File (Session)... -> Select current session and then telemetry.log
  • now you see all telemetry collected
  • try to perform some interesting actions and see what events are produced

@jeanp413
Copy link
Member Author

jeanp413 commented Dec 14, 2021

Updated steps as I did more changes:

  • https://gitpod.io#https://github.com/gitpod-io/openvscode-server/pull/257
  • await till another window on port location 9888 opens with with instrumented dev version, there can be multiple windows opened recursively, just close them
  • in this window do F1 -> Developer: Set Log Level -> Select trace
  • Open bottom Panel and click the Output tab, in the dropdown select Log (telemetry)
  • try to perform some interesting actions and see what events are produced

package.json Outdated Show resolved Hide resolved
}

log(eventName: string, data?: any): void {
data = mixin(data, this._defaultData);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will race with preparing api?

@@ -290,11 +293,13 @@ export class RemoteExtensionHostAgentServer extends Disposable {

let appInsightsAppender: ITelemetryAppender = NullAppender;
if (supportsTelemetry(this._productService, this._environmentService)) {
if (this._productService.aiConfig && this._productService.aiConfig.asimovKey) {
if (this._productService.aiConfig && this._productService.aiConfig.asimovKey !== 'foo') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this left over, or genuine code? 😆

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's intended, I could remove that block of code, but this way I think it would create less merge conflicts

@loujaybee
Copy link
Member

Wow, this is awesome! Thanks so much @jeanp413 😍

It would be good to get this foundational PR merged, which implements the "framework" for capturing these events, and an easy way to map these events into the tracking event structure (the structure is decided on a case-by-case basis) we send to Segment, which is implemented in analytics.ts [1].

I'd argue that this PR should only put in place that "foundational" code, and then we can specify the exact events we need to track, and what format we need to store them (for our purposes) on the other GitHub issues. e.g. In other words, we add the specifics of which telemetry events to track (and how to map them to the segment structure) on each analytics ticket (gitpod-io/gitpod#6897, gitpod-io/gitpod#6895, gitpod-io/gitpod#6981)

However, for reference, some of events that look useful right now:

  1. telemetry/activityBarAction (id: workbench.view.explorer) - Open file explorer (side bar)
  2. telemetry/filePUT - User has inputted on a file
  3. telemetry/activityBarAction (viewletId: workbench.view.search) - Open file search (side bar)
  4. telemetry/activatePlugin - Installed extension
  5. telemetry/workbenchActionExecuted (id: workbench.files.openFile) - Click to open file
  6. telemetry/fileGet - File request is made
  7. telemetry/workbenchActionExecuted (id: workbench.action.terminal.clear) - Clear terminal output (even with shortcut)

A few events I couldn't trigger yet:

  • Anything really related to git, I could see some git-triggered events, but nothing super useful
  • The terminal doesn't really trigger any events it seems (apart from "clear" and/or open new terminal, etc)
  • I couldn't figure out how to initiate a guide/walkthrough and/or pop-up notifications (yet)

A couple of challenges:

  • We will need to experiment over time to understand what initiates these events (in some cases it could be multiple sources, which could make our analytics results inaccurate)
  • We'll need to throttle/debounce some events otherwise we'll get flooded with unnecessary data

Thought:

When we do implement the events, it would be nice if we have a simple collection of maps, that map between these telemetry events, and the analytics ones. e.g.

const maps = [
    (/* The teletry event */) => {
       return // The analytics event
    }, 
    (/* The teletry event */) => {
       return // The analytics event
    }
]

So that it's super easy to add new events (read: I could do it without having to bother you guys 😁 )

data = mixin(data, this._defaultData);
data = validateTelemetryData(data);

if (eventName !== 'workbenchActionExecuted') {
Copy link
Member

@akosyakov akosyakov Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeanp413 let's start but tracking first read and write interactions, so we don't produce many data and addressing gitpod-io/gitpod#6981

We can have following event:

{
    eventName: 'vscode_file_access`,
    properties: {
        // first `editorOpened` or `fileGet` fires `read`
        // first `filePut` fires `write`
        kind: 'read' | 'write',
        // from supervisor info endpoint
        workspaceId: string,
        // from supervisor info endpoint
        workspaceInstanceId: string,
        // from MS telemetry event
        sessionId: string,
        // from MS telemetry event
        timestamp: Date
    }
}

It is important that we care about only first to avoid spamming segment.

We need also kind of a function which does conversion from MS telemetry event to our event similar how @loujaybee is suggested in #257 (comment) It should help later adding more events for other team members.

It will be all for the scope of PR. After that we can work one by one with concrete issues.

Copy link
Member Author

@jeanp413 jeanp413 Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the logic to send just the first events but they are misleading as they are triggered when the getting started page or the simple-browser is shown

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it because editorOpened or fileGet?
Maybe we can filter down editorOpened for files with file scheme?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will take a look but not sure if that is gonna be reliable enough. either way I think this PR is done and we can polish this event in following PRs related to each gitpod telemetry issue

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ended up creating separate event for editorOpened and filtering by 'workbench.editors.files.fileEditorInput'
fileGet gets fired automatically by the gitpod-web extension when reading the gitpod.yml file.
If this needs more tweaking lets address them in following PRs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it sounds like fileGet and filePut more track fs access by any source (i.e. api and user triggered), we should not rely on it.

Copy link
Member Author

@jeanp413 jeanp413 Dec 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so should I delete them? and just send editorOpened?

@akosyakov
Copy link
Member

@jeanp413 check that by enabling telemetry for Gitpod we don't send anything to MS even from extensions like built-in for instance git or 3rd party like GHPR extensions.

@jeanp413
Copy link
Member Author

I'll go ahead and merge this

@jeanp413 jeanp413 self-assigned this Dec 17, 2021
@jeanp413 jeanp413 merged commit 97df074 into gp-code/main Dec 17, 2021
@jeanp413 jeanp413 deleted the jp/testing-telemetry branch December 17, 2021 00:02
super(address, protocols, {
headers: {
'Origin': new URL(gitpodHost).origin,
'Authorization': `Bearer ${serverToken}`
Copy link
Member

@akosyakov akosyakov Dec 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeanp413 we need to add here User-Agent at least. It should be a requirement for all our clients to Gitpod Server

}
filterEvent.add(eventName);
return {
event: `vscode_${formatEventName(eventName)}`,
Copy link
Member

@akosyakov akosyakov Dec 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should be vscode_file_access with read kind.

I think it would be better to wait for approval with this PR.

We should be careful with adding new events. Because we need to track them in these doc and make sure that they make sense for @loujaybee and @jakobhero: https://www.notion.so/gitpod/dd900d5177944fc38d22bb8c7d3d2cce?v=54cdae8ff0f54b4d8235429ab9893e49

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, sorry about that, do you want me to revert it? or just push the changes directly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be enough to make a new PR which properly collects vscode_file_access. And merge it only after approval this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants