Compatibilidade e pré-requisitos

Antes de iniciar o monitoramento do MySQL com o NRDOT, é necessário garantir que o ambiente atenda a estes requisitos.

Pré-requisitos

Antes de começar, certifique-se de ter o seguinte:

Uma chave de licençada New Relic válida
Conectividade de rede entre o host onde o NRDOT Collector é instalado e o seu banco de dados MySQL. Caso planeje instalar o NRDOT Collector em um host diferente do seu banco de dados MySQL, consulte os Requisitos de Acesso à Rede.
Conectividade de rede para a documentação dos endpoints OTLP da New Relic

Versões MySQL suportadas

O receptor detecta o produto e a versão do banco de dados na primeira conexão e ajusta seu comportamento de acordo. Versões não suportadas ou mais antigas ainda funcionam, mas com funcionalidade reduzida:

Versões	Planos de consulta em `db.server.top_query`	Propagação do traceparent	`client.port` / `network.peer.port`	Sintaxe de status de réplica
`8.0.3` – `8.0.21`	Sim	Sim	0	`SHOW SLAVE STATUS`
`8.0.22+`	Sim	Sim	Preenchido	`SHOW REPLICA STATUS`
`8.4.x`	Sim	Sim	Preenchido	`SHOW REPLICA STATUS`
`9.x`	Sim	Sim	Preenchido	`SHOW REPLICA STATUS`

Requisitos de acesso à rede

Por padrão, o NRDOT se conecta via TCP (transport: tcp na configuração do receptor, o padrão). Se o coletor for executado no mesmo host que o banco de dados, você pode, em vez disso, definir transport: unix e apontar endpoint para o soquete de domínio Unix do banco de dados (por exemplo, /var/run/mysqld/mysqld.sock), o que contorna totalmente as verificações de rede abaixo. Para qualquer outra implantação (coletor e banco de dados em hosts, contêineres ou VPCs diferentes), o TCP é necessário.

Implantação	O que verificar
MySQL autogerenciado no EC2	Security group : adicionar uma regra de entrada na porta do banco de dados (padrão `3306` ) a partir da origem do coletor: o ID do seu próprio security group (mesma VPC, preferível a um IP bruto) se o coletor for executado em uma instância de EC2 diferente, ou nenhuma regra será necessária se ele for executado como um sidecar na mesma instância. Verificar também `bind-address` em `my.cnf` : muitos padrões de distribuição incluem `bind-address = 127.0.0.1` , que recusa qualquer conexão TCP não local. Definir como o IP privado da instância ou `0.0.0.0` antes que um coletor remoto possa acessá-lo.
Amazon RDS / Aurora para MySQL	Grupo de segurança da VPC : adicione uma regra de entrada na porta da instância do RDS (padrão `3306` ) a partir do grupo de segurança ou IP privado do coletor; o RDS não possui `my.cnf` no nível do sistema operacional para editar, portanto, este é o único portão de rede. Concessões devem vir do usuário mestre do RDS. O RDS não tem conta `root` . Privilégios restritos : `SUPER` e `FILE` são restritos ou indisponíveis dependendo da versão do mecanismo do RDS e do grupo de parâmetros. TLS : as instâncias do RDS com a imposição “Require SSL/TLS” precisam que o coletor confie na CA do Amazon RDS. Defina `tls.ca_file` (ou `tls.ca_pem` ) para o pacote de certificados do Amazon RDS e deixe `tls.insecure` / `tls.insecure_skip_verify` em `false` .
Qualquer implantação remota/entre hosts	O MySQL trata `'<user>'@'localhost'` e `'<user>'@'%'` (ou um host/CIDR específico) como contas diferentes , mesmo com um nome de usuário idêntico. Criar o usuário de monitoramento como `'<user>'@'localhost'` falha silenciosamente ao autenticar a partir de um coletor em execução em qualquer outro lugar, com um erro de acesso negado indistinguível de uma senha incorreta. Use `'<user>'@'%'` ou restrinja-o ao IP/CIDR privado específico do coletor.

