Instalar y configurar NRDOT para el monitoreo de MSSQL con Helm

Puede instalar y configurar el monitoreo de SQL Server en Kubernetes usando el chart de Helm mssql-otel. Opcionalmente, el chart también puede ejecutar un trabajo de configuración que le crea el inicio de sesión de monitoreo.

Instalación guiada

Para instalar esto a través de la UI de New Relic en su lugar, vaya a one.newrelic.com > Integrations & Agents > Microsoft SQL Server (Database 360) . Siga las instrucciones en pantalla para configurar la integración. Esta página solo cubre la instalación manual.

Importante

Este chart solo admite la autenticación de SQL Server (nombre de usuario/contraseña). No admite la autenticación de Windows, la autenticación de dominio de Windows ni gMSA. El recolector siempre se conecta a SQL Server de forma remota a través de la red, ya sea que se ejecute en Linux o Windows, de forma autohospedada o en RDS, por lo que la autenticación de SQL funciona de manera idéntica en todos los casos. También informa solo las métricas de SQL Server (sin métricas de host/infraestructura), ya que el recolector se ejecuta como un despliegue de Kubernetes en lugar de en el propio host de SQL Server.

Requisitos previos

Clave de licencia de New Relic válida.
Helm 3.0 o posterior, y kubectl configurado para acceder al clúster de Kubernetes.
Conectividad de red desde el clúster de Kubernetes al host de SQL Server (o extremo de RDS) y puerto:
- Autohospedado: una ruta enrutada al host de SQL Server (VPN, peering o red compartida), y el firewall del lado de SQL Server debe permitir la IP de origen de la conexión.
- AWS RDS: interconexión de VPC, una puerta de enlace de tránsito o ubicación de VPC compartida con la instancia de RDS, y el grupo de seguridad de RDS debe permitir el puerto de SQL Server (1433 de forma predeterminada) desde el origen de salida del clúster.
Ya sea un inicio de sesión de monitoreo que ya haya creado o credenciales de administrador de SQL Server (un inicio de sesión con rol sysadmin, como sa o el usuario maestro de RDS) para que el trabajo de configuración del chart pueda crearle uno. Consulte Configurar las credenciales de monitoreo a continuación.

Cree el namespace

Cree el namespace en el que realizará la instalación. Debe existir antes de crear cualquier secreto en el siguiente paso, ya que helm install --create-namespace solo crea el namespace durante el paso de instalación final:

bash

$kubectl create namespace newrelic

Sugerencia

Establézcalo como el namespace predeterminado para el contexto kubectl actual para que no necesite pasar -n en cada comando a continuación:

bash

$kubectl config set-context --current --namespace=newrelic

Configurar las credenciales de monitoreo

Decida si desea que el trabajo de configuración del chart cree el inicio de sesión de monitoreo de SQL Server y, de no ser así, cómo proporcionará sus credenciales:

Con este método no hay un trabajo de configuración, por lo que nada aquí crea el inicio de sesión de monitoreo. Este chart solo admite la autenticación de SQL Server, por lo que antes de instalarlo, cree el inicio de sesión de monitoreo utilizando el paso de autenticación de SQL Server Crear usuario de monitoreo de Linux autohospedado, Windows autohospedado, Linux RDS o Windows RDS, según su entorno.

Configurará el nombre de usuario y la contraseña de monitoreo directamente en values.yaml en el siguiente paso.

Con este método tampoco hay un trabajo de configuración. Cree primero el inicio de sesión de monitoreo, exactamente como en el método de credenciales en texto sin formato anterior. La única diferencia es dónde residen sus credenciales: en lugar de texto sin formato en values.yaml, guárdelas en un secreto de Kubernetes:

bash

$kubectl create secret generic mssql-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

Con este método, el trabajo de configuración del chart crea el inicio de sesión de monitoreo utilizando las credenciales de administrador de SQL Server. Tanto las credenciales de monitoreo como las de administrador deben proporcionarse como secretos de Kubernetes: el trabajo de configuración nunca acepta credenciales de administrador en texto sin formato, y habilitarlo también requiere credenciales de monitoreo basadas en secretos.

Cree un secreto con el nombre de usuario y la contraseña de monitoreo. Esta es la identidad que crea el trabajo de configuración y con la que se conecta el recolector:

