So you have MSSQL databases and you’d like to keep an eye on the performance of your DB. Using NetEye this is quite easy. The tools you need are already available on your NetEye server: InfluxDB, the Telegraf agent, and Grafana for visualizing your Dashboards.
The SQL Server Input Plugin provides metrics for your SQL Server instance. It currently works with SQL Server versions 2008 and later. Recorded metrics are lightweight, and employ the dynamic management views supplied by SQL Server. What you need then is a login for your SQL Server created more or less with the following commands:
USE master;
GO
CREATE LOGIN [neteye] WITH PASSWORD = N'mystrongpassword';
GO
GRANT VIEW SERVER STATE TO [neteye];
GO
GRANT VIEW ANY DEFINITION TO [neteye];
GO
On your NetEye server, create a config file (/etc/telegraf/telegraf_mssql.conf) for Telegraf using this template:
Now start a Telegraf agent using that config file. Telegraf will immediately start sending data to InfluxDB. Then go to Grafana and import an “official” Dashboard using the number 4730. You will now have a very nice dashboard with all the performance data for your DB instance.
The dashboard provides KPI’s and graphs for metrics collected in real time by the Telegraf agent and stored in InfluxDB:
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Juergen Vigna
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Running Ollama locally or on dedicated hardware is straightforward until you need to know whether a model is actually loaded in RAM, how fast it generates tokens under load, or when memory consumption reaches a threshold that affects other workloads. Read More
Hello to you all. It's been a while. Don't worry though, this won't be a long and technical post. It's just to let you know I'm doing (almost) well and to tell you about our latest news. The Metrics Challenge Read More
Not long ago, I received an interesting request from one of our client’s Unix teams: They wanted a URL where the latest version of the Icinga 2 agent is always available. An important requirement was that this version should stay Read More
Hi everyone! Today I'd like to share with you an investigation we undertook related to ingesting Open Telemetry data in Elasticsearch, while maintaining tenant segregation from start to end. The Scenario Let's imagine we have multiple customers, where in this Read More
SNMP monitoring is the standard method for obtaining information and metrics from network devices. Typically, we focus on extracting data from a single interface to monitor its status, traffic, or errors. But in many cases, we’re only interested in getting Read More