The Silent Screen
The Network Operations Center hummed its usual lullaby of cooling fans and low conversation. On the wall, a massive screen displayed a constellation of green dots—each one a server, a service, a heartbeat. In the center of that constellation, glowing a steady, reassuring emerald, was Zabbix.
Leila, the senior on-call engineer, nursed her third coffee of the morning. She glanced at the dashboard. All green. A quiet Tuesday.
Then, at 10:03 AM, she saw it. Not an alarm. Not a siren. An absence.
A single widget on her secondary monitor, the one dedicated to the MSSQL cluster that handled all customer transactions, was… blank. The graph that should have been a lively, jagged line showing query response times was a flat, grey void.
She clicked on the item: MSSQL: User activity per minute.
The status read: "Failed to fetch info data."
Leila frowned. Zabbix never screamed. It whispered. And this whisper was wrong.
She checked the logs. The last successful data pull from the database was 28 minutes ago. The Zabbix proxy, which sat in the DMZ, was sending heartbeats. The firewall rules were intact. The user account zabbix_svc had the right permissions. The ODBC driver was there.
Thirty minutes.
She called Tom, the database admin. "Hey, look at your SQL server. Zabbix is blind." zabbix mssql failed to fetch info data -or no data for 30m-
Tom pulled up his own tools. "It's up. CPU 12%. Memory fine. Locks… no deadlocks. Connections…" He paused. "Huh. I see the Zabbix proxy connected. But it's just… waiting."
"Waiting for what?"
"An answer," Tom said quietly. "The query is SELECT COUNT(*) FROM transactions WHERE timestamp > DATEADD(minute, -5, GETUTCDATE()). It should return in milliseconds. But the execution plan shows a table scan on a table with 2.3 billion rows."
Leila’s blood went cold. "The maintenance job."
Two weeks ago, they had disabled the weekly index rebuild on the transactions table to speed up a different report. They had forgotten to re-enable it. The indexes had fragmented into digital gravel. A simple count query now took the server hostage.
She watched the clock tick over to 10:33 AM.
Thirty minutes. "No data for 30m."
Now Zabbix screamed. The silence broke. Yellow alerts turned to red. A cascade of triggers fired: Zabbix agent on MSSQL01 is unreachable, Template DB MSSQL: Lack of available memory, No data from Database for 30 minutes.
The customer portal, which relied on that data for a "system status" widget, showed a spinning circle. Then a dash. Then a blank page.
Leila didn't reach for her coffee. She reached for her terminal. The Silent Screen The Network Operations Center hummed
She bypassed Zabbix entirely. She logged into the SQL server via an emergency admin account and issued the kill command for the orphaned Zabbix query. Then, with shaking fingers, she typed:
ALTER INDEX ALL ON transactions REBUILD;
She watched the percentage crawl from 0 to 100. Four minutes.
After the rebuild, she restarted the Zabbix proxy agent. In her dashboard, the grey void flickered. Then a single dot of data appeared. Then a line. Then the familiar, jagged, living waveform of a healthy database.
The green lights returned.
Leila slumped back in her chair. Zabbix hadn't failed. It had done exactly what it was supposed to do: it reported an absence. The failure had been human—a forgotten index, an ignored whisper.
She wrote in her post-mortem: "Zabbix did not lose the data. We lost the ability to fetch it. The silence was the alarm."
You’ve configured Zabbix to monitor your critical Microsoft SQL Server instances. The templates are applied, the user macro is set, and for a few hours, everything looks perfect. Then, without warning, your dashboard turns grey. The dreaded error appears:
“Failed to fetch info data from database.”
Or worse:
“No data for 30 minutes.”
Your database is still running. Queries are working. But Zabbix has gone blind. In the world of infrastructure monitoring, no data is often more dangerous than bad data. It creates false confidence, hides disk space exhaustion, and masks deadlocks until users start screaming.
This 3,000+ word guide will leave no stone unturned. We’ll cover the root causes, the debugging workflow, and the permanent fixes for the Zabbix-MSSQL integration breakdown.
On the same SQL host, enable:
zabbix[agent,version]zabbix[process,<type>,<param>]proc.num[zabbix_agentd]Trigger on nodata(5m) for a known always-increasing counter like system.uptime. If uptime stops reporting, your whole SQL monitoring is dead.
If you monitor dozens of SQL Server instances per agent, the default polling may collapse.
Apply these in zabbix_agentd.conf:
StartAgents=32
Timeout=30
ODBCPoolSize=100
EnableRemoteCommands=1
Restart the agent. Also, spread items across multiple trapper items or use a Zabbix proxy for distributed SQL monitoring.
Disclaimer: This paper is for informational purposes. Always test configuration changes in a non‑production environment first.
From the Zabbix server or proxy:
isql -v MSSQL_DSN zabbix_user 'password'
SELECT GETDATE();
If manual fails, the issue is OS/ODBC layer.
zabbix_server.conf or zabbix_agentd.conf) for any errors or typos.