New component: SQL Server Receiver

[StefanKurek]

The purpose and use-cases of the new component

The SQL Server Metric Receiver would pull KPI stats from windows performance counters using the windowsperfcountersreceiver as a base to build off of.

Targeted versions would be Microsoft SQL Server 2012+ as this is the oldest version with any support EOL

Example configuration for the component

collection_interval (default = 10s): This receiver collects metrics on an interval. Valid time units are ns, us (or µs), ms, s, m, h.

receivers:
  sqlserver:
    collection_interval: 10s

Telemetry data types supported

Metrics

[codeboten]

Thanks for proposing the new component @StefanKurek! I haven't interacted with SQL server in some time, so apologies if my questions are naive.

Are there any metrics that would not be available through the windows performance counters and would require connecting to the SQL server directly? What would the configuration on the SQL server look like for users?

It looks like the telegraf plugin suggests some additional configuration, would these be desirable here?

[StefanKurek]

@codeboten Hello. Those are good questions for sure. Most of the commonly used metrics are available in the windows performance counters (which matches up more or less with the sys.dm_os_performance_counters view of SQL Server). There are other metrics that can be collected through the querying of different views or stored procedures. And yes, to collect them would require a different set of config options (endpoint/user/pass/database/etc) to connect directly to the database, but I think there is a case for focusing on just the windows performance counters off the bat.

[djaglowski]

I'd like to sponsor this.

Direct connection can provide more information, but this approach does provide a lot of value for very little effort on the user's part.

I agree w/ @StefanKurek that direct connection functionality could be added later too. The main challenge there could be in managing overlap between metrics, if querying sys.dm_os_performance_counters gives slightly different values. Ultimately though, if the those values are meaningfully different then we should have a good case for defining separate metrics. Otherwise, we can reconcile them and give the user the choice of which way to collect them.

[djaglowski]

Closed by #9252