-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Implement Language Server Metrics #14245
Comments
Because of microsoft/vscode-languageserver-node#517 there are a few more steps we will need to do before providing full metrics. Currently, in https://github.com/JPinkney/theia-plugin-extension-metrics we can collect the number of errors that occur in a particular vscode extension by inspecting the output channel and using a regex to abstract the method that is erroring. Then we can keep track of the number of times this method inside of that output channel has errored. A Prometheus metric would look something like: where Although this doesn't necessarily give us all the information we need it is a stepping stone towards future work for full support of these language metrics. In order to achieve full support we need to do a few things that can be done in a few different ways. No matter what we will have to work on eclipse-theia/theia#6151 so that we can get the number of successful language requests that happen from a vscode extension id/particular output channel id. Next we have two options on what we can do:
Or
Obviously 1 is ideal because we don't have to manually provide a static mapping but it all depends on the implementation we can have for eclipse-theia/theia#6151. |
From what I can tell theres only a few things that need to be finished for this task: Once those are done #13375 needs to be completed to be able to get the metrics to prometheus |
PR has been merged. |
In #13270 we are asked to provide the following metrics:
The % of Language Servers requests that get a successful response
The % of Language Servers requests that get a successful response in under N seconds
Let's implement this as far as we can (see also #13375). We need to ensure that metrics have no negative impact on performance (e.g. no potentially blocking calls, etc.).
as we investigaged in #14017, our approach will be to instrument the plugin API, as this is our preferred way of implementing language support.
The text was updated successfully, but these errors were encountered: