Due to the very positive customer feedback on our extended MSSQL performance
monitoring article, I would like to briefly highlight this functionality.
We have been implementing systems for MSSQL performance monitoring for a long
time, offered either as a managed IT service, or on-premise depending on the
requirements.
Previously, we recorded and evaluated counters such as CPU, memory KPI’s, I/O KPIs, performance counters, wait statistics, memory breakdowns, transaction log activity, etc. We would then frame them as a historical comparison for each counter individually.
Here’s a dashboard that illustrates what I mean:
Now let’s go one step further.
It’s clear that as soon as performance problems occur on a MSSQL database, these metrics are no longer sufficient for accurate error analysis. That’s why we’ve extended MSSQL performance monitoring to analyze long transactions, head blockers and deadlocks.
This means that we not only measure the number or duration, e.g. of long
transactions, but also the user, host name, etc. from which each
transaction was generated. This is an essential part of an effective
performance analysis by a DBA.
Here’s a screenshot showing an example Long Transactions analysis:
To implement this functionality, we again use InfluxDB with Grafana dashboarding. We fill the Influx database via the Telegraf agent, which runs on the MSSQL server and reads the necessary information from the MSSQL instance via the scripts we have created.
I started my professional career as a system administrator.
Over the years, my area of responsibility changed from administrative work to the architectural planning of systems.
During my activities at Würth IT Italy, the focus of my area of responsibility changed to the installation and consulting of the IT system management solution WÜRTHPHOENIX NetEye.
In the meantime, I take care of the implementation and planning of customer projects in the area of our unified monitoring solution.
Author
Tobias Goller
I started my professional career as a system administrator.
Over the years, my area of responsibility changed from administrative work to the architectural planning of systems.
During my activities at Würth IT Italy, the focus of my area of responsibility changed to the installation and consulting of the IT system management solution WÜRTHPHOENIX NetEye.
In the meantime, I take care of the implementation and planning of customer projects in the area of our unified monitoring solution.
A safer way to run privileged Windows checks with SystemRunner If you’ve been monitoring Windows for a while, you’ve probably seen this pattern: some checks must run as LocalSystem (S-1-5-18), and the “quick fix” is to run the Icinga Agent Read More
With the upgrade to NetEye 4.44, we've added a lot of new features (https://www.neteye-blog.com/2025/10/neteye-4-44-release-notes/) and, from my point of view, one of the most relevant is the introduction of Elastic Stack 9. This Elasticsearch major release (https://www.elastic.co/guide/en/elastic-stack/9.0/elastic-stack-release-notes.html) includes some new Read More
In NetEye, 'business processes' is a module used to model and monitor the business process hierarchy to obtain a high-level view of the status of critical applications. In short, they allow monitoring controls of individual components to be aggregated into Read More
If you've worked with Elastic APM, you're probably familiar with the APM Server: a component that collects telemetry data from APM Agents deployed across your infrastructure. But what happens when you need to segregate that data by tenant, especially in Read More
In the first part we created hosts and services to monitor a sequence of script using Tornado. The Tornado Rule Now let's continue with the creation of a Tornado rule: open the NetEye web interface and select Tornado dashboard, then Read More