Implantação

O que verificar

MySQL autogerenciado no EC2

Security group

: adicionar uma regra de entrada na porta do banco de dados (padrão

3306

) a partir da origem do coletor: o ID do seu próprio security group (mesma VPC, preferível a um IP bruto) se o coletor for executado em uma instância de EC2 diferente, ou nenhuma regra será necessária se ele for executado como um sidecar na mesma instância. Verificar também

bind-address

my.cnf

: muitos padrões de distribuição incluem

bind-address = 127.0.0.1

, que recusa qualquer conexão TCP não local. Definir como o IP privado da instância ou

0.0.0.0

antes que um coletor remoto possa acessá-lo.

Amazon RDS / Aurora para MySQL

Grupo de segurança da VPC

: adicione uma regra de entrada na porta da instância do RDS (padrão

3306

) a partir do grupo de segurança ou IP privado do coletor; o RDS não possui

my.cnf

no nível do sistema operacional para editar, portanto, este é o único portão de rede.

Concessões

devem vir do usuário mestre do RDS. O RDS não tem conta

root

Privilégios restritos

SUPER

FILE

são restritos ou indisponíveis dependendo da versão do mecanismo do RDS e do grupo de parâmetros.

TLS

: as instâncias do RDS com a imposição “Require SSL/TLS” precisam que o coletor confie na CA do Amazon RDS. Defina

tls.ca_file

(ou

tls.ca_pem

) para o

pacote de certificados do Amazon RDS

e deixe

tls.insecure

tls.insecure_skip_verify

false

Qualquer implantação remota/entre hosts

O MySQL trata

'<user>'@'localhost'

'<user>'@'%'

(ou um host/CIDR específico) como

contas diferentes

, mesmo com um nome de usuário idêntico. Criar o usuário de monitoramento como

'<user>'@'localhost'

falha silenciosamente ao autenticar a partir de um coletor em execução em qualquer outro lugar, com um erro de acesso negado indistinguível de uma senha incorreta. Use

'<user>'@'%'

ou restrinja-o ao IP/CIDR privado específico do coletor.

Importante

Verificado em uma instância ativa do Amazon RDS for MySQL: a família de grupos de parâmetros mysql8.0 do RDS não expõe nenhum parâmetro performance_schema_consumer_*; apenas parâmetros de dimensionamento/buffer, além de performance_schema, slow_query_log e long_query_time, podem ser definidos lá. Isso significa que events_waits_current (necessário para mysql.events_waits_current.timer_wait e dashboards baseados em espera em geral) só pode ser ativado em tempo de execução no RDS e não sobrevive a uma reinicialização ou failover.

Configuração no lado do servidor recomendada

Configure esses parâmetros do servidor MySQL para garantir que o receptor possa coletar todas as métricas e planos de consulta disponíveis. A tabela a seguir lista os parâmetros e os seus valores recomendados:

Parâmetro	Valor recomendado	Por que
`performance_schema`	Habilitado	Amostras de consulta, principais consultas e detecção de bloqueio dependem disso
`max_digest_length`	`4096`	Texto de resumo mais longo antes que o MySQL o trunque
`performance_schema_max_digest_length`	`4096`	O mesmo, na camada do esquema de desempenho
`performance_schema_max_sql_text_length`	`4096`	Se uma instrução capturada for truncada, o receptor ignora `EXPLAIN` para ela totalmente. Planos de consulta desaparecem silenciosamente para instruções longas no padrão de `1024` bytes

Próximos passos

Depois de verificar se o seu ambiente atende a estes pré-requisitos:

Escolha o método de instalação:

Verifique as métricas disponíveis que serão coletadas
Consulte Ativar insights detalhados para ver recursos opcionais, como planos de consulta de instruções de gravação e rastreamento da duração da espera de bloqueio
Consulte nosso guia de resolução de problemas para problemas comuns