Create a skeleton of the driver debug utility

[skypodolsky]

In order to address requests from the customers and debug the driver more effectively, we need a debugging tool

1. We need to understand better what’s going on with the driver
2. Customers/support engineers need to understand better how to configure it
3. At some point we’ll need a tool to provide remote support for a Customer

The main metrics to achieve:

• What information is written and where it’s mapped in the COW file?
• How many free blocks have we still got there?
• How many disk IO per second take place?
• What is an average device throughput?
• How much RAM is used by the driver in real time?
• What is the bio request latency? Are there bottlenecks anywhere?
• Any errors during the operation?

For the implementation, Netlink sockets are proposed. The debug information will be streamed locally, where the proxy utility translates it to the usable form for the further redirect. For the nearest time and internal debugging, the simple architecture is proposed:

elastio-snap -> proxy -> GUI application

The goal is to create the skeleton, estimate its pros and cons, and decide if it fits our needs.

[anelson]

Questions:

• Will this be on by default, or customers need to enable it?
• What is the performance impact of enabling this instrumentation?
• How can we get the results of this instrumentation from the system where the driver is operating?
• Would the elastio CLI be modified to support this? If not how will support be implemented?

[skypodolsky]

@anelson

1. The functionality will be enabled with the module parameter, but an additional build parameter will be added to exclude this from the code if needed. At the time being this will be used for internal debugging purposes, so by default and in the nearest perspective, this functionality will be disabled. It needs to be added that we won't stream any content in the telemetry: only information about the bio requests/cow mapping;
2. I predict the performance impact as 'negligible' as the main load will be exerted on the network subsystem. The load on the network subsystem, in its turn, will also be insignificant;
3. For the nearest future it is considered that we'll have netlink messages to be parsed and redirected to the GUI with the proxy utility. elastio CLI can be, but not required to be modified; It seems that it might be used as a proxy in the future to stream data to the additional AWS instance.