Avance
Todavía estamos trabajando en esta característica, ¡pero nos encantaría que la probaras!
Esta función se proporciona actualmente como parte de una vista previa de conformidad con nuestras políticas de prelanzamiento.
Antes de comenzar a monitorear su MySQL con NRDOT, asegúrese de que su entorno cumpla con estos requisitos.
Requisitos previos
Antes de comenzar, cerciorar de tener lo siguiente:
- Clave de licenciade New Relic válida
- Conectividad de red entre el host donde instala el NRDOT Collector y su base de datos MySQL. Si planea instalar el NRDOT Collector en un host diferente al de su base de datos MySQL, consulte los Requisitos de acceso a la red.
- Conectividad de red a la documentación de los extremos OTLP de New Relic
- Esta integración está disponible como parte del programa de vista previa pública (public preview) de New Relic. Consulte con el Gerente de su organización para activarla desde la página de Previsualizaciones y pruebas (Previews & Trials).
Versiones de MySQL admitidas
El receptor detecta el producto y la versión de la base de datos en la primera conexión y ajusta su comportamiento en consecuencia — las versiones no compatibles/más antiguas siguen funcionando, pero con funcionalidad reducida:
Versiones | Planes de consulta en
| Propagación de traceparent |
/
| Sintaxis de estado de réplica |
|---|---|---|---|---|
| No | Sí | 0 |
|
–
| No | Sí | 0 |
|
–
| Sí | Sí | 0 |
|
| Sí | Sí | Completado |
|
| Sí | Sí | Completado |
|
| Sí | Sí | Completado |
|
Importante
La detección de versión no es fatal: si falla, el receptor vuelve al comportamiento de MySQL < 8 en lugar de generar un error.
Requisitos de acceso a la red
De forma predeterminada, NRDOT se conecta a través de TCP (transport: tcp en la configuración del receptor, el valor predeterminado). Si el recolector se ejecuta en el mismo host que la base de datos, en su lugar puede configurar transport: unix y apuntar endpoint al socket de dominio de Unix de la base de datos (por ejemplo, /var/run/mysqld/mysqld.sock), lo que evita por completo las comprobaciones de red a continuación. Para cualquier otro despliegue —recolector y base de datos en diferentes hosts, contenedores o VPC— se requiere TCP.
Despliegue | Qué revisar |
|---|---|
MySQL autoadministrado en EC2 | Grupo de seguridad : agregue una regla de entrada en el puerto de la base de datos (predeterminado
) desde el origen del recolector —su propio ID de grupo de seguridad (misma VPC, preferido sobre una IP sin procesar) si el recolector se ejecuta en una instancia EC2 diferente, o no se necesita ninguna regla si se ejecuta como un sidecar en la misma instancia. También verifique
en
: muchos valores predeterminados de distribución incluyen
, que rechaza cualquier conexión TCP no local —establézcalo en la IP privada de la instancia o
antes de que un recolector remoto pueda alcanzarlo. |
Amazon RDS/Aurora para MySQL | Grupo de seguridad de VPC : agregue una regla de entrada en el puerto de la instancia de RDS (predeterminado
) desde el grupo de seguridad o la IP privada del recolector; RDS no tiene
a nivel de sistema operativo para editar, por lo que esta es la única puerta de red. Los permisos deben provenir del usuario maestro de RDS — RDS no tiene una cuenta
. Privilegios restringidos :
y
están restringidos o no están disponibles según la versión del motor de RDS y el grupo de parámetros. TLS : las instancias de RDS con la exigencia de "Require SSL/TLS" necesitan que el recolector confíe en la CA de RDS de Amazon — establezca
(o
) en el paquete de certificados de Amazon RDS y deje
/
en
. |
Cualquier despliegue remoto/entre hosts | MySQL trata a
y
(o un host/CIDR específico) como cuentas diferentes , incluso con un nombre de usuario idéntico — la creación del usuario de monitoreo como
falla silenciosamente al autenticarse desde un recolector que se ejecuta en cualquier otro lugar, con un error de acceso denegado indistinguible de una contraseña incorrecta. Use
o limítelo a la IP/CIDR privada específica del recolector. |
Importante
Verificado en una instancia activa de Amazon RDS para MySQL: la familia de grupos de parámetros mysql8.0 de RDS no expone ningún parámetro performance_schema_consumer_* en absoluto —solo los parámetros de tamaño/búfer más performance_schema, slow_query_log y long_query_time se pueden configurar allí. Esto significa que events_waits_current (necesario para mysql.events_waits_current.timer_wait y los dashboards basados en esperas en general) solo se puede activar en tiempo de ejecución en RDS, y no sobrevive a un reinicio o conmutación por error.
Configuración del lado del servidor recomendada
Configure estos parámetros del servidor MySQL para garantizar que el receptor pueda recopilar todas las métricas y planes de consulta disponibles. La siguiente tabla enumera los parámetros y sus valores recomendados:
Parámetro | Valor recomendado | Por qué |
|---|---|---|
| Activado | Las muestras de consultas, las consultas principales y la detección de bloqueos dependen de ello |
|
| Texto de resumen más largo antes de que MySQL lo trunque |
|
| Igual, en la capa del esquema de rendimiento |
|
| Si una sentencia capturada se trunca, el receptor omite
para ella por completo. Los planes de consulta desaparecen silenciosamente para sentencias largas en el valor predeterminado de
bytes |
Próximos pasos
Una vez que haya verificado que su entorno cumple con estos requisitos previos:
- Elija su método de instalación:
- Revise las métricas disponibles que se recopilarán
- Consulte la configuración avanzada para obtener características opcionales como planes de consulta de sentencias de escritura y seguimiento de la duración de la espera de bloqueo
- Consulte nuestra guía de resolución de problemas para problemas comunes