Solucionar problemas de configuración de DBM (Database Monitoring) para SQL Server
En esta página se detallan los problemas más comunes relacionados con la configuración y el uso de Database Monitoring con SQL Server y se explica cómo resolverlos. Datadog recomienda utilizar la última versión estable del Agent y seguir la última documentación de configuración, ya que puede cambiar según las versiones del Agent.
Diagnóstico de problemas comunes de conexión
SQL Server no se puede conectar ‘Login Failed for user’
El Agent puede conectarse a una instancia de SQL Server de dos maneras:
Autenticación de Windows (sólo disponible en hosts de Windows)
Autenticación de SQL Server
Windows es el modo de autenticación por defecto y es más seguro que la autenticación de SQL Server. Cuando se utiliza la autenticación de Windows, se pueden crear grupos de Windows a nivel de dominio y se puede crear un inicio de sesión en SQL Server para todo el grupo. Para utilizar la autenticación de Windows debes:
Utilizar la cuenta de servicio creada en el momento de instalación del Agent y asegurarte de que esta cuenta tiene el acceso adecuado a SQL Server.
Configurar connection_string: "Trusted_Connection=yes"
y omitir los campos username
y password
. El atributo de conexión Trusted_Connection=yes
indica al controlador de bases de datos OLE para SQL Server que debe utilizar la autenticación de Windows para validar el inicio de sesión.
Las autenticaciones de SQL Server no se basan en cuentas de usuario de Windows, sino que se crean en la instancia y se almacenan en el propio SQL Server. La autenticación de SQL requiere definir el username
y el password
en la configuración de la instancia de SQL Server para la conexión.
Si se produce un error de inicio de sesión al conectarse, es importante comprobar primero que puedes acceder a la instancia como usuario del Datadog Agent. Una forma sencilla de hacerlo es a través de una utilidad de línea de comandos como sqlcmd
.
Por ejemplo:
# este ejemplo utiliza la autenticación de SQL
sqlcmd -S <INSTANCE_ENDPOINT> -U datadog -P <DATADOG_PASSWORD> -d master
# este ejemplo utiliza la autenticación de Windows
# Ejecuta este comando en powershell seleccionando la opción `run as user...` para que se ejecute como el ddagentuser
sqlcmd -S <INSTANCE_ENDPOINT> -d master -E
Si el usuario datadog
no puede acceder a la instancia de SQL Server, asegúrate de que el usuario ha sido creado y se le han dado los permisos adecuados de acuerdo con la documentación de configuración.
Microsoft también ofrece un documento útil para solucionar este tipo de errores, que puedes consultar aquí.
Error de conexión TCP de SQL Server
Los problemas de conexión TCP son comunes cuando hay un error de configuración con el Agent. Los mensajes de error proporcionados por el controlador no siempre son claros.
Por ejemplo, el siguiente error se debe a que ha fallado la conexión TCP:
TCP-connection(ERROR: getaddrinfo failed). Exception: unable to connect: could not open database requested by login
Algunos errores comunes son:
“Login failed for user”: significa que el Agent ha conseguido establecer una conexión con el host, pero el inicio de sesión ha sido rechazado por alguna razón.
Para solucionar este problema:
Comprueba las credenciales de inicio de sesión del Agent.
Intenta iniciar sesión con esas credenciales manualmente utilizando sqlcmd. Por ejemplo: sqlcmd -S localhost -U datadog -P ${SQL_PASSWORD} -d master
.
“Could not open database requested for login”: este error aparece debido a problemas de red o debido a una base de datos desconocida.
Para solucionar este problema:
Comprueba la conexión TCP del Agent al host ejecutando telnet {host} {port}
para asegurarte de que existe una conectividad de red del Agent a la base de datos.
Intenta iniciar sesión manualmente utilizando sqlcmd y observa si existe algún error en la base de datos configurada. Por ejemplo: sqlcmd -S localhost -U datadog -P ${SQL_PASSWORD} -d master
.
Debido a “Atributo de cadena de conexión no válido”
Los siguientes proveedores ADO son compatibles con Windows: SQLOLEDB
, MSOLEDBSQL
, MSOLEDBSQL19
, SQLNCLI11
.
Los proveedores SQLOLEDB
y SQLNCLI11
podrían mostrar el mensaje de error Invalid connection string attribute
debido a varios problemas. Por ejemplo:
datadog_checks.sqlserver.connection.SQLConnectionError:
Unable to connect to SQL Server for instance foo.com,1433 - master:
OperationalError(com_error(-2147352567, 'Exception occurred.',
(0, 'Microsoft OLE DB Provider for SQL Server',
'Invalid connection string attribute', None, 0, -2147467259), None),
'Error opening connection to "ConnectRetryCount=2;Provider=SQLOLEDB;Data Source=foo.com,1433;Initial Catalog=master;User ID=datadog;Password=******;"')
Este mismo error se muestra independientemente del motivo del fallo (por ejemplo, debido a un nombre de host desconocido, a que la conexión TCP no se ha establecido, a que las credenciales de acceso no son válidas o a que la base de datos es desconocida).
Busca los códigos de error HResult en el mensaje de error. Estos son ejemplos de códigos conocidos:
-2147217843
“Login failed for user”: significa que el Agent ha conseguido establecer una conexión con el host, pero el inicio de sesión ha sido rechazado por algún motivo.
-2147467259
“Could not open database requested for login”: este error aparece debido a problemas de red o debido a una base de datos desconocida.
Si ninguno de los dos pasos te ayuda a resolver el problema o si el código de error que ves no aparece en la lista, Datadog te recomienda utilizar el controlador MSOLEDBSQL
o el Microsoft ODBC Driver for SQL Server
. Los controladores proporcionan mensajes de error más detallados, que pueden ayudarte a determinar por qué está fallando la conexión.
SQL Server ‘Unable to connect: Adaptive Server is unavailable or does not exist’
Algunas veces, este error puede deberse a que no se ha configurado correctamente el campo host
. Para la integración, configura el campo host
con la siguiente sintaxis: host:server,port
.
Por ejemplo, si has configurado host
de esta manera:
host: sqlserver-foo.cfxxae8cilce.us-east-1.rds.amazonaws.com
Debes añadir el puerto y configurarlo como se indica a continuación:
host: sqlserver-foo.cfxxae8cilce.us-east-1.rds.amazonaws.com,1433
Proveedor SSL: La cadena de certificados ha sido emitida por una autoridad que no es de confianza
Controlador de bases de datos OLE Microsoft 2019
Este error es común después de actualizar al controlador MSOLEDBSQL
2019 debido a los cambios de última hora que se han introducido. En la última versión del controlador, todas las conexiones a la instancia SQL están cifradas por defecto.
Si estás utilizando la última versión del controlador de bases de datos OLE Microsoft para SQL Server e intentas conectarte a una instancia de SQL Server que requiere conexiones cifradas, puedes utilizar una de las siguientes soluciones alternativas:
Si utilizas un certificado autofirmado y el parámetro Forzar cifrado en el servidor (rds.force_ssl=1
en AWS) para garantizar que los clientes se conectan mediante cifrado:
- Cambia a un certificado de confianza como parte de la cadena de confianza del cliente.
- Añade el certificado autofirmado como certificado de confianza en el cliente.
- Añade
Trust Server Certificate=True;
a la cadena de conexión.
Este procedimiento se describe con más detalle en la documentación de Microsoft.
- Si tu instancia de SQL Server no requiere cifrado para conectarse (
rds.force_ssl=0
en AWS), entonces actualiza la cadena de conexión para incluir Use Encryption for Data=False;
. Por ejemplo:
# example uses windows authentication
instances:
- host: <INSTANCE_ENDPOINT>,<PORT>
connection_string: "Trust Server Certificate=True;Use Encryption for Data=False;"
connector: adodbapi
adoprovider: MSOLEDBSQL19
- Instala la versión 2018 del controlador MSOLEDBSQL, que no utiliza cifrado por defecto. Luego de instalar el controlador, actualiza
adoprovider
a MSOLEDBSQL
. Por ejemplo:
# example uses windows authentication
instances:
- host: <INSTANCE_ENDPOINT>,<PORT>
connection_string: "Trusted_Connection=yes;"
connector: adodbapi
adoprovider: MSOLEDBSQL
Otras versiones de controladores de bases de datos OLE y ODBC de Microsoft
Si utiliza un controlador de bases de datos OLE distinto de MSOLEDBSQL
2019 o de los controladores ODBC, este error puede resolverse configurando TrustServerCertificate=yes
en la cadena de conexión. Por ejemplo, para el controlador ODBC
:
# este ejemplo utiliza la autenticación de SQL Server
instances:
- host: <INSTANCE_ENDPOINT>,<PORT>
username: datadog
password: <DD_AGENT_PASSWORD>
connection_string: "TrustServerCertificate=yes;"
connector: odbc
driver: '{ODBC Driver 18 for SQL Server}'
SQL Server no puede conectarse ‘SSL Security error (18)’
Se trata de un problema conocido para versiones antiguas del controlador ODBC de SQL Server. Puedes comprobar qué versión del controlador utiliza el Agent consultando la cadena de conexión en el mensaje de error.
Por ejemplo, si ves Provider=SQL Server
en la cadena de conexión del mensaje de error, la actualización a una versión más reciente del controlador ODBC solucionará el error.
Este problema se describe con más detalles en esta entrada del blog de Microsoft
Cadena de conexión vacía
El check de SQL Server de Datadog se basa en la biblioteca Python adodbapi
, que tiene algunas limitaciones en cuanto a los caracteres que puede utilizar para establecer una cadena de conexión con un SQL Server. Si tu Agent tiene problemas para conectarse a tu SQL Server y si encuentras errores similares a los siguientes en los logs del recopilador de tu Agent, es posible que tu sqlserver.yaml
incluya algunos caracteres que causan problemas con adodbapi
.
OperationalError: (KeyError('Python string format error in connection string->',), 'Error opening connection to ""')
Por el momento, el único carácter conocido que causa este problema específico de conectividad es el carácter %
. Si necesitas utilizar el carácter %
en tu archivo sqlserver.yaml
(por ejemplo, si tu contraseña de usuario de SQL Server de Datadog incluye un %
), debes escapar este carácter incluyendo un doble %%
en lugar de cada %
simple.
Diagnóstico de problemas comunes del controlador de SQL Server
No se ha encontrado el nombre de la fuente de datos y no se ha especificado ningún controlador por defecto
Este es un error comúnmente visto en Linux cuando se utiliza la configuración por defecto para el controlador ODBC. Esto puede ocurrir debido a que el DSN, que se configura para el controlador en el archivo /etc/odbcinst.ini
, no coincide con el nombre del controlador configurado en tu Agent.
Por ejemplo, si quieres utilizar el controlador ODBC predeterminado para el Agent ({ODBC Driver 18 for SQL Server}
), la configuración de tu instancia debe contener lo siguiente:
Cuando el Agent se inicia e intenta establecer una conexión con tu instancia de SQL Server, busca el archivo /etc/odbcinst.ini
para encontrar la ruta a los binarios del controlador.
Por ejemplo, este archivo /etc/odbcinst.ini
configura el controlador:
```text
$ cat /etc/odbcinst.ini
[ODBC Driver 18 for SQL Server]
Description=Microsoft ODBC Driver 18 for SQL Server
Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.7.0
UsageCount=1
```
El DSN en el ejemplo anterior es [ODBC Driver 18 for SQL Server]
, que coincide con el nombre del controlador por defecto que está utilizando el Agent. Si el DSN de tu controlador no coincide con el nombre del controlador que está utilizando el Agent, obtendrás el error Data source not found
.
Es posible definir dsn
en la configuración de tu instancia para que coincida con lo definido en el archivo /etc/odbcinst.ini
. Por ejemplo:
```text
$ cat /etc/odbcinst.ini
[Custom]
Description=Microsoft ODBC Driver 18 for SQL Server
Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.7.0
UsageCount=1
```
En la configuración de tu instancia, deberías definir el campo dsn
:
connector: odbc
dsn: "Custom"
Proveedor o controlador no encontrado
Este mensaje de error puede variar de un controlador a otro, pero normalmente tiene el siguiente aspecto en ODBC
:
Can't open lib .* file not found
Data source name not found.* and no default driver specified
Y para los proveedores de MSOLEDBSQL
, el mensaje de error tiene el siguiente aspecto:
```text
No es posible encontrar el proveedor. Es posible que no esté instalado correctamente.
Esto significa que el controlador o el proveedor no está instalado correctamente en el host en que se ejecuta el Agent. Debes asegurarte de que has seguido todas las instrucciones de instalación del controlador que has decidido utilizar.
Es posible que el Agent no encuentre el controlador. Esto sucede con mayor frecuencia en los controladores ODBC en Linux. Para obtener más instrucciones sobre cómo instalar el controlador ODBC en Linux, consulta la sección [conectarse a SQL Server en un host Linux](#connecting-to-sql-server-on-a-linux-host).
Para obtener ayuda al elegir un controlador, consulta la sección [elegir un controlador de SQL Server](#picking-a-sql-server-driver) para saber cómo configurar correctamente tu controlador con el Agent.
### Conexión a SQL Server en un host de Linux
Para conectar SQL Server (ya sea alojado en Linux o Windows) a un host de Linux:
1. Instala el [controlador ODBC de Microsoft][11] para tu distribución Linux.
Si no sabes cuál es el nombre del controlador que debes utilizar, puede encontrarlo entre paréntesis en la parte superior de `/etc/odbcinst.ini`.
```text
$ cat /etc/odbcinst.ini
[ODBC Driver 13 for SQL Server]
Description=Microsoft ODBC Driver 13 for SQL Server
Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.7.0
UsageCount=1
```
2. Copia los archivos `odbc.ini` y `odbcinst.ini` en la carpeta `/opt/datadog-agent/embedded/etc`.
3. Si es necesario, instala el módulo pyodbc. Puedes hacerlo ejecutando pip install pyodbc en el entorno Python de tu Agent. Por ejemplo:
```shell
$ sudo /opt/datadog-agent/embedded/bin/pip install pyodbc
```
3. Configura tu SQL Server `conf.yaml` para utilizar el conector odbc y especifique el controlador adecuado como se indica en el archivo `odbcinst.ini`.
```yaml
init_config:
instances:
- host: <HOST>,<PORT>
# enable the odbc connector
connector: odbc
# enable the ODBC driver
driver: ODBC Driver 13 for SQL Server
username: <USERNAME>
password: <PASSWORD>
```
### Elección de un controlador de SQL Server {#picking-a-driver}
Para que el Agent pueda conectarse a la instancia de SQL Server, debes instalar el [controlador ODBC de Microsoft][12] o el [controlador de bases de datos OLE][13].
El controlador que elijas determinará lo que configures para el campo [conector][14] en la configuración de tu instancia.
Por ejemplo, para el [controlador ODBC de Microsoft][12]:
```yaml
connector: odbc
driver: '{ODBC Driver 18 for SQL Server}'
Para el controlador de bases de datos OLE:
connector: adodbapi
adoprovider: MSOLEDBSQL
Estos valores se utilizarán para asignar la parte Provider
de la cadena de conexión.
Así, por ejemplo, si configuras adoprovider: MSOLEDBSQL
, la cadena de conexión incluirá Provider=MSOLEDBSQL
. Esto debería coincidir con el nombre de la versión del controlador que tengas instalada.
En la última versión del controlador de bases de datos OLE Microsoft, el nombre del controlador ha cambiado de MSOLEDBSQL
a MSOLEDBSQL19
, lo que significa que debería aparecer en la configuración de tu instancia de la siguiente forma:
connector: adodbapi
adoprovider: MSOLEDBSQL19
Esto se recomienda para mantener una actualización con la última versión disponible del controlador que selecciones.
Otros problemas comunes
Falta la etiqueta de usuario de SQL Server en Métricas de consultas y muestras de planes
La etiqueta user
ya no es compatible con Métricas de consultas y Muestras de planes debido a limitaciones técnicas en SQL Server que impiden la recopilación de las consultas correctas ejecutadas por el usuario.
La etiqueta user
está disponible para Eventos de actividades de consulta y Métricas de cargas de bases de datos.
¿Por qué hay tantas consultas “CREATE PROCEDURE”?
En versiones del Agent anteriores a la v7.40.0, existe un error por el que las estadísticas de PROCEDURE
se cuentan en exceso. Esto lleva a ver muchas ejecuciones de CREATE PROCEDURE...
en la interfaz de usuario de las métricas de consultas de Database Monitoring. Para solucionar este problema, actualiza a la última versión del Datadog Agent.
Limitaciones conocidas
SQL Server 2012
Las siguientes métricas no están disponible para SQL Server 2012:
sqlserver.files.read_io_stall_queued
sqlserver.files.write_io_stall_queued
sqlserver.ao.quorum_type
sqlserver.ao.quorum_state
sqlserver.ao.member.type
sqlserver.ao.member.state
sqlserver.ao.member.number_of_quorum_votes
sqlserver.ao.log_send_queue_size
sqlserver.ao.log_send_rate
sqlserver.ao.redo_queue_size
sqlserver.ao.redo_rate
sqlserver.ao.low_water_mark_for_ghosts
sqlserver.ao.filestream_send_rate
sqlserver.ao.replica_status
sqlserver.ao.secondary_lag_seconds
sqlserver.fci.status
sqlserver.fci.is_current_owner
sqlserver.latches.latch_wait_time
SQL Server 2014
Las siguientes métricas no están disponible para SQL Server 2014:
sqlserver.ao.secondary_lag_seconds
sqlserver.latches.latch_wait_time