Add SSH connection analytics

[iQQBot]

Description

This PR introduce SSH connection analytics in ws-proxy

Related Issue(s)

Fixes #

How to test

1. open a workspace
2. use copy/paste SSH command to connect
3. watch segment event, you will see ssh_connection event

Release Notes

Add SSH connection analytics

Documentation

• /werft analytics=segment|TEZnsG4QbLSxLfHfNieLYGF4cDwyFWoe

[akosyakov]

@iQQBot Could you add a new event in https://www.notion.so/gitpod/Tracking-Plan-ed27d1492da745b9b31711dd73dcbe57 please, explain properties, phases and possible values? 🙏

[iQQBot]

Added https://www.notion.so/gitpod/ssh_connection-60f7d649667b4f8ead093daaf7ac619e

[akosyakov]

@iQQBot Could we extract an improvement in another PR? I think the improvement is questionable and need to be discussed. Analytics though looks good already. I would like analytics parts get merged.

[iQQBot]

@akosyakov @andreafalzetti Already do some cleanup, now this PR only include analytics for ssh connection

[akosyakov]

lgtm, thank you a lot!

[akosyakov]

Could you also add a metric for prometheus with another PR? I don't think we need to track duration of ssh connections, but having a counter of auth/connection attempts and success rate will be helpful. We don't need to label workspaces or collect any error information but only use it for monitoring and alerts. If we see a spike then we should go to logs and check them.

[andreafalzetti]

watch segment event, you will see ssh_connection event

Where do I verify the data? From segment.com? 🤔

[iQQBot]

watch segment event, you will see ssh_connection event

Where do I verify the data? From segment.com? 🤔

Yes, login your account then find source staging untrust -> debugger https://app.segment.com/gitpod/sources/staging_untrusted/debugger

[iQQBot]

Could you also add a metric for prometheus with another PR? I don't think we need to track duration of ssh connections, but having a counter of auth/connection attempts and success rate will be helpful. We don't need to label workspaces or collect any error information but only use it for monitoring and alerts. If we see a spike then we should go to logs and check them.

Ok, no problem, just one point needs to be clarified, as a public network to expose the IP of port 22, is bound to be a variety of hackers violent crack every day, I suggest that the success rate of the statistics here should ignore the user name length of less than 6 digits

[akosyakov]

Ok, no problem, just one point needs to be clarified, as a public network to expose the IP of port 22, is bound to be a variety of hackers violent crack every day, I suggest that the success rate of the statistics here should ignore the user name length of less than 6 digits

Let's try without first?

[iQQBot]

Ok, no problem, just one point needs to be clarified, as a public network to expose the IP of port 22, is bound to be a variety of hackers violent crack every day, I suggest that the success rate of the statistics here should ignore the user name length of less than 6 digits

Let's try without first?

OK

[nandajavarma]

LGTM from the installer side. Also, noting that this does not affect the self hosted user.