🚨 Telegraf Error Guide: '[inputs.sqlserver] Login failed for user' — Fix SQL Server Auth

Overview

The sqlserver input connects to Microsoft SQL Server and runs DMV queries to collect performance metrics. When the login in the connection string is rejected, Telegraf logs the driver’s authentication error:

2026-07-10T12:00:00Z E! [inputs.sqlserver] Error in plugin: mssql: login error: Login failed for user 'telegraf'. (18456)

A permission-level variant appears once login succeeds but the account cannot read the DMVs the plugin needs:

E! [inputs.sqlserver] Error in plugin: mssql: VIEW SERVER STATE permission was denied on object 'server', database 'master'. (300)

Either way, no sqlserver_* metrics are produced for that instance until authentication and permissions are correct.

Symptoms

• All sqlserver_* metrics for an instance are missing while other inputs work.
• journalctl -u telegraf repeats Login failed for user (error 18456) or VIEW SERVER STATE ... denied (error 300).
• sqlcmd with the same credentials fails identically, confirming it is not a Telegraf-specific issue.
• Login works interactively but fails from Telegraf due to an encryption/TrustServerCertificate mismatch.
• The error appears only after a password rotation or a SQL Server upgrade that changed default TLS behavior.

Common Root Causes

• Wrong username or password — a typo, an unescaped special character in the connection string, or a stale password after rotation.
• Login disabled or expired — the SQL login is disabled, locked out, or has an expired password.
• SQL vs. Windows authentication mismatch — using a SQL login on an instance set to Windows-only auth, or vice versa.
• Missing VIEW SERVER STATE — login succeeds but the account lacks the server-level permission the DMV queries require.
• Encryption/TLS mismatch — SQL Server 2022+ defaults to encrypted connections; without encrypt=true;TrustServerCertificate=true (for self-signed certs) the handshake or login fails.
• Wrong database or instance — connecting to a named instance or port that does not host the login.
• Firewall blocking TCP/1433 — the connection never reaches the instance.

Diagnostic Workflow

Reproduce the login outside Telegraf with sqlcmd (or go-mssqldb test) from the Telegraf host. If sqlcmd fails the same way, fix SQL Server, not Telegraf:

sqlcmd -S sql01.internal,1433 -U telegraf -P "$SQL_PASS" -Q "SELECT SUSER_NAME();"

Confirm the port is reachable:

nc -z -v sql01.internal 1433

Run only the sqlserver input under Telegraf with debug:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter sqlserver --debug

A correct connection string sets the encryption parameters explicitly (required on modern SQL Server):

[[inputs.sqlserver]]
  servers = ["Server=sql01.internal;Port=1433;User Id=telegraf;Password=${SQL_PASS};app name=telegraf;log=1;encrypt=true;TrustServerCertificate=true;"]
  database_type = "SQLServer"

On the SQL Server side, create a least-privilege login and grant the one permission the plugin needs:

-- Run as an admin in SSMS / sqlcmd
CREATE LOGIN telegraf WITH PASSWORD = 'REDACTED', CHECK_POLICY = ON;
GRANT VIEW SERVER STATE TO telegraf;
GRANT VIEW ANY DEFINITION TO telegraf;

Confirm the login is enabled and its auth mode matches the server:

SELECT name, is_disabled FROM sys.sql_logins WHERE name = 'telegraf';

Example Root Cause Analysis

After upgrading to SQL Server 2022, a previously working Telegraf instance began logging Login failed for user 'telegraf'. (18456). The credentials had not changed, and sqlcmd -S sql01,1433 -U telegraf -P ... (which negotiates encryption automatically) still worked — but Telegraf’s connection string was Server=sql01;User Id=telegraf;Password=...; with no encryption parameters.

SQL Server 2022 enables mandatory encryption by default. Telegraf’s go-mssqldb driver, without encrypt=true;TrustServerCertificate=true, failed the TLS negotiation against the instance’s self-signed certificate, and the server surfaced the failure as a login error (18456). Adding the encryption parameters fixed it:

[[inputs.sqlserver]]
  servers = ["Server=sql01.internal;Port=1433;User Id=telegraf;Password=${SQL_PASS};encrypt=true;TrustServerCertificate=true;app name=telegraf;"]

After the change, telegraf --test --input-filter sqlserver returned sqlserver_performance metrics. The lesson: on modern SQL Server, an 18456 “login failed” is frequently a TLS/encryption mismatch rather than a bad password — reproduce with a client that negotiates encryption the same way, and set encrypt/TrustServerCertificate explicitly in the connection string.

Prevention Best Practices

• Store the password in an environment variable (${SQL_PASS}) referenced from the config, never inline in version control.
• Create a dedicated least-privilege login with only VIEW SERVER STATE (and VIEW ANY DEFINITION where needed) — never use sa.
• Set encrypt and TrustServerCertificate explicitly to match the server’s TLS posture, especially on SQL Server 2022+.
• Reproduce credentials with sqlcmd from the Telegraf host as part of onboarding each instance.
• Update the Telegraf password immediately as part of any SQL login rotation runbook to avoid crash-looping auth errors.
• Open TCP/1433 (or the named-instance port) from the Telegraf host to the database, and document the source subnet.

Quick Command Reference

# Reproduce the login from the Telegraf host
sqlcmd -S sql01.internal,1433 -U telegraf -P "$SQL_PASS" -Q "SELECT SUSER_NAME();"

# Check port reachability
nc -z -v sql01.internal 1433

# Run only the sqlserver input with debug
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter sqlserver --debug

# On SQL Server: grant the permission the plugin needs
#   GRANT VIEW SERVER STATE TO telegraf;

# Watch auth errors live
journalctl -u telegraf -f | grep -i sqlserver

Conclusion

[inputs.sqlserver] Login failed for user (error 18456) means SQL Server rejected the login — a wrong or rotated password, a disabled login, an auth-mode mismatch, or, on modern SQL Server, a TLS/encryption mismatch in the connection string. Reproduce with sqlcmd from the Telegraf host, set encrypt/TrustServerCertificate explicitly, and grant the login VIEW SERVER STATE for the DMV queries. Once a least-privilege login authenticates cleanly, SQL Server performance metrics flow into your pipeline.