This is a Visual Studio Code extension for Digma, providing continuous feedback to developers. With this extension, developer can see insights related to their code, derived from sources such as OpenTelemetry, right in the IDE. To read more about the Digma platform visit our main repo.
It provides code objects insights and runtime analytics inside the IDE. The IDE is intended to be extensible (currently refactoring toward that), so that anyone would be able to define new types of insights based on the collected data.
Discovering code objects is a key part of the extension functionality. Code objects can be anything that can be found in the code on the client side, and from the observability data on the backend. Code objects are associated with aggregated data and insights.
In the below example, you can see some potential code objects to discover marked out in red:
There are many types of possible code objects, this is where the platform is extensible to support them both on client and server. Here is some of current backlog:
- β Functions/methods
- β REST endpoints
- β OTEL Spans
- β GRPC endpoints (WIP)
- RabbitMQ event classes
- Kafka producer
- Classes/modules
- More...
Of course code object discovery is language specific, sometimes platform or library specific.
More basic method/function discovery is done using the language server for that specific programming language already installed in the IDE.
Commits are a way to group code object feedback together. Digma's backend already tags each metric and trace by the relevant commit identifier.
TBD
Based on the code section currently focused on the IDE, the Code Insights sidebar panel displays the relevant insights for the discovered code objects in that section. While focused on a specific function in the code I'll be able to see all relevant insights.
The IDE extension in this case simply queries the backend API with the discovered code object identifier. The backend provides back a list of insights that were gleaned from the observability data that relate to these objects.
The runtime errors panel provides analytics over the error behavior of both the specific code object and the different code object flows it participates in.
The errors are not displayed as raw data π₯©. Digma already groups together errors which essentially signify the same problem and also highlights those errors that are "interesting". What makes an error interesting? That is something decided by the backend scoring processes but some reasons may include:
- π It is trending up!
- π It is something that started recently
- π£ It is affecting multiple services
- π³ It is not handled internally some other place
Digma identifies flows which describe how code objects are used together. It can be useful to think about a code flow like a 'proto-trace'. Basically grouping together all traces that are extremely similar as a 'flow' within the application and starting to aggregate information about that flow.
There are multiple ways in which additional information is provided regarding the errors. Including highlighting of specific lines within the code itself. However, by double clicking into a specific error type we can get more information about it as well as navigate the callstack to understand its origins:
Some insights can be highlighting in the code itself using code annotations. Based on the information passed on from the backend the extension will proactively display annotations or even highlight a specific code object to provide feedback.
Another way to provide feedback on code object behavior is through their tooltips. For example, looking at this function object I can already see which runtime error types I should be expecting:
Insights on runtime data can also be displayed. For example, in this case Digma has identified that in all different occurrences of this specific error, a parameter is always None:
Some of the insights provide additional information regarding how the code is used and what is the change impact radius. Below we can see different span sources reaching the selection code section with a simple breakdown.
The observability data is typically collected from multiple environments (staging, dev, prod, CI, etc.). The Context panel allows the user to choose the environment he would like to see feedback from.
Environments can be easily assigned to observability data collected via an env variable on the running process.
This extension contributes the following settings:
| Key | Description |
|---|---|
digma.enableCodeLens |
Enable/disable methods codelens regarding errors. |
digma.url |
Digma api endpoint url. |
digma.environment |
Filter the telemetry data by environment. Can be set from the Context panel, by selecting from the Environment dropdown. |
digma.hideFramesOutsideWorkspace |
Show/Hide frame of files that do not belong to the opened workspace(s) Can be in Error Flow Details panel, by checking/unchecking the Workspace only checkbox). |
digma.sourceControl |
Workspace's source control - used to open files in specific revision. Only git is supported for now. |
digma.enableNotifications |
Enable/disable insight event notifications. |
npm install
vsce package