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.
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 SQLsqlcmd -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 ddagentusersqlcmd -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í.
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.
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.
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:
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.
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 authenticationinstances:- host:<INSTANCE_ENDPOINT>,<PORT>connection_string:"Trust Server Certificate=True;Use Encryption for Data=False;"connector:adodbapiadoprovider: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 authenticationinstances:- host:<INSTANCE_ENDPOINT>,<PORT>connection_string:"Trusted_Connection=yes;"connector:adodbapiadoprovider:MSOLEDBSQL
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 Serverinstances:- host:<INSTANCE_ENDPOINT>,<PORT>username:datadogpassword:<DD_AGENT_PASSWORD>connection_string:"TrustServerCertificate=yes;"connector:odbcdriver:'{ODBC Driver 18 for SQL Server}'
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.
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.
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:
connector:odbc
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:
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}'
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:adodbapiadoprovider:MSOLEDBSQL19
Esto se recomienda para mantener una actualización con la última versión disponible del controlador que selecciones.
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.
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.
