Installez & configurez NRDOT pour le monitoring MSSQL avec Helm

Vous pouvez installer et configurer le monitoring de SQL Server sur Kubernetes à l’aide du chart Helm mssql-otel. En option, le chart peut également exécuter un job de configuration qui crée l’identifiant de monitoring pour vous.

Installation guidée

Pour installer ceci via l’UI de New Relic à la place, accédez à one.newrelic.com > Integrations & Agents > Microsoft SQL Server (Database 360) . Suivez les instructions à l’écran pour configurer l’intégration. Cette page couvre uniquement l’installation manuelle.

Important

Ce chart prend uniquement en charge l’authentification SQL Server (nom d’utilisateur / mot de passe). Il ne prend pas en charge l’authentification Windows, l’authentification de domaine Windows, ou gMSA. Le collecteur accède toujours à SQL Server à distance via le réseau, qu’il s’exécute sur Linux, ou Windows, qu’il soit auto-hébergé, ou sur RDS, de sorte que l’authentification SQL fonctionne de manière identique dans tous les cas. Il rapporte également uniquement les métriques SQL Server (aucune métrique d’hôte/infrastructure), puisque le collecteur s’exécute en tant que déploiement Kubernetes, plutôt que sur l’hôte SQL Server lui-même.

Prérequis

Clé de licence New Relic valide.
Helm 3.0 ou version ultérieure, et kubectl configuré pour accéder à votre cluster Kubernetes.
Connectivité réseau depuis votre cluster Kubernetes vers l’hôte SQL Server (ou le point de terminaison RDS) et le port :
- Auto-hébergé : un chemin routé vers l’hôte SQL Server (VPN, peering, ou réseau partagé), et le pare-feu côté SQL Server doit autoriser l’adresse IP source de la connexion.
- AWS RDS : appairage de VPC, gateway de transit, ou placement dans un VPC partagé avec l’instance RDS, et le groupe de sécurité RDS doit autoriser le port SQL Server (1433 par défaut) depuis la source de trafic sortant du cluster.
Soit un identifiant de monitoring que vous avez déjà créé, soit des identifiants d'administrateur SQL Server (un identifiant avec le rôle sysadmin, tel que sa ou l'utilisateur maître RDS) afin que le job de configuration du chart puisse en créer un pour vous. Voir Configurer les identifiants de monitoring ci-dessous.

Créer l’espace de nommage

Créez l’espace de nommage dans lequel vous effectuerez l’installation. Il doit exister avant que vous ne créiez des secrets à l’étape suivante, car helm install --create-namespace ne crée l’espace de nommage que lors de l’étape d’installation finale :

bash

$kubectl create namespace newrelic

Conseil

Définissez-le comme espace de nommage par défaut pour votre contexte kubectl actuel afin de ne pas avoir à passer -n à chaque commande ci-dessous :

bash

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

Configurez les identifiants de monitoring

Décidez si vous souhaitez que la tâche de configuration du chart crée l’identifiant de connexion de monitoring SQL Server pour vous, et si ce n’est pas le cas, comment vous fournirez ses informations d’identification :

Avec cette méthode, il n’y a aucun job de configuration, donc rien ici ne crée l’identifiant de monitoring pour vous. Ce chart ne prend en charge que l’authentification SQL Server, donc avant de l’installer, créez vous-même l’identifiant de monitoring en utilisant l’étape Créer un utilisateur de monitoring de l’authentification SQL Server à partir de Linux auto-hébergé, Windows auto-hébergé, Linux RDS, ou Windows RDS, selon votre environnement.

Vous définirez le nom d’utilisateur et le mot de passe de monitoring directement dans values.yaml à l’étape suivante.

Avec cette méthode, il n’y a pas non plus de tâche de configuration. Créez d’abord vous-même l’identifiant de monitoring, exactement comme dans la méthode des informations d’identification en texte clair ci-dessus. La seule différence est l’endroit où se trouvent ses informations d’identification : au lieu d’être en texte clair dans values.yaml, stockez-les dans un secret Kubernetes :

bash

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

Avec cette méthode, le job de configuration du chart crée l’identifiant de monitoring pour vous à l’aide des identifiants d’administrateur SQL Server. Les identifiants de monitoring et d’administrateur doivent tous deux être fournis en tant que secrets Kubernetes : le job de configuration n’accepte jamais les identifiants d’administrateur en texte clair, et son activation nécessite également des identifiants de monitoring basés sur des secrets.

