Visualização
Ainda estamos trabalhando nesse recurso, mas adoraríamos que você experimentasse!
Atualmente, esse recurso é fornecido como parte de uma prévia, de acordo com nossas políticas de pré-lançamento.
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:
- 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
- Esta integração está disponível como parte do programa de pré-visualização pública da New Relic. Verifique com seu gerente da organização para fazer a adesão na página Previews & Trials.
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/mais antigas ainda funcionam, mas com funcionalidade reduzida:
Versões | Planos de consulta em
| Propagação do traceparent |
/
| Sintaxe de status de réplica |
|---|---|---|---|---|
| Não | Sim | 0 |
|
–
| Não | Sim | 0 |
|
–
| Sim | Sim | 0 |
|
| Sim | Sim | Preenchido |
|
| Sim | Sim | Preenchido |
|
| Sim | Sim | Preenchido |
|
Importante
A detecção de versão não é fatal: se falhar, o receptor reverte para o comportamento do MySQL < 8 em vez de apresentar erro.
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, é possível 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 evita 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 | Grupo de segurança : adicionar uma regra de entrada na porta do banco de dados (padrão
) a partir da origem do coletor — seu próprio ID de grupo de segurança (mesma VPC, preferencial em relação a um IP bruto) se o coletor for executado em uma instância de EC2 diferente, ou nenhuma regra será necessária se for executado como um sidecar na mesma instância. Verificar também
em
: muitos padrões de distribuição incluem
, que recusa qualquer conexão TCP não local — defini-lo para o IP privado da instância ou
antes que um coletor remoto possa alcançá-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
) a partir do grupo de segurança ou IP privado do coletor; o RDS não possui
no nível do sistema operacional para editar, portanto, este é o único acesso de rede. Permissões devem vir do usuário mestre do RDS — o RDS não possui conta
. Privilégios restritos :
e
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
(ou
) para o pacote de certificados do Amazon RDS e deixe
/
em
. |
Qualquer implantação remota/entre hosts | O MySQL trata
e
(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
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. Utilize
ou restrinja-o ao IP/CIDR privado específico do coletor. |
Importante
Verificado em uma instância ativa do Amazon RDS para 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 |
|---|---|---|
| Habilitado | Amostras de consulta, principais consultas e detecção de bloqueio dependem disso |
|
| Texto de resumo mais longo antes que o MySQL o trunque |
|
| O mesmo, na camada do esquema de desempenho |
|
| Se uma instrução capturada for truncada, o receptor ignora
para ela totalmente. Planos de consulta desaparecem silenciosamente para instruções longas no padrão de
bytes |
Próximos passos
Depois de verificar se o seu ambiente atende a estes pré-requisitos:
- Escolha o método de instalação:
- Revisar as métricas disponíveis que serão coletadas
- Consultar a configuração avançada para obter recursos opcionais, como planos de consulta de instrução de gravação e rastreamento de duração de espera de bloqueio
- Consulte o guia de resolução de problemas para problemas comuns