Add support for MSSQL Transactions counters

[btshft]

Pull request changes:

• Add support for Transactions counters
• Fix wrong counter name for errors count (Add support for SQL Errors counter #370). I forgot to push changes, sorry :(

Also I'm not pretty happy with some counter names:

transactions_nonsnapshot_version_active_total
transactions_snapshot_active_total
transactions_active_total
transactions_update_snapshot_active_total

If follow the original microsoft naming pattern, they should be called

transactions_nonsnapshot_version_transactions
transactions_snapshot_transactions
transactions_transactions
transactions_update_snapshot_transactions

It's again a bit redundant, so I replaced the transactions suffix with active_total which is more appropriate in terms of Prometheus naming convention. I decided to add active because microsoft docs says about only active transactions but not transactions at all. This detail may not be obvious if we use just total prefix. But as I mentioned I'm not really sure if this decision is trully correct. Therefore if there are any suggestions on how names can be enchanced, feel free to share them :)

[carlpett]

Overall looks good, thanks! Some naming comments

[carlpett]

Given the name of the data, this needs to be normalized to bytes, I suppose?

[carlpett]

Same kilobytes->bytes here.

[carlpett]

More kilobytes

[carlpett]

Make sure these matches the name of the actual metric we expose, if it is not the same as the WMI name or we improved the naming.

[carlpett]

It's again a bit redundant, so I replaced the transactions suffix with active_total which is more appropriate in terms of Prometheus naming convention. I decided to add active because microsoft docs says about only active transactions but not transactions at all. This detail may not be obvious if we use just total prefix. But as I mentioned I'm not really sure if this decision is trully correct.

In general, I find it more important for us to have good metric names that indicate what they mean, vs staying close to Microsoft naming. So having active_total for example is a good thing :)

[btshft]

@carlpett Thanks for sensible comments! They're fixed now

[carlpett]

Nice 🎉
Just noticed one metric on the second read-through that I missed - transactions_update_conflict_ratio. What are some typical values you can read from this one? I would suspect this is actually not a ratio that we get from WMI, but rather the total count. Could you see if that is the case?
Apart from that, looks good to me!

[btshft]

What are some typical values you can read from this one? I would suspect this is actually not a ratio that we get from WMI, but rather the total count. Could you see if that is the case?

If we can rely on Microsoft docs it says about percentage ratio not just count.

The percentage of those transactions using the snapshot isolation level that have encountered update conflicts within the last second. [...]

Also I found mention of counter in SQL Server book that defines it as follows

This counter monitors the ratio of update snapshot transactions that have update conflicts. It's the ratio of the number of conflicts compared to the total number of update snapshot transactions.

But true this or not I can only check tomorrow on staging db. On my laptop value of counter is just pointless 0 :(

[btshft]

Actually I found a way to look counter values on staging db and Update conflict ratio equals to 1476 and also there is Update conflict ratio base which is equal to 7175995. So you're right it's not looks like some sort of ratio and more seems to be total_count or something else.

I suppose the real ratio can be calculated as:
(update_conflict_ratio / update_conflict_ratio_base) * 100 so we need to expose both update_conflict_ratio and update_conflict_ratio_base. But I'm confused about how metrics should be named.

[carlpett]

Ah, as I suspected then.

If we can rely on Microsoft docs it says about percentage ratio not just count.

Thing is, we can't, a lot of the time. Since we use the PerfRaw values, but the docs are about the "cooked" values, ie after they have some calculation performed on them. In this case, dividing by the base value (which tends to be total number of seconds elapsed since counting started, or similar)

Usually what we do is then just expose the nominator as a counter, so you'd rename it as update_conflicts_total. Prometheus can then help us calculate rates over different time periods as needed.

[btshft]

Got the idea, thanks! Honestly, these unobvious things make me frustrated. The documentation talks about one thing when counter values are completely different and have nothing to do with docs 😬. Will fix naming soon

[carlpett]

Yes, I know. We should write something up about how to understand what they really mean. But time is a bit limited, so we still haven't managed to do so. We're sorry that it leads to frustrations for you and other contributors!

[carlpett]

This looks good now, thanks a lot for your contribution!