Créez un secret avec le nom d'utilisateur et le mot de passe de monitoring. Il s'agit de l'identité que le job de configuration crée et avec laquelle le collecteur se connecte :
bash
```
$kubectl create secret generic mssql-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
```
Le job de configuration n’accepte les identifiants d’administrateur que via un secret Kubernetes (pas de nom d’utilisateur / mot de passe en texte clair dans values.yaml). Puisque cet identifiant peut créer des connexions, et accorder un accès VIEW étendu, créez-le en tant que secret distinct. Utilisez une connexion dans le rôle sysadmin (ou équivalent) pour SQL Server auto-hébergé, ou l’utilisateur principal RDS pour SQL Server sur AWS RDS :
bash
```
$kubectl create secret generic mssql-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configurez les valeurs Helm

Configurez mssql.topology pour correspondre à votre environnement :

Valeur	Description
`self-hosted`	SQL Server auto-hébergé, accessible via le réseau (hôte Linux ou Windows).
`rds`	SQL Server sur AWS RDS.

Utilisez le values.yaml qui correspond à la méthode d'identification que vous avez choisie à l'étape précédente :

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

paramètres	Description
`licenseKey`	Votre clé de licence New Relic.
`otlpEndpoint`	Le point de terminaison OTLP/HTTP de votre région, sous forme d’URL complète avec le schéma : `https://otlp.nr-data.net:4318` (US) ou `https://otlp.eu01.nr-data.net:4318` (EU). Pour plus d’informations, consultez la documentation sur les points de terminaison OTLP New Relic .
`mssql.server` / `mssql.port`	Votre hôte SQL Server (ou point de terminaison RDS) et le port, accessibles depuis le cluster.
`mssql.tls.enabled` / `mssql.tls.trustServerCertificate`	Facultatif. Définissez `enabled: true` pour chiffrer la connexion à SQL Server, et `trustServerCertificate: true` pour ignorer la validation du certificat (utile pour les certificats auto-signés dans les environnements de test).
`setupJob.image.repository` / `setupJob.image.tag`	Une image compatible avec `sqlcmd` utilisée par le job de configuration. Il n’y a pas de valeur par défaut : le `mcr.microsoft.com/mssql-tools:latest` de Microsoft librement téléchargeable date de 2017 et n’est pas maintenu, confirmez donc que son ancienneté (y compris les CVE non corrigées) vous convient avant de l’utiliser, ou créez vous-même une image actuelle à partir des packages apt `mssql-tools18` de Microsoft. Requis uniquement pour les identifiants basés sur des secrets, lorsque la tâche de configuration est activée.

Conseil

Consultez le fichier values.yaml du chart pour connaître toutes les options de configuration disponibles, y compris mssql.collectionInterval, mssql.maxConcurrentQueries, et la trappe de secours additionalReceiverConfig.

(Facultatif) Monitorer plusieurs instances à partir d’une seule sortie

Au lieu de mssql.*, définissez mssqlMulti.enabled: true pour monitorer plusieurs instances SQL Server (auto-hébergées ou RDS) à partir d’un seul pod collecteur dans une seule sortie. Les deux modes sont mutuellement exclusifs : ne définissez pas mssql.server et mssqlMulti.enabled: true dans la même sortie.

Le mode multi-instance n’a pas de chemin nom d’utilisateur / mot de passe en clair : chaque instance a besoin de son propre secret Kubernetes avec des identifiants de monitoring. Décidez si vous souhaitez également que le job de configuration crée chaque identifiant de monitoring pour vous :

Créez vous-même le secret monitoring-login de chaque instance avant l'installation (répétez pour chaque instance, en faisant correspondre le name que vous lui donnez dans 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

Chaque instance nécessite à la fois son propre secret monitoring-login et son propre secret admin-credentials (répétez par instance) :

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: ""

paramètres	Description
`mssqlMulti.enabled`	Définissez sur `true` pour monitorer plusieurs instances à partir d’une seule sortie au lieu de `mssql.*` . Par défaut `false` .
`mssqlMulti.topology`	`self-hosted` ou `rds` , même signification que `mssql.topology` , partagé par chaque instance dans cette sortie.
`mssqlMulti.databases`	Liste des instances à monitorer. Chaque entrée nécessite un `name` unique, `server` ( `port` vaut `1433` par défaut), et `existingSecret` ; ajoutez `sqlAdmin.existingSecret` par entrée uniquement lorsque `setupJob.enabled` est `true` .

