If an WMI query were to return an empty result set, trying to access the
first element in the result set would result in a `panic: runtime error:
index out of range` error.
add logic to explicitly check if the result set size is 0 and return an
error rather.
Fixes https://github.com/martinlindhe/wmi_exporter/issues/240
the only sql servers I have access to are using the default
`MSSQLSERVER` instance names. I was contacted by someone using a
different instance name and it was failing.
Found 2 bugs in the code:
1) I was returning the default `MSSQLSERVER` as an instance even if it wasn't found in the registry
2) learned that the WMI class naming scheme for non-default instances
was not what I had coded. Changed to incorproate new knowledge.
removed persec from variable names
but when I did that, there was some variable name collisions, so I went
through and name-spaced the class variables.
1
in the process of trying to build a grafana dashboard with "useful"
mssql metrics, I was looking around for what metrics might be useful and
came across an article of [15 SQL Server Performace Counters to Monitor](https://blogs.sentryone.com/allenwhite/sql-server-performance-counters-to-monitor/)
two of the suggested metrics are provided by the AccessMethod
class, which I was not yet capturing.
So I added metrics for the
Win32_PerfRawData_MSSQLSERVER_SQLServerAccessMethods class.
so that the two functions that list available child collectors are next
to each other - should make less likely to not miss editing one of those
when adding additional wmi classes
also removed the 'filter' from the `mssqlFilterAvailableClassCollectors`
function as it's not filtering anyting.
modify the `process` collector so that the IIS worker process name is
appended to the corresponding `w3wp` process.
before:
```
wmi_process_private_bytes{creating_process_id="2068",process="w3wp",process_id="12308"} 7.18204928e+08
```
after:
```
wmi_process_private_bytes{creating_process_id="2068",process="w3wp_our.website.com",process_id="12308"} 7.18204928e+08
```
reason:
We have some IIS servers hosting many .NET applications. When there is
resource contention on one of those servers, it's nice to know which IIS
application pool is the culprit. Having only the process_id to
differentiate between w3wp processes requires additional work to figure
out which is which. Also it does not allow for historial trending as
the process_id can change across restarts.
