Sql Server - Disk Space Measurement

[Trovalo]

Required for all PRs:

• Signed CLA.
• Associated README.md updated.
• Has appropriate unit tests.

This is a new measurement (only for query v2) which returns disk space data for the disks related to Sql Server (in which there is at least one db or log file)
The measurement has the following structure
Measurement: sqlserver_disk_space
Tags:

• server_name (useful when monitoring a remote instance)
• sql_instance
• volume_mount_point

Fields:

• available_space_bytes
• total_space_bytes
• used_space_bytes

The measurement has the same naming convention and calculation rules (for tag values) of the other measurements.

Note that this measurement does not work (and does not make sense) on Azure SQL DB since the queried tables do not exist. If enabled on Azure SQL DB nothing will happen (the query won't be executed)

Why is it useful

• Having this data is relevant for the monitoring of databases, it allows you to avoid problems like a full disk and databases unable to grow
• It can be used on remote instances (the Windows plugin cannot be used on remote instances afaik)

Readme update
The readme has been updated to add this new query in the available query list, and other slight changes have been made, i.e. the list now shows which queries are available in which version

Tests
it has been tested on:

• SQL Server 2012
• SQL Server 2019
• Azure SQL DB (even if enabled it does nothing)

[Trovalo]

Looks like something like this exists in version 1 of the queries, it's called "VolumeSpace", since this PR adds the same thing to v2 queries is probably better to rename it to match the name in v1. (I will do it later)

[Trovalo]

the name has been changed to match the query v1 name (VolumeSpace).
I've looked at the tests, the v2 queries are used only in one test which has been changed accordingly.

[danielnelson]

@denzilribeiro can you take a look?

[denzilribeiro]

@Trovalo this isn't relevant for managed instances and that isn't excluded as of now - Also somewhere in readme collecting this at 10 second interval is totally overkill, as it isn't something that changes often so should be collected with much lower frequency.

[Trovalo]

I will exclude the SQL Managed Instance from the execution.
About the frequency, I know that it does not make sense to run this every 10s, that's why it has his own measurement (so you can override the interval), but the query itself is not heavy and even if it runs every 10s there should be no problems.

I will add something more in the readme specifying both those points