paramètres

Description

mssqlMulti.enabled

Définissez sur

true

pour monitorer plusieurs instances à partir d’une seule sortie au lieu de

mssql.*

. Par défaut

false

mssqlMulti.topology

self-hosted

rds

, même signification que

mssql.topology

, partagé par chaque instance dans cette sortie.

mssqlMulti.databases

Liste des instances à monitorer. Chaque entrée nécessite un

name

unique,

server

(

port

vaut

1433

par défaut), et

existingSecret

; ajoutez

sqlAdmin.existingSecret

par entrée uniquement lorsque

setupJob.enabled

est

true

Conseil

Les paramètres de scraping (intervalle de collecte, TLS, métriques) s’appliquent de manière identique à chaque instance dans mssqlMulti.databases. Il n’y a pas de surcharge par instance. Utilisez additionalReceiverConfig pour tout ce qui doit différer. Le job de configuration s’exécute une fois par instance (<release>-setup-<name>) plutôt qu’une fois par sortie.

Installer le chart Helm

Ajouter le dépôt Helm New Relic :

bash

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

Installez le chart à l'aide de votre fichier values.yaml :

bash

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

Vérifier l'installation

Vérifiez que la tâche de configuration est terminée (si elle est activée), et que le pod du collecteur est en cours d’exécution :
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Exécutez cette requête dans le générateur de requêtes pour confirmer que les données arrivent :

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

Trouvez et utilisez vos données

Une fois vos données collectées, vous pouvez accéder à un monitoring complet de la base de données SQL Server via l'UI de New Relic.

Pour trouver votre entité de base de données SQL Server dans New Relic :

Allez à one.newrelic.com > All capabilities > Databases.
Dans la liste déroulante Entity type, sélectionnez MSSQL instance, puis cliquez sur Apply.
Sélectionnez votre base de données SQL Server dans la liste des entités.
Après avoir configuré le monitoring SQL Server avec NRDOT, vous pouvez :
- Créez des dashboards personnalisés pour visualiser les métriques de votre base de données
- Configurer des alertes pour les seuils critiques de performances des bases de données
- Explorez vos données à l’aide des fonctionnalités de requête de New Relic

Référence des métriques

Découvrez les métriques disponibles collectées par le collecteur NRDOT.

Dépannage

Découvrez comment dépanner votre configuration de monitoring MSSQL dans New Relic.

Configurer la corrélation APM-base de données

Découvrez comment corréler les performances des applications avec les opérations de base de données dans New Relic.

Cette traduction automatique est fournie pour votre commodité.

Installez & configurez NRDOT pour le monitoring MSSQL avec Helm

Installation guidée

Important

Prérequis

Créer l’espace de nommage

Conseil

Configurez les identifiants de monitoring

Aucun job de configuration : nom d’utilisateur et mot de passe simples

Aucun job de configuration : identifiants basés sur des secrets

Job de configuration automatisé

Configurez les valeurs Helm

Aucun job de configuration : nom d’utilisateur et mot de passe simples

Aucun job de configuration : identifiants basés sur des secrets

Job de configuration automatisé

Conseil

(Facultatif) Monitorer plusieurs instances à partir d’une seule sortie

Aucune tâche de configuration

Job de configuration automatisé

Conseil

Installer le chart Helm

Vérifier l'installation

Trouvez et utilisez vos données

Référence des métriques

Dépannage

Configurer la corrélation APM-base de données

Cette traduction automatique est fournie pour votre commodité.

Installez & configurez NRDOT pour le monitoring MSSQL avec Helm

Installation guidée

Important

Prérequis .css-21sua1{background:none;border:none;width:0;padding:0;}

Créer l’espace de nommage

Conseil

Configurez les identifiants de monitoring

Aucun job de configuration : identifiants basés sur des secrets

Job de configuration automatisé

Configurez les valeurs Helm

Aucun job de configuration : nom d’utilisateur et mot de passe simples

Aucun job de configuration : identifiants basés sur des secrets

Job de configuration automatisé

Conseil

(Facultatif) Monitorer plusieurs instances à partir d’une seule sortie

Aucune tâche de configuration

Job de configuration automatisé

Conseil

Installer le chart Helm

Vérifier l'installation

Trouvez et utilisez vos données

Documentation associée

Référence des métriques

Dépannage

Configurer la corrélation APM-base de données

Prérequis