bash

$kubectl create secret generic mssql-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

El trabajo de configuración solo acepta credenciales de administrador a través de un secreto de Kubernetes (sin nombre de usuario/contraseña en texto sin formato en values.yaml). Dado que esta credencial puede crear inicios de sesión y otorgar un amplio acceso a VIEW, créela como su propio secreto. Utilice un inicio de sesión en el rol sysadmin (o equivalente) para SQL Server autohospedado, o el usuario maestro de RDS para SQL Server en AWS RDS:
bash
```
$kubectl create secret generic mssql-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configurar los valores de Helm

Establezca mssql.topology para que coincida con su entorno:

Valor	Descripción
`self-hosted`	SQL Server autohospedado, al que se accede a través de la red (host de Linux o Windows).
`rds`	SQL Server en AWS RDS.

Utilice el values.yaml que coincida con el método de credenciales que eligió en el paso anterior:

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: https://otlp.nr-data.net:4318

mssql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  username: <YOUR_MONITORING_USERNAME>
  password: <YOUR_MONITORING_PASSWORD>

# No setup job runs, so create the monitoring login yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: https://otlp.nr-data.net:4318

mssql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: mssql-monitor-creds

# No setup job runs, so the monitoring login referenced by
# this secret must already exist - create it yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: https://otlp.nr-data.net:4318

mssql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: mssql-monitor-creds

setupJob:
  enabled: true
  image:
    # -- sqlcmd image. No default: see the chart's README for why
    # (mcr.microsoft.com/mssql-tools:latest is freely pullable but
    # stale and unmaintained).
    repository: ""
    tag: ""
    pullPolicy: IfNotPresent
  sqlAdmin:
    existingSecret: mssql-admin-creds

Parámetro	Descripción
`licenseKey`	Su clave de licencia de New Relic.
`otlpEndpoint`	El extremo OTLP/HTTP de su región, como una URL completa con esquema: `https://otlp.nr-data.net:4318` (EE. UU.) o `https://otlp.eu01.nr-data.net:4318` (UE). Para obtener más información, consulte la documentación de los extremos OTLP de New Relic.
`mssql.server` / `mssql.port`	El host de SQL Server (o extremo de RDS) y el puerto, accesibles desde el clúster.
`mssql.tls.enabled` / `mssql.tls.trustServerCertificate`	Opcional. Establezca `enabled: true` para cifrar la conexión a SQL Server y `trustServerCertificate: true` para omitir la validación del certificado (útil para certificados autofirmados en entornos de prueba).
`setupJob.image.repository` / `setupJob.image.tag`	Una imagen compatible con `sqlcmd`utilizada por el trabajo de configuración. No hay un valor predeterminado: `mcr.microsoft.com/mssql-tools:latest` de Microsoft, que se puede extraer libremente, es de 2017 y no tiene mantenimiento, así que confirme que se siente cómodo con su antigüedad (incluidas las CVE sin parches) antes de usarlo, o cree una imagen actual a partir de los paquetes apt `mssql-tools18` de Microsoft. Solo es necesario para las credenciales basadas en secretos, donde el trabajo de configuración está habilitado.

Sugerencia

Consulte el archivo values.yaml del chart para ver todas las opciones de configuración disponibles, incluidos mssql.collectionInterval, mssql.maxConcurrentQueries y la vía de escape additionalReceiverConfig.

(Opcional) Monitorear múltiples instancias desde un release

En lugar de mssql.*, configure mssqlMulti.enabled: true para monitorear varias instancias de SQL Server (autohospedadas o RDS) desde un solo pod recolector en un release. Los dos modos son mutuamente excluyentes: no configure mssql.server y mssqlMulti.enabled: true en el mismo lanzamiento.

El modo de múltiples instancias no tiene una ruta de nombre de usuario/contraseña en texto sin formato: cada instancia necesita su propio secreto de Kubernetes con credenciales de monitoreo. Decida si también desea que el trabajo de configuración le cree cada inicio de sesión de monitoreo:

Cree usted mismo el secreto de inicio de sesión de monitoreo de cada instancia antes de instalar (repita por instancia, haciendo coincidir el name que le asigne en values.yaml):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: https://otlp.nr-data.net:4318

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secret you created for it.
mssqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  databases:
    - name: db1
      server: <YOUR_DB_1_HOST>
      existingSecret: db1-monitor-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      existingSecret: db2-monitor-creds

