Instale e configure o NRDOT para monitoramento do MSSQL com Helm

Você pode instalar e configurar o monitoramento do SQL Server no Kubernetes usando o chart do Helm mssql-otel. Opcionalmente, o chart também pode executar um job de configuração que cria o login de monitoramento para você.

Instalação guiada

Para instalar isso pela interface da New Relic, acesse one.newrelic.com > Integrations & Agents > Microsoft SQL Server (Database 360) . Siga as instruções na tela para configurar a integração. Esta página aborda apenas a instalação manual.

Importante

Este chart suporta apenas a Autenticação do SQL Server (nome de usuário/senha). Ele não suporta a Autenticação do Windows, a Autenticação de domínio do Windows ou gMSA. O coletor sempre acessa o SQL Server remotamente pela rede, seja executado no Linux ou no Windows, auto-hospedado ou no RDS, portanto, a autenticação do SQL funciona de forma idêntica em todos os casos. Ele também relata apenas métricas do SQL Server (sem métricas de host/infraestrutura), já que o coletor é executado como uma implantação do Kubernetes em vez de no próprio host do SQL Server.

Pré-requisitos

Chave de licença da New Relic válida.
Helm 3.0 ou posterior, e kubectl configurado para acessar seu cluster do Kubernetes.
Conectividade de rede do seu cluster do Kubernetes para o host do SQL Server (ou endpoint do RDS) e porta:
- Auto-hospedado: um caminho roteado para o host do SQL Server (VPN, peering ou rede compartilhada), e o firewall do lado do SQL Server deve permitir o IP de origem da conexão.
- AWS RDS: emparelhamento de VPC, um transit gateway ou posicionamento em VPC compartilhada com a instância do RDS, e o grupo de segurança do RDS deve permitir a porta do SQL Server (1433 por padrão) a partir da origem de saída do cluster.
Um login de monitoramento que você já criou ou credenciais de administrador do SQL Server (um login com a função sysadmin, como sa ou o usuário mestre do RDS) para que o job de configuração do chart possa criar um para você. Veja Configurar credenciais de monitoramento abaixo.

Crie o namespace

Crie o namespace onde a instalação será realizada. Ele deve existir antes da criação de qualquer secret na próxima etapa, já que helm install --create-namespace cria o namespace apenas durante a etapa final de instalação:

bash

$kubectl create namespace newrelic

Dica

Defina-o como o namespace padrão para o seu contexto kubectl atual para que não seja necessário passar -n em todos os comandos abaixo:

bash

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

Configure as credenciais de monitoramento

Decida se deseja que o job de configuração do chart crie o login de monitoramento do SQL Server para você e, caso contrário, como você fornecerá as credenciais dele:

Com este método, não há job de configuração, portanto, nada aqui cria o login de monitoramento para você. Este chart suporta apenas a Autenticação do SQL Server, portanto, antes de instalá-lo, crie o login de monitoramento usando a etapa Criar usuário de monitoramento da Autenticação do SQL Server em Linux self-hosted, Windows self-hosted, Linux RDS ou Windows RDS, dependendo do seu ambiente.

Você definirá o nome de usuário e a senha de monitoramento diretamente em values.yaml na próxima etapa.

Com este método, também não há job de configuração. Crie você mesmo o login de monitoramento primeiro, exatamente como no método plain-credentials acima. A única diferença é onde suas credenciais ficam: em vez de texto simples em values.yaml, armazene-as em um secret do Kubernetes:

bash

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

Com este método, o job de configuração do chart cria o login de monitoramento para você usando as credenciais de administrador do SQL Server. Tanto as credenciais de monitoramento quanto as de administrador devem ser fornecidas como secrets do Kubernetes: o job de configuração nunca aceita credenciais de administrador em texto simples, e habilitá-lo também requer credenciais de monitoramento baseadas em secrets.

Crie um secret com o nome de usuário e a senha de monitoramento. Esta é a identidade que o job de configuração cria e com a qual o coletor se conecta:

bash

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

O job de configuração aceita apenas credenciais de administrador por meio de um secret do Kubernetes (sem nome de usuário/senha em texto simples em values.yaml). Como essa credencial pode criar logins e conceder amplo acesso VIEW, crie-a como seu próprio segredo. Use um login na função sysadmin (ou equivalente) para o SQL Server auto-hospedado, ou o usuário mestre do RDS para o SQL Server no AWS RDS:
bash
```
$kubectl create secret generic mssql-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configure os valores do Helm

Defina mssql.topology para corresponder ao seu ambiente:

Valor	Descrição
`self-hosted`	SQL Server auto-hospedado, acessado pela rede (host Linux ou Windows).
`rds`	SQL Server no AWS RDS.

Use o values.yaml que corresponde ao método de credencial escolhido na etapa 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	Descrição
`licenseKey`	Sua chave de licença New Relic.
`otlpEndpoint`	O endpoint OTLP/HTTP da sua região, como um URL completo com esquema: `https://otlp.nr-data.net:4318` (US) ou `https://otlp.eu01.nr-data.net:4318` (EU). Para mais informações, consulte a documentação dos endpoints OTLP da New Relic .
`mssql.server` / `mssql.port`	Seu host do SQL Server (ou endpoint do RDS) e porta, acessíveis a partir do cluster.
`mssql.tls.enabled` / `mssql.tls.trustServerCertificate`	Opcional. Defina `enabled: true` para criptografar a conexão com o SQL Server e `trustServerCertificate: true` para ignorar a validação do certificado (útil para certificados autoassinados em ambientes de teste).
`setupJob.image.repository` / `setupJob.image.tag`	Uma imagem compatível com `sqlcmd` usada pelo job de configuração. Não há padrão: o `mcr.microsoft.com/mssql-tools:latest` da Microsoft, que pode ser baixado gratuitamente, é de 2017 e não tem manutenção; portanto, confirme se está confortável com a idade (incluindo CVEs sem correção) antes de usá-lo, ou crie você mesmo uma imagem atual a partir dos pacotes apt `mssql-tools18` da Microsoft. Necessário apenas para credenciais baseadas em segredos, em que o job de configuração está habilitado.