# No admin credential is configured here since the setup
# job is disabled - create each instance's monitoring login
# yourself first.
setupJob:
  enabled: false

Cada instancia necesita tanto su propio secreto de inicio de sesión de monitoreo como su propio secreto de credenciales de administrador (repita por instancia):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
>kubectl create secret generic db1-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, db2-admin-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: https://otlp.nr-data.net:4318

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secrets you created for it.
mssqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  databases:
    - name: db1
      server: <YOUR_DB_1_HOST>
      existingSecret: db1-monitor-creds
      sqlAdmin:
        existingSecret: db1-admin-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      existingSecret: db2-monitor-creds
      sqlAdmin:
        existingSecret: db2-admin-creds

setupJob:
  enabled: true
  image:
    repository: ""
    tag: ""

Parámetro	Descripción
`mssqlMulti.enabled`	Establezca en `true` para monitorear varias instancias desde un lanzamiento en lugar de `mssql.*`. Por defecto es `false`.
`mssqlMulti.topology`	`self-hosted` o `rds`, mismo significado que `mssql.topology`, compartido por cada instancia en esta versión.
`mssqlMulti.databases`	Lista de instancias para monitorear. Cada entrada requiere un `name`, `server` (`port` por defecto es `1433`) y `existingSecret` únicos; agregue `sqlAdmin.existingSecret` por entrada solo cuando `setupJob.enabled` sea `true`.

Sugerencia

Los ajustes de extracción (intervalo de recolección, TLS, métrica) se aplican de manera idéntica a cada instancia en mssqlMulti.databases. No hay sobrescritura por instancia. Use additionalReceiverConfig para cualquier cosa que deba ser diferente. El trabajo de configuración se ejecuta una vez por instancia (<release>-setup-<name>) en lugar de una vez por versión.

Instale el chart de Helm

Agregue el repositorio Helm de New Relic:

bash

$helm repo add newrelic https://helm-charts.newrelic.com
$helm repo update

Instale el chart utilizando su archivo values.yaml:

bash

$helm upgrade --install mssql-otel newrelic/mssql-otel \
>  -n newrelic \
>  --create-namespace \
>  -f values.yaml

Verifique la instalación

Compruebe que el trabajo de configuración se haya completado (si está habilitado) y que el pod del recolector se esté ejecutando:
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Ejecute esta consulta en el generador de consultas para confirmar que los datos están llegando:

SELECT count(*) FROM Metric
WHERE metricName LIKE 'sqlserver.%'
AND instrumentation.provider = 'opentelemetry'
SINCE 10 minutes ago

Encuentra y utiliza tus datos

Una vez que sus datos se estén recopilando, puede acceder al monitoreo integral de bases de datos SQL Server a través de la UI de New Relic.

Para encontrar su entidad de base de datos SQL Server en New Relic:

Vaya a one.newrelic.com > All capabilities > Databases.
En el menú desplegable Entity type, seleccione MSSQL instance y luego haga clic en Apply.
Seleccione su base de datos SQL Server de la lista de entidades.
Después de configurar el monitoreo de SQL Server con NRDOT, puede:
- Crea dashboards personalizados para visualizar las métricas de tu base de datos
- Configura alertas para umbrales críticos de rendimiento de la base de datos
- Explore los datos con las capacidades de consulta de New Relic

Referencia de métricas

Obtenga información sobre las métricas disponibles recopiladas por NRDOT Collector.

Resolución de problemas

Aprenda a solucionar problemas de la configuración de monitoreo de MSSQL en New Relic.

Configurar la correlación de APM y base de datos

Aprenda a correlacionar el rendimiento de la aplicación con las operaciones de la base de datos en New Relic.

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de MSSQL con Helm

Instalación guiada

Importante

Requisitos previos

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Referencia de métricas

Resolución de problemas

Configurar la correlación de APM y base de datos

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de MSSQL con Helm

Instalación guiada

Importante

Requisitos previos .css-21sua1{background:none;border:none;width:0;padding:0;}

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Documentación relacionada

Referencia de métricas

Resolución de problemas

Configurar la correlación de APM y base de datos

Requisitos previos