Dica

Consulte o values.yaml do chart para ver todas as opções de configuração disponíveis, incluindo mssql.collectionInterval, mssql.maxConcurrentQueries e a válvula de escape additionalReceiverConfig.

(Opcional) Monitorar várias instâncias a partir de um release

Em vez de mssql.*, defina mssqlMulti.enabled: true para monitorar várias instâncias do SQL Server (self-hosted ou RDS) a partir de um único pod de coletor em um release. Os dois modos são mutuamente exclusivos: não defina mssql.server e mssqlMulti.enabled: true no mesmo release.

O modo multi-instância não possui um caminho de nome de usuário/senha em texto simples: cada instância precisa de seu próprio secret do Kubernetes com credenciais de monitoramento. Decida se você também deseja que o job de configuração crie cada login de monitoramento para você:

Crie manualmente o secret de login de monitoramento de cada instância antes da instalação (repita por instância, correspondendo ao name fornecido em 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 instância precisa tanto de seu próprio segredo de login de monitoramento quanto de seu próprio segredo de credenciais de administrador (repita por instância):

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	Descrição
`mssqlMulti.enabled`	Defina como `true` para monitorar várias instâncias de uma versão em vez de `mssql.*` . O padrão é `false` .
`mssqlMulti.topology`	`self-hosted` ou `rds` , mesmo significado que `mssql.topology` , compartilhado por todas as instâncias nesta versão.
`mssqlMulti.databases`	Lista de instâncias a serem monitoradas. Cada entrada requer um `name` exclusivo, `server` ( `port` tem como padrão `1433` ) e `existingSecret` ; adicione `sqlAdmin.existingSecret` por entrada apenas quando `setupJob.enabled` for `true` .

Parâmetro

Descrição

mssqlMulti.enabled

Defina como

true

para monitorar várias instâncias de uma versão em vez de

mssql.*

. O padrão é

false

mssqlMulti.topology

self-hosted

rds

, mesmo significado que

mssql.topology

, compartilhado por todas as instâncias nesta versão.

mssqlMulti.databases

Lista de instâncias a serem monitoradas. Cada entrada requer um

name

exclusivo,

server

(

port

tem como padrão

1433

) e

existingSecret

; adicione

sqlAdmin.existingSecret

por entrada apenas quando

setupJob.enabled

for

true

Dica

As configurações de scrape (intervalo de coleta, TLS, métricas) se aplicam de forma idêntica a cada instância em mssqlMulti.databases. Não há substituição por instância. Use additionalReceiverConfig para qualquer item que precise ser diferente. O job de configuração é executado uma vez por instância (<release>-setup-<name>) em vez de uma vez por release.

Instale o Helm chart

Adicione o repositório Helm da New Relic:

bash

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

Instale o chart usando seu arquivo values.yaml:

bash

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

Verifique a instalação

Verifique se o job de configuração foi concluído (se ativado) e se o pod do coletor está em execução:
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Execute esta consulta no criador de consulta para confirmar se os dados estão chegando:

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

Encontre e use seus dados

Assim que os dados estiverem sendo coletados, será possível acessar o monitoramento abrangente do banco de dados SQL Server por meio da interface do New Relic.

Para encontrar sua entidade de banco de dados SQL Server no New Relic:

Vá para one.newrelic.com > All capabilities > Databases.
Na dropdown Entity type, selecione MSSQL instance e clique em Apply.
Selecione seu banco de dados SQL Server na lista de entidades.
Após configurar o monitoramento do SQL Server com o NRDOT, você pode:
- Crie dashboards personalizados para visualizar suas métricas de banco de dados
- Configure alertas para limites críticos de desempenho do banco de dados
- Explore seus dados usando os recursos de consulta do New Relic

Referência de métricas

Saiba mais sobre as métricas disponíveis coletadas pelo NRDOT Collector.

Resolução de problemas

Saiba como solucionar problemas na sua configuração de monitoramento do MSSQL no New Relic.

Configurar a correlação entre APM e banco de dados

Aprenda a correlacionar o desempenho do seu aplicativo com as operações de banco de dados no New Relic.

Esta tradução de máquina é fornecida para sua comodidade.

Instale e configure o NRDOT para monitoramento do MSSQL com Helm

Instalação guiada

Importante

Pré-requisitos

Crie o namespace

Dica

Configure as credenciais de monitoramento

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Configure os valores do Helm

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Dica

(Opcional) Monitorar várias instâncias a partir de um release

Sem job de configuração

Tarefa de configuração automatizada

Dica

Instale o Helm chart

Verifique a instalação

Encontre e use seus dados

Referência de métricas

Resolução de problemas

Configurar a correlação entre APM e banco de dados

Esta tradução de máquina é fornecida para sua comodidade.

Instale e configure o NRDOT para monitoramento do MSSQL com Helm

Instalação guiada

Importante

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

Crie o namespace

Dica

Configure as credenciais de monitoramento

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Configure os valores do Helm

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Dica

(Opcional) Monitorar várias instâncias a partir de um release

Sem job de configuração

Tarefa de configuração automatizada

Dica

Instale o Helm chart

Verifique a instalação

Encontre e use seus dados

Documentação relacionada

Referência de métricas

Resolução de problemas

Configurar a correlação entre APM e banco de dados

Pré